I run a fair number of sites, and I don't want to hold people's passwords.
Today I use auth0 configured as a passwordless solution, i.e. email code + login, or use Google OAuth, etc. You can see it working on sites like https://www.lfgss.com/
I would consider another solution, but I'm not sure that this is it.
The information is sparse, as a site-owner it hasn't really sold me on:
1. how this works
2. that the first login friction for the user is low/effortless
As I understand it, this is not a "password manager", but more along the idea of a "login manager" that you install locally.
And, if you do not wish to install something locally then there is a browser bit which I think is in JS and this is "less secure" and "slower"... but this in itself puts me off the whole idea because I think the browser bit is what most people will use, and that security is fairly boolean so "less secure" probably equals "not secure". If this is just a communication of risks, then those are not being communicated.
But I'm curious enough to want to know more, so I googled, found his Twitter, looked through and saw others asking similar things to which the author response amounts to "read the code".
It feels like a poor sell, because whatever this is may well be the kind of thing I'm looking for. But I just do not know.
Changing authentication is such a big thing that I can't see me moving from passwordless auth0 unless the communication is super effective... not just for me as a site owner, but also for end users who will wonder what it is being asked of them and whether to trust it.
If you don't speak Ruby, hit me up I will dedicate all my time to help you.. and even get free audit as early adopter. FYI we conducted security audit for Auth0 (https://sakurity.com/)
Actually by using auth0 you rely not on one central authority, but on two: auth0 and google/microsoft oauth. If _either_ of them is compromised, your users accounts are too. If that worries you, try SL:
With SecureLogin you only rely on the local app user installs. First login friction? Not great, but is getting better, I'm giving it daily to normal users and it improves.
> If this is just a communication of risks, then those are not being communicated
Correct, that message is not very informative. I think it will be removed.
Literally just "1". Tells me nothing about what's happening in this change, and from the diff, it looks like quite a lot ("118 changed files with 283 additions and 179 deletions").
Talk about as substance-less criticism as any. A lot of the criticism of his/er project here seems to be on non-substantive things (commit messages, tone of the medium article) and not on the substance (the actual fucking protocol). Classic HN poo-poo'ing on anything that either competes with their service or they've missed the boat on.
Besides, everyone writes shitty messages every now and then. Don't judge their code by their use of a VCS. It's like judging a person's articles by their notes. I've got terrible handwriting.
> Don't judge their code by their use of a VCS. It's like judging a person's articles by their notes. I've got terrible handwriting.
Except notes rarely are intended to be public and used for communication with other developers. While I agree that bad commit messages every now and then are not a big deal - that is not what the original commenter was referring to. Of the 23 commit messages, 8 of them are just "1".
The only meaningful commit message was from a 3rd party PR that was merged. For security-related code, "hygienic" coding practices, including quality commit messages, are - at least in my eyes - important.
It doesn't. `git commit` will open your $EDITOR to let you modify the full commit message. I would recommend looking at how Linux kernel commit messages are structured.
Except that the commit history is actually important when auditing a security-sensitive project.
After reading the guidelines for the Linux kernel I've always given full and proper commit descriptions for effectively all of my commits (with exceptions for projects which don't matter, and such messages aren't going to be read by anyone -- including me). I really wish more people did this, because it makes bisecting, backporting and otherwise spelunking projects much easier.
To put it in your analogy, it wouldn't be fair to judge a programmer by their handwriting. But it might be fair to judge a secretary by their handwriting (you'd be annoyed if your secretary didn't write down important details, or wrote them in a way that nobody could read them).
It's not really true to say that the commit history of a project is an important aspect in regards to security. Whether it's security-sensitive or not, a project has either been audited or it hasn't. And an audit doesn't rely on commit messages.
Yes, but usually audits are of a single snapshot in the repo's history. Understanding why a change was made is quite important, especially if someone touched security-sensitive code.
This is a worthy goal as I'm sold on passwordless mechanisms too.
Not a telecom provider leaking your SMS codes,
not email provider resetting your passwords, not
Facebook Connect/Google OAuth issuing your access_token
to someone else.
We also need to consider someone who just has access to your phone unlocked .. even if it be your "harmless" kid :) It looks like in the current design, there is no additional safeguard for this - like using a device's finger print scanner.
That's an interesting recommendation that sounds valid. I'm unsure of the user experience - in particular whether a user is likely to be confused by being thrown back to the system unlock. Any notes on non-techies dealing with this in your experience?
You are right, but this is easy to solve. The less nice solution is to show a little explanation before locking the device, the better one depends on OSes. They should simply provide a way for devs to trigger the lock screen for this specific purpouse and let devs specify a message, color scheme, theme, logo, whatever that needs to feel the lock mechanism more integrated in the app.
> If email is compromised, so is the password reset mechanism.
If we didn't have online password resets then we wouldn't have to worry about the e-mail account being the weak-point.
I would argue that no service that offers an online password reset mechanism deserves it.
If I mess-up my bank login, I have to go to a branch to initiate the re-authentication process. Password in the post in secure-mail envelopes, things like that.
If I screw-up my Amazon login - well, that should really be too bad, end of story. Just create a new account. There's too much risk in having an online reset mechanism that could enable someone else to use my cards for purchases.
I'm a little unclear on how this is more than a serverless password manager with Nacl public keys instead of some symmetric algorithm generating per-site passwords.
There are lots and lots of serverless password managers, and their uptake is even lower than that of real password managers.
Is the cleverness here that this one is exploiting modern browser API to quietly embed the whole thing in localStorage so that users don't have to install it?
Thomas, many times I made a point that if auth solution is not enforceable it's not going to be popular. You like 1Password and it has reasons to be loved.
But let's take it real and look at password reuse problem. Can you admit that password managers and/or 2fa are not what we need and where we should stop for securing users?
We always needed an __enforceable__ protocol that has clear flow for the user. Button. Download, Generate profile, use to login anywhere.
I thought it was made clear that it has nothing to do with password managers. It's an authentication protocol that's 1) decentralized 2) extremely usable 3) scalable. That's all it is.
I'm not saying people should use 1Password instead of this. I'm actually not recommending anything, just trying to get my head around the concept. Reading the Github page, the impression I was left with was that this was essentially the same thing as an auto-installed site-specific serverless password manager. Is that incorrect?
It's mostly correct, but it really is not a password manager.
Manager is a helper for some people, protocol is a requirement for all. So I want to draw a line between protocol and a manager.
It's like https://getclef.com/ or SQRL or Mozilla Persona, but not exactly a manager.
By being a protocol it can be _legitimately_ deterministic (you know why deterministic managers aren't great, Tony Arcieri wrote a good post)
By being deterministic it can be absolutely free and scalable
By being scalable and free I hope it has a chance for being popular (no vendor lock-in).
No real innovation, definitely, but in little details it's a good balance of existing things.
I like the little details. And unlike Steve Gibson's SQRL--which I was trashing recently for being overhyped--you don't come off as a dick. ;)
Some questions/comments:
1. The github would be clearer (to me, anyway) if the protocol were written out in prose rather than in code. That may account for the following question:
2. It's not clear to me how the origin of the auth request is validated on the auth GET. I.e. how does the "relying party" (so to speak) validate that the SecureLogin client is following an auth link that wasn't MITM'ed by a phishing page?
3. I actually think the URI-scheme/browser-integration is a clever idea, and the UX flow seems fairly nice to me.
4. I think you're sort of kidding yourself if you say that lost-password recovery is not a big deal for big providers like Google and Facebook. For smaller providers, falling back to email verification is fine--or maybe doing nothing. Big providers offer all kinds of verification--email, SMS, domain-ownership, credit card--and a human customer support path. That doesn't change with TOTP or U2F, and wouldn't change here. Not a dealbreaker, really, but it's worth noting this weakness (lost-auth recovery) is probably here for the foreseeable future.
5. Having to enter your master password sometimes is a UX feature, not a bug--it teaches users to remember the master password. Just something to keep in mind on the client apps.
2. I'm not sure if that's what you meant but I just realized pretty bad bug in current callback=ping flow. When malicions page opens my.app for me and second later opens securelogin://#state=THEIRSTATE... so my sltoken will be matched with their state and they will log into my account. That requires good timing so not super severe but definitely will be fixed: if someone opens the app twice in a raw it will notify the user. Thanks
3. There's pretty much no alternatives working cross platform.
4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".
2: What I was trying to understand was whether a malicious site can relay the "securelogin://" challenge generated by a good site to the victim. Basically, an XSRF attack. Does the client validate the context of the challenge?
4: I don't think that's true. Gmail has a heuristic recovery based on knowledge tests. It's _easier_ if you have a backup email or SMS, but not required in all cases.
As an aside, another downside of this approach is that it requires server-side state. Not a huge deal in most cases, but it can present a scalability limit versus cookie-only (signature-based) auth schemes. If the client were able to relay cookies or redirects back to the browser--which seems like it should be possible by simply opening a redirect in the https:// scheme--you could avoid that, no?
4. Have you tried? Because they seem to ask too hard questions like exact date your account was created.
> downside of this approach is that it requires server-side state
Using key-value for delivering signed token to first request? there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one.
2. Phishing and XSRF are effectively the same in this case, no? We're talking about the phisher relaying the challenge to the victim and tricking them into posting the response--which doesn't really require phishing per se, hence the XSRF. Again, I may be misunderstanding the protocol here. :)
4. Yeah. It's a pain in the ass, but they do offer lost-password fallback. Anyway, I wasn't trying to belabor the point; just noting that big sites will probably always offer some lost-password recovery.
> there's callback=direct that opens the link instead of pinging it, but it's a huge pain to figure out which browser you used if not the default one.
Where can I read docs on the different behavior between callback=ping and callback=direct? I know I could read the source code, but I do enough of that in the office. ;)
>When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".
Have Google changed something? I had to go through account recovery a while back on a gmail account (with no backup email/number set).
They asked a bunch of questions to try and prove whether I was actually familiar with the account (when did you create the account, provide an address you've emailed more than once in the last month etc). It was a PITA, but I eventually regained access
> 4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".
Checking now, I cannot setup a gmail account without a phone number or backup email. I can also reset my password as long as I have access to my phone which is currently logged in.
> In the end of any authentication scheme there will be a password that you just cannot forget. In SecureLogin we removed unnecessary levels of "backups" and "recovery codes", our scheme boils down to one master password, not to master password and backup file/paper/SIM card/email account etc.
I don't think a backup is "unnecessary". It lowers the chance of being completely locked out.
What happens if I forget my master password? Does it mean I can never log into the sights using the same account ever again?
Backup with 3rd party == giving up access to 3rd party. #1 principle of this protocol is not giving up access, at least by default. You are free to email your password to yourself, write it on a note, but it will never offer to send your password on your phone number. We live in a hostile world.
> Does it mean I can never log into the sights using the same account ever again?
It's up to the websites, they could use your email for reset + lots of personal info you have about account activity.
Right. My point was only that most people may want a lost-password fallback; this scheme doesn't prevent implementers from providing that, so it's not really a big deal.
This is a very interesting concept. I'm pretty sensitive to UX issues, and I'm yet to see nicely implemented and secure auth flows. All non-OS-native 2FA solutions (Google Auth, Duo) seem a bit cumbersome (and require additional efforts to implement and to setup for the average user). Apple does auth right with their Touch ID (both for logging in and to confirm transactions). I see a potential for SecureLogin to be as close to that Touch ID user experience as possible.
While I see the potential, I understand that this is an initial implementation, so it has UX issues:
1. First and foremost, the user has to download an app in order to sign into your service. That's a huge ask. Service providers will be hesitant to implement this, since this will mean losing customers. The implementation has to be really polished for this to gain traction, IMO. Without getting initial traction, it's less likely that this can be implemented natively in browsers/OS, where this technology makes more sense and can have better UX. Kind of a catch 22.
2. Related to 1: A 50+MB Electron app is definitely not a casual download. It has to be as lightweight and OS-native as possible. For most likely use case (web app authentication), did you consider using browser extension that would store the data locally? Might be a good alternative to a downloadable app at least for that common use case.
3. When signing in, it asks if one has the app installed. I don't want to be asked. If the app is not there, I want to have it installed in one click, and then have the auth retried. And visiting a separate https://securelogin.pw/ site for downloads is not the best option as well. This bootstrapping process is very important. Again, a browser extension might help with this, since it can communicate with the page and make itself discoverable.
4. As I understand, Cobased is your reference demo app. As such, it needs more polishing/explanation (read: some narrative in addition to the UI).
---
And a non UX-related question: nowadays people not only value security, but anonymity as well. Does SecureLogin have to pass profile email address back to the app? Can the protocol work in the way that simply uniquely identifies the user for the target service via providing some service-unique token but not disclosing an email address? In other words, the protocol might benefit from the fact that no one can link account on service A to the account on service B.
The enterprise version of Duo apparently works by having the mobile app wake up to ask you for confirmation for the login -- similar to how Apple's Touch ID automatically opens to confirm things like Apple Pay if you initiate from the desktop -- rather than making the user open the app, select the account and generating a number.
I don't know what protocol is used, and I've never tried it, because it's not part of the single-user Duo Mobile app.
But this always struck me as a much more user-friendly way of doing 2FA than the Google Authenticator style that generates numbers that you then have to manually enter.
Yeah, I'm an every-day-user of enterprise Duo app. It is as good as a third-party app can be (on iOS specifically), yet you have to do extra steps as compared to Touch ID alone: force-press the notification, click Accept, then confirm with Touch ID. The first steps out of two are just a limitation of how apps work in iOS. If your phone is in sleep mode, you will miss the notification as well. Such things really need to be implemented on OS level.
But apart from arguably good iOS app UI, it takes the whole IT department to enable Duo 2FA and educate employees on how to enable and use it on their personal accounts, and that's what I don't like about Duo and other solutions. Also, this is just a second step of the two-factor auth, which means the first step (usually plain old username/password auth) is still there.
In my ideal world, I'd prefer something that worked out of the box (with very easy bootstrapping process). I believe SecureLogin, as a concept, has potential here, and if implemented right, might lead to some standardization and implementation of more transparent 1FA/2FA flows.
Blizzard 2FA doesn't even come up. Having it installed is good enough for automatic detection if on same device if I remember correctly. If on different devices you have to press accept or deny comparing a unique code on the app vs. On the app where you want to login. Much easier than copying the code.
1. I myself hate native apps, but the catch is web apps are 100% depended on the servers behind them. So I would be responsible for JS I serve any single request. Otherwise, Web version is fine.
Lots of catch 22. I would definitely through $10k+ on a polished UX + native app, if someone with large userbase can commit to using it. I already gave this project a TON of my time.
2. I hate that 50MB size of electron apps too. Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.
3. Actually there's amazing self-discovery iframe - https://securelogin.pw/s when in iframe it will parent.postMessage if you have a native app. But Safari does not support 3rd party iframes...
You think showing app links on the same screen is better? Good idea
4. Will improve the demo app
That's what profiles are for. If you want another identity: create another profile. It is possible to keep unlinked accounts under the same SecureLogin profile, BUT we end up with all websites asking for your E-Mail (like they need it for some reason) so that's why it is sent by default.
Real privacy is hard, it's not just different email. It's different browsing context and sometimes even VM. That's why I do not pursue paranoid level privacy, and just offer Profiles.
> BUT we end up with all websites asking for your E-Mail (like they need it for some reason) so that's why it is sent by default.
I believe that it'd better be explicit (like in OAuth, where the web service asks for a permission to access your email) and optional (defaulting to not asking for email).
Note that services usually don't need emails (at least not right away). They should also continue working just fine if the user decides not to provide their email initially — the service may ask for user's email at a later step. I also see that the similar concept might be used to ask people for or other sensitive data, like delivery/billing address and payment info; this way I as a service developer don't have to store anything on the web service at all except for the unique user token, and the user would be able to provide this information with a single click as well — same as in your demo app where the user confirms a transaction.
> Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.
I'd probably disagree here. Installing an extension is much faster/easier than a native app; it can store data in localStorage (so no centralized service is needed), it can solve your Safari-related discoverability issues, and it can provide a really nice UX for web-based service authentication with no context switching between apps. I'm not a security expert, but a browser extension storing your data locally should — theoretically — be as secure as a native app. Am I missing something here?
Would love to continue the discussion offline. Is it ok to email you?
1. This is a good point. I wonder if it might be better for the initial adoption period to build this protocol into a password manager (preferably several existing popular password managers), then market it as something sites can implement to improve UX and security for users who use password managers. (E.g. Instead of having your password manager generate a password for you when signing up, you can just click one button on the signup form and the protocol will handle everything for you. And it's more secure since the site only stores a public key instead of a password.)
Then once it gains sufficient adoption, sites would be able to slowly start phasing out the use of passwords by making the use of SecureLogin mandatory.
Tried demo on chromebook. It failed. Read github. Requires native app... written in JS? Relies entirely on single password that can be forced out of me. No mention on how to sync across devices. Nice try. I think it has a lot more to work out.
"Classic passwords/2FA are poorly designed, hard to backup and inconvenient to use."
That's insulting. Stop that. Want to state that as your personal experience, fine. You are really too young to declare that with any authority. Quote a crypto legend or take that out. You will alienate a huge pile of developers you claim to be courting.
"SecureLogin's #1 goal is to fix password reuse"
That by itself is easy to solve. Generate the password for the user.
"Usability: existing onboarding process is a disaster for conversion"
Requiring a native app is a disaster.
"Central authority"
You're confusing out of band authentication with centralization.
"no iOS support"
SecureLogin can't guarantee their native app won't be pulled from Apple's app store.
Sorry never tested on that platform. But web app must be working, just press Cancel if app is not installed. Native app is not required but recommended.
It's deterministic - enter same password, get same profile. No sync needed.
> That's insulting. Stop that
Wait, you seriously feel all these "your password must have x, y and z, confirm it, scan QR, enter digits" as convenient? Don't listen to me: watch any password manager promo video. Everyone in the world knows auth is broken.
>That by itself is easy to solve. Generate the password for the user.
Yes, but there is goal #2 and others.
>Requiring a native app is a disaster.
Necessary evil? All password managers are native apps too.
>You're confusing out of band authentication with centralization.
Verification through central authority API or gateway is also out-of-band, i.e. user<->authority<->server. These terms are not mutually exclusive.
>"SecureLogin can't guarantee their native app won't be pulled from Apple's app store."
There's no reason for this to happen, it's not an uber :) In App Store soon.
>But web app must be working, just press Cancel if app is not installed.
I want to try your thing, so I press cancel? That doesn't seem terribly intuitive. I thought your main selling point was usability.
>Everyone in the world knows auth is broken.
Auth is broken when you have a HIPAA breach. Try explaining how convenience fits in there to someone deciding if you've been negligent. It can mean the difference between prison and no prison.
>Necessary evil?
The current onboard process hurts conversion, so that's a disaster. Instead, we ask users to download an app, which they don't[1], it hurts conversion, and that's a necessary evil. A rose by any other name...
>There's no reason for this to happen
Maybe not today. Apple has the power to put any developer on their platform out of business, overnight. Apple could decide to amend their "Application may not download or install executable code" clause to include JS apps that it didn't before. They've wiped out huge swathes of apps in the past. If auth is down, the app/service is down. I'd hate to have a large portion of my customer base wiped out permanently by a policy change at Apple.
>I want to try your thing, so I press cancel? That doesn't seem terribly intuitive. I thought your main selling point was usability.
To be precise that depends on client implementation, we will use a popup that doesn't even redirect anywhere.
[1] - exactly my thoughts. Web is a good way to go, but the apps are what many security-minded folks require, so it's both.
> Apple could decide to amend their "Application may not download or install executable code" clause to include JS apps that it didn't before
I kind of support that anti Unrollme policy. They could outlaw all Cordova apps, but that would be a disaster. It makes me think to make going back to web app easier, will look for a way.
It's definitely not an easy problem. I hope I haven't come off as too harsh. Client certificates would be great. I think you write off the value of hardware tokens too quickly, but by all means, look at other ways. Auth is one of the first things any of us have to do when putting together a service. This is something a lot of us have studied for a long time. Welcome to the party :)
> Wait, you seriously feel all these "your password must have x, y and z, confirm it, scan QR, enter digits" as convenient?
Requiring certain character classes is not mandatory for a password.
The 2FA initial setup could be improved slightly, but it's not that much worse than your entire login flow, and it has actual security benefits.
> Everyone in the world knows auth is broken.
Well apparently not.
> There's no reason for this to happen
There's no reason for you to dismiss valid statements about external risks as "There's no reason for this to happen", and yet that happened, didn't it?
> Which one is your favorite?
I'm sorry, are you analysing the best open source license to use for your code, or taking a lunch order?
For this particular situation, I too would recommend Apache 2.0 over MIT. In other words, please do claim that you won't sue over patents, and that you won't be sued over patents.
Not if this is a reference implementation of a protocol that ends up built into operating systems.
If the point is to be a reference implementation, though, I'd rather it was a reference implementation of, say, better OS/browser handling, syncing, and UI for TLS client certificates.
It baffles me that no one else mentioned client certificates. That's like Crypto 101, but the author of this software seems unaware it even exists (it's not mentioned in the comparison on the GitHub page)
If everyone is already using something, then the existing implementations are probably already near-optimal, so it's hard to do better and easy to do worse. You can expend a great deal of effort in such a space and—almost all of the time—all that effort will be for naught, because your solution will end up different but not necessarily strictly better for any particular use-case.
On the other hand, if everyone agrees that a design is great in theory—but nobody is using it—then that suggests that all current implementations are crap—and so that's a great niche to innovate in. It's hard to do worse, and very easy to do better—and "doing better" is likely to turn "the thing nobody uses" into "the thing at least some people use", with your name stamped on the side in the process.
> then that suggests that all current implementations
Long story short entire concept of client certs is not as usable in terms of backups/enrollment as I want to, no matter how well dialogs are implemented.
> not as usable in terms of backups/enrollment as I want
That's what I was referring to when I said "all current implementations are crap." A better implementation would change that (by e.g. having client certs sync in browser-sync like cookies do; and sync in the OS between devices like macOS keychains do.)
>that suggests that all current implementations are crap
Except the one time I've seen it in the wild, the implementation/UX was surprisingly good. Turns out Firefox can generate a cert entirely client-side and install it via Javascript. Chrome draws from whatever cert storage the underlying OS offers, so it should be as simple as saving the cert file to disk and opening it.
Mobile might pose a problem. Would have to try it out.
I like the idea, but the master password scares me a bit. So if I accidentally type my master password into Slack one day (not that that has ever happened), it seems anyone who saw it would then immediately be able to log into every website using SecureLogin as me.
The README addresses a concern about "Master password is single point of failure in this system", but it talks about the case of a user forgetting it, not accidentally disclosing it.
I don't think this criticism is that valid. LastPass et al are the same. After years of use I have no idea how someone would do that.
It's like saying about credit cards - " but what if I randomly read the card number and pin out loud". I'm sure it could happen but it seems silly to bother criticising.
I've typed my most sensitive password on public IRC once. I assumed my screen was locked while my display came back to life after sleep mode. For some reason, my screen wasn't locked and the IRC window had the focus instead.
The great thing was that, even though that was my most sensitive password (the only that unlocks my desktop and encrypted folders), it didn't matter because all I had to do was immediately change the password in the only two places it was used.
I will never trust generation of site-specific passwords from a single master password. Too many things could go wrong. There could be a bug in the derivation algorithm, crypto might become brute-forcable, etc.
Yeah, I've done this as well. Texted someone my laptop password because the macOS beta I was using had a delayed auto-unlock bug and I thought it had failed.
You can use get it here too: first part is truly random (store it locally) second is memorable. It gives you freedom to do it your way, unlike traditional approach where you have to backup a wallet no matter what.
No, it's not the same with 1password, etc. (I'm assuming LastPass works the same way as 1Password - a master password protecting a local database of passwords). My 1Password master password is useless without my database. If I accidentally typed it into Slack, I'd just change it in 1Password.
This criticism does apply to all methods that use one master password to derive all other passwords. They necessarily have the master password as a single breaking point.
Say, Attacker knows User is a member of Site X, but Site X fails to implement checks and/or rate limits properly. Attacker brute forces master password by spamming the login endpoints.
Extrapolating: a database leak of any site means the attacked can locally brute force master passwords of all users?
Currently, such a leak means a subset of users who reuse passwords are in trouble. Widespread deployment of this kind of scheme would take away choice, and put everyone in trouble. (Unless you start using different master passwords to create bubbles, which means we're back to square one.)
I don't know if brute forcing is that much of a thread. Your password is taken through a key derivation function that takes about 20s to generate the real master key. (From what I understand).
Slightly harder but may generate some good ideas/discussion:
A two-part password (no, not two factor) where
part 1 is stored by the browser and recommended to be written down or otherwise recoverable
part 2 is remembered by the user from day to day.
Now if the user types the password into the wrong field or the keyboard is bugged they should still be fairly safe as long as part 1 is a good password on its own.
Agreed on the hygiene... However, we're humans, and even the best of us will make a mistake at some point. The impact of that mistake in that scheme seems potentially catastrophic in a way that's different from traditional password managers. I don't see an easy way to fix it given your design goals (which I really like!)
I never really tried to type my password and hit Send, so I never worried about this case. Hygiene has to be reshaped to understand how important master pw is compared to all pw we used to type, like 123456.
The times I've seen people type passwords into Slack has usually been because they had the wrong field focused, and autopilot typed the password and hit Enter.
(To be clear, this complaint applies to all schemes that rely on passwords derived from a master password.)
I've done it once before, with Keepass and Lync. I was working on several tasks at once, area bit of a frenzied pace. I had a few Lync chat Windows open. I copied my password from Keepass, alt-tabbed to what I thought was the browser, pasted and hit enter. Oops, wrong window...
I've had people paste their passwords to me a couple of times over the years too.
One clever UI way around this would be to not use Enter in the master password field.
Instead use something on the homerow like "jkl" to end every password. Then the input field just accepts whenever /.*jkl/ matches.
This mostly solves the "wrong focus" problem because hitting Enter is no longer part of the muscle memory. Of course you could still enter it into a shared Google doc or something else that discloses without Enter, so it's only a partial solution.
In the case where a master password does get disclosed (for whatever reason), how does a user change their password everywhere? I don't see anything about that in the README.
TLDR. Your technical writing is bad and it is putting lots of people off.
1. Learn to write arguments properly. Your claims are outright wrong and ridiculous. You provided no strong evidence thus just reading your blog post put off lots of people.
Examples:
"It is production-ready to be used by four Billion people by tomorrow morning" -> no, it is not. You are underestimating the time complexity of integrating your project with existing apps. Show me how many people are using SecureLogin 24 hours from now? By the way "tomorrow morning" without an exact date is vague.
"terrible usability. First one offers you to write down backup codes on a paper (which I never did)" -> use your personal anecdote as an evidence is not strong unless you show me statistics of how many people who wrote down backup code (I did).
2. Learn to write protocol documentation properly. At least include a figure of the protocol flow and pointer to your code location. No matter how interesting is your concept, many people will be put off digging through your github project to understand the protocol. Not everyone is familiar with Javascript.
Oh god, there are so many things in that post which make me sad.
> Unfortunately OWASP is out of touch with reality. First Top10 was released in 2003 and back then the web was a mess. CSRF? Everywhere. XSS? Give me a minute. SQL injection? Just try another parameter.
This is idealistic to say the least. Those things are still very much issues, and sadly are likely to continue to be for some time.
Regards 1) why do I need statistics for such self-evident things? How on Earth writing down secret codes can be called convenient? No one said yet "wait a second, I actually love all this hassle"
> You are underestimating the time complexity of integrating your project with existing apps
This is not a relevant blocker for being production-ready: websites _can_ read the docs and use it. The server could go down (valid blocker), but not that.
This is a pretty cool scheme, but I'm not sure about the UX argument. The login flow itself is good UX, but it's arguably just the happy path, and now I'm responsible for irreplaceable data on my device. My device might fall into a river, or a customs lockbox. I can mitigate that but then I'm doing manual secrets management work that "eh, I'll just trust my email provider" would have prevented.
It seems like your device is completely replaceable in this scheme. The keypair is derived solely from the email address and the master password, so you can just generate the same keypair on a new device.
There are many differences, because your password used just once to create root hash. From root hash private key is generated, and no one is sharing password anymore
Isn't that a huge usability issue? I use multiple devices, phone, laptop, desktop. How do you propose being able to log into the same website on more than one device if the key is on the original device?
Also, have you reviewed Web Authentication specification? It sounds very similar.
So, that's kind of a weird half truth. The key is determined from your email + master key, and will always be the same as long as those two details are the same. The downside, and what I'm not a fan of, is neither can be changed without massive work. At least, that's what it seems like based on the README but it might be a little vague ...
Yes! As a site admin in today's world, you should indeed not want to store passwords. Or even personal data for that matter.
I applaud this initiative since it lists exactly the reasons why we started Authentiq: Decentralization, usability, privacy, safety for end users (which is very different from merely offering security features that most people don't use).
Authentiq is similar in goals and architecture, yet with a more comprehensive feature set, since we aim to support existing standards (like OIDC) as the integration point for developers, and offer a more complete mobile identity to end users so that the site owner doesn't need to store those details either.
That said, I'm very keen to see if we can add support for the OP's authentication protocol soon. Check us out here if interested: https://www.authentiq.com/
There are probably several angles on this. One is to let our Authentiq ID mobile app support and sign in to SecureLogin sites. Another to let websites that use Authentiq automatically support sign-ins with SecureLogin. These look feasible at first sight.
A third, replacing our current auth flow with SecureLogin indeed isn't likely to work for reasons you mention.
>"Currently the only way to have safe authentication is to either enable TOTP (like Google Authenticator) or using a USB stick like U2F.
Both you need to do manually so practically nobody is doing that. They both provide terrible usability. First one offers you to write down backup codes on a paper (which I never did), second one is barely supported by anyone."
Aren't many people using Google Authenticator/Yubico/Push Duo versions of TOTP for github logins, gmail and bastion hosts? I thought this was becoming increasingly more common. At least its been pretty standard in the shops I have worked at in the last few years.
Also Github, DropBox, Fastmail, Gmail, Wordpress, Chrome, GitLab and BitBucket all have support for U2F:
Supporting != users are using it. Especially outside of tech bubble.
I myself always cringe when forced to setup TOTP. Yes, I seriously would rather take the risk of my gmail reset compromise than dealing with TOTP again.
It's number of downloads btw. Some might have downloaded it once and never used, some could have used for just one app, some removed and downloaded again.
If you hit OK that you have the client, but you actually don't, suddenly you can't do anything at all on the website... Also, imo, asking to install an app, no matter what app, is going to be way less likely to happen then any other kind of login, as I don't like putting trust in random third party software.
In addition, the web client seems defective, you "create an account", and then get a control panel, and have to go back and try the login again on the original demo. Very counter intuitive.
Thanks for a fresh look. Yes, first encounter can be putting off. Clicking "OK" makes it open local app which you don't have, but it would be silly to have "clear localStorage" button right?
3rd party software is getting better sandboxed every year, hopefully it soon will be in Mac App Store.
Counter intuitive parts of enrollment will be fixed.
Also, do all of the companies linked to on https://sakurity.com/securelogin actually support this protocol? If not, linking to that page as "Who supports SecureLogin now?" is a bit disingenuous.
Great idea! Exactly this is implemented across pretty much all "important" services in Sweden (Tax office, banks, pension funds, money transfers etc), it's called BankId: https://www.bankid.com/en/
It's a great concept but currently somewhat limited to government and financial services, I would love to see something similar get good traction!
Not another... It's more flexible kdf(site data, consumer, scope, expiration, master pwd) protocol, allows to prevent many other attacks and replace OAuth all in one.
While I understand the single master key way makes it trivial to manage multiple clients, it is a non-starter as far as I'm concerned since you cannot rotate it once you've used it as a credential on multiple services. And what about revocation? If you support neither rotation nor revocation, each credential must be independent or you are painting yourself into a corner.
Check "change password" section for rotation of one profile to another. It's quite simple
Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)
An update operation is one part of a solution. Are passwords versioned? You will eventually get into a state on some client where you have changed the pwd N times since last talking to a particular server. Does that client have to keep around N passwords to be able to update it? That defeats the purpose of rotation, which is to fully retire an old key.
I can't understand first paragraph, especially "versioned" passwords. Every profile is result of generation, and you can change profile (manually or automatically) if you think it was compromised.
With OAuth you add a lot of extra code in your app. Like storing client_id client_secret and you need grant dialogs etc. Have a look at this demo (any account with web version):
With "versioned" passwords I mean a way to detect when a site hasn't been updated after a master password change. Presumably you need the old password to generate the old key, which is used to sign the change request. If you've changed your password multiple times since you last spoke with that website, how do you know which old password to use.
You mention automation, which is good, but you may not be able to rely on it succeeding. Until every client website has responded to the change request, you must keep around or remember the old passwords.
For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central.
My point was that the protocol to "refresh" a website account with a new master pwd only solves part of the key rotation (=master password change) story.
As for OAuth, I don't agree with you that it is onerous. Yes, client_id and secret are poor mechanisms, and better ones will emerge. But there are many cases where you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant.
That's what made me confused. There is no way to "change" password, only to create a new profile and migrate to it. And you can have many profiles at the same time (some with equal email).
>For automation you also have to store the list of websites you've registered with somewhere. Since your system works on multiple clients, that place has to be central.
The plan is: until we have 1000+ origins using the protocol, there will be a manual list of origins that will be tried for reset. After that, it will be sorted out with a central server and encrypted list of origins. Sounds good?
> you absolutely want to authenticate the client (it might not always be the user's own browser) in addition to the user/grant
Cool part is you still can. Provider can look at "client" the token was issued to, and reject if it does not match with some authorized Client record in the database. It's rather flexible for any scenario.
Why is Authy called unsafe by the Author and Google Authenticator safe? Ever heard that it is more likely that your smartphone gets lost, broken and stolen than your precious online account getting hacked? I'm very happy I had Authy when I was in a foreign country and my Nexus 5X stopped working (BTW: damn you LG for your poor engineering!)
Just a few days ago I received an email from Coinbase asking to switch from Authy to Google Authenticator. The reasoning was:
> Authy and SMS are vulnerable to phone porting attacks. Device based Authenticator apps like Google Authenticator mitigate this by being linked to your device, not your phone number.
Authy is not as vulnerable as SMS to phone porting, as your TOTP secrets require a passphrase to decrypt. So even if someone ports your phone number, they'll only get your encrypted TOTP credentials.
Plus, if you do request the encrypted TOTP seeds from Authy you have a choice of 1. getting the download approved by another device already linked or 2. a 24 hour wait period during which Authy will send you an email every 6 hours.
Authy also can backup your TOTP tokens (encrypted with passphrase on device). This is super handy when switching devices, but weaker than Google Auth where the TOTP private bits never go back to Google in any form.
I think your idea is brilliant but needs a bit o polishing off.
Because every website is different everyone has different requirements, and a solution would be to just use the public key as the identifier instead of the email.
And for backup purposes as master password, I would suggest making it very similar to Trezor and generate for the user with a good RNG a 24-word mnemonic. I know is a hard task to write down for some but you don't do it every day, and you know you're safe if you lose your device or make use of it on a different device. I wouldn't want to rely on the user to memorise it or generate it, especially when users do not generate a good entropy.
I understand is a label, but some bad devs might use it as a way of matching the user, and end users might get confused especially when you can write any email as there is no verification for it in place. Let them choose it, or you make the first one to speed up the process and let them edit it if they don't like "Account 1".
In terms of master password, what do you think is easier to write down as a backup?
This: ?A[ZSOO{PBs&Y]5.6iwm=_t}]t<DOk
Or this: remove maple runway unable empty little swing zebra lava interest secret admit
To create this you can even use the bitcoin libraries, so you don't have to write your own, and you will only need to work on the clients.
If you do it similar to what Trezor did but on a desktop app, you're protocol is built for the web pretty fast. If is good for money is definitely good for Facebook/Twitter/whatever.
If you don't have a lot of experience with bitcoin, you can try to use https://copay.io/ is cross-platform, open source and very secure. Exactly what you're after from my understanding.
You can even change this remove all the bitcoin wallet stuff and make it as an authentication app. It generates the words for you and forces you to back them up to avoid any pain later on. This follows all the principles mentioned.
My initial concern was an aggressive server timeout on nginx/haproxy. I think the defaults should be long enough, but it's entirely possible to have something lower than 20 seconds. (and the app developer might not even be aware of this)
I have no reason to think it's unacceptable, was just curious. Interesting project!
Cool. I created a similar protocol a couple of years ago but it never got beyond a weekend project, see here for a diagram: https://github.com/jtwaleson/vault
The client worked with QR codes so you could login with just your phone. The app would verify authentication using a websocket/long-polling so as soon as you scanned the QR code you'd be logged in. Most banking apps now use a similar technique, which is a good UX imho.
So it needs to be done with each site. That isn't feasible. I either need to do each one individually all at once or risk forgetting the password for lesser used sites.
How does it compare with SQRL? What does SecureLogin better? It like SQRL's QR code approach very much so that you can easily go to a public computer and login by just using pointing your phone to the screen.
I've looked closely after standards in auth area and left very disappointed. They are painfully slow. FIDO is founded on 2013, and they never tried to get rid of passwords, but only sell overpriced plastic sticks. I doubt webauthn will be less bureaucratic
Interestingly, a few days ago Google Authenticator asked me if I wanted to switch to a simple confirmation (instead of manually entering the 2FA token).
So DoubleSign is pretty cool for financial apps because it signs `scope` on two devices. First prototype had that feature. But it was very unclear to the users. So it was removed, but will be added back if this 1.0 version gets used by well... anyone at all :)
I don't see any discussion about what this does besides decentralisation. Care to explain how it is securing through decentralisation? Is this some blockchain based solution?
It's essentially the offline password manager idea with some kinks worked out.
The offline password doesn't use an encrypted database, but instead used a key-derivation function based on a master password and e.g. the service name to get deterministic passwords.
In the case of a password manager, there are issues with password requirements and service name reuse. Here, by switching to a signing protocol, those issues are mitigated. At the same time, because this isn't the password protocol, it forces users to use this app. Meanwhile, you can't force users to use a password manager, leading to horrible password reuse.
The big downside I see is the immediate compromise upon revealing your master password. In the case of a PW manager, your opponent needs to get to your database first. This might give you time to roll-over your passwords.
Another thing I don't see is key-revocation. What to do when you fear your master password is compromised? That might just be done by essentially the same as a password change though.
There's a button "Change SecureLogin" which essentially replaces old pubkey with new one. One would have to do it with all services they every used, and do it before the attacker. It could be automated though.
> The big downside I see is the immediate compromise upon revealing your master password
I personally still prefer a password vault stored in the cloud combined with a strong master password.
You can quite freely backup the password vault, because pure access to it isn't the end-all-be-all. It's essentially a second factor.
I'd also like to compare this to a simpler challenge-response based protocol. Have the shared secret be e.g. SS = scrypt(hmac(passwd, serviceID)), and the challenge be nonce, to which one should respond hmac(SS, nonce).
The biggest difference I see is the issue of leaking the shared secret. It doesn't leak anything about the passwd, but compromises access to the service. If your public key leaks, that still can't be used to authenticate you with the service. If I'm not mistaken, the shared secret approach has the advantage of better privacy.
I tried the "Change SecureLogin" flow, and it's not obvious to me how that works if I'm changing my master password. It lets me select a new profile from within the app, but won't that also change my email address?
Right now email is not changed, because it's not used as primary key, it's just a label like your fullname.
After you changed you can get into the same account using your 2nd profile only. Ignore the email: site owners are free to confirm it, but playground does not.
If this protocol got implemented widely, I think there would be some value in creating an alternative app that essentially combines this with a local password database. The app could automatically generate site-specific keypairs, and you would still only need to memorize your master password.
This combination would solve the problem of your master password being disclosed (your opponent still needs to get your database), while retaining the benefit of giving sites only your public key instead of a usable password.
The biggest problem here is multi-device support. Right now you can enter the same email + mpw on a different device and it just works. Adding a local secret means you must manually transfer that to any new device.
Seems like a good feature for people with stronger security requirements (eg, journalists), but not the average user.
The nice thing about the protocol is that the client-side app can actually be replaced. All you need is something that will manage the private key(s) and properly respond to the authentication challenge through the protocol handler.
So the average user can stick with the default app, while anyone who wants more security can opt for a vault-based version. This is similar to the current state of affairs with passwords, where users can opt to use password managers.
The important thing is that sites make the shift to a challenge-based protocol. Once that's done, there are lots of different ways of implementing the client-side app, all with different trade-offs. For example, you could replace the master password with a fingerprint.
The goal is similar, but not execution. I don't know all specs of Persona - learnt about it when it was being deprecated - but the key difference SecureLogin cannot be deprecated.
"All user data stored on the persona.org services will be destroyed, including registered email addresses and password hashes"
I'm already highly sceptical because of the authors previous "solutions" for "a password replacement": just rely on one time password links via email. When the subject of mailbox security is mentioned he responds with "I'm not trying to solve that part of the problem". Right.
So of course, we get the ridiculous statements like:
- complaining that TOTP provides a system for fallback codes. The author didn't write them down, and of course they're stupid and pointless and let's quickly forget about them because his "solution" has literally no fallbacks.
- responses in this thread where the author says "well what if a bank just steals your money?", when someone mentions that even credit cards are easier to revoke: you can call the bank to cancel the card.
- responses to questions about it's open source status (because no License was specified) that seem more like a fucking lunch order at Subway: "which one is your favourite?". This leads on to one of my favourite bits in this thread:
- This absolute gem (emphasis mine), from the author who claims it's "production ready for four billion people":
> I don't want to have any rights or responsibility, just Do Whatever You Want license.
The author loves to dismiss current solutions with weird anecdotal evidence. He freely admits he doesn't use TOTP on many sites, even when it's available. He never "signs out" of applications. He claims that users "don't care" if their account on a site is breached.
For reference, the "current solution" that I believe still beats this system is:
Password managers, with a secure "master" (i.e. keychain on iOS is unlocked by TouchID/ system pin) combined with TOTP are achievable, don't rely on a fucking electron app, and provide fallbacks if a 3nd factor authentication device is lost.
But ultimately all of that is just gravy when you look at the most basic of irony in this whole thing:
The author's stated goal is to remove the need for passwords, because user's don't create strong passwords, they write them down, etc. His "solution" to that, is a system whereby users entire (for sites using this system) security is based on a single pair: email address, and a "master password" that, you guessed it - the user HAS TO REMEMBER.
I'll leave you with one final though: if this ever gets any real-world usage, how long until bad actors start gaming the system, by presenting "Proceed with SecureLogin" buttons that show a dupe of the existing web UI to convince users to enter their email/password, and then hey presto, they have access to all SecureLogin-enabled sites that user has an account on.
Today I use auth0 configured as a passwordless solution, i.e. email code + login, or use Google OAuth, etc. You can see it working on sites like https://www.lfgss.com/
I would consider another solution, but I'm not sure that this is it.
The information is sparse, as a site-owner it hasn't really sold me on:
1. how this works
2. that the first login friction for the user is low/effortless
As I understand it, this is not a "password manager", but more along the idea of a "login manager" that you install locally.
And, if you do not wish to install something locally then there is a browser bit which I think is in JS and this is "less secure" and "slower"... but this in itself puts me off the whole idea because I think the browser bit is what most people will use, and that security is fairly boolean so "less secure" probably equals "not secure". If this is just a communication of risks, then those are not being communicated.
But I'm curious enough to want to know more, so I googled, found his Twitter, looked through and saw others asking similar things to which the author response amounts to "read the code".
It feels like a poor sell, because whatever this is may well be the kind of thing I'm looking for. But I just do not know.
Changing authentication is such a big thing that I can't see me moving from passwordless auth0 unless the communication is super effective... not just for me as a site owner, but also for end users who will wonder what it is being asked of them and whether to trust it.