Passwordless authentication: Secure, simple, and fast to deploy(hacks.mozilla.org)
hacks.mozilla.org
Passwordless authentication: Secure, simple, and fast to deploy
https://hacks.mozilla.org/2014/10/passwordless-authentication-secure-simple-and-fast-to-deploy/
32 comments
I was in the beginning stages of working on an open source passwordless system like this, and this is immensely helpful to me.
I plan on using this for the small things. Want to authenticate, purchase something small, and maybe never use my service again? This lets you do that.
And if you want to create an actual account to do more advanced stuff, that is also an option.
I think a hybrid approach is very useful for outward facing web applications.
I plan on using this for the small things. Want to authenticate, purchase something small, and maybe never use my service again? This lets you do that.
And if you want to create an actual account to do more advanced stuff, that is also an option.
I think a hybrid approach is very useful for outward facing web applications.
Offering both seems reasonable. Just next to the traditional "lost password" button add a login-by-email button.
How often does a typical user use your system, and how long is the login session good for? I think I would hate such a system if it required me to check my email, say, every day or even once a week, but if it was once every month or two, I think it would be fine.
This is a fair point considering the use scenario that you describe. For other website this might look very different: Think of all those small websites for which you had to create logins but that you rarely use. They are a huge risk due to people's tendency to reuse passwords across important & unimportant sites.
For those smaller sites people might not even recognize this system as a traditional login: They simply come back to the site, are asked for their email address if they want to get back to their information, and shortly thereafter they have a link in their inbox to their details/comments/favorites/...
For those smaller sites people might not even recognize this system as a traditional login: They simply come back to the site, are asked for their email address if they want to get back to their information, and shortly thereafter they have a link in their inbox to their details/comments/favorites/...
This really affected me the one day in the past 3 years that I forgot my phone in the morning... There was one site I had enabled 2FA (two factor authentication) on that I hadn't logged in from work yet, and it was really a pain not being able to access it.
Honestly, I've been pretty happy simply using LastPass (with a really long passphrase that I haven't shared with anyone) and generating more complex passwords for sites...
Just the same, not sure what the best answer is... Especially considering shared computers, portable devices and other devices which may get stolen or hacked.
Honestly, I've been pretty happy simply using LastPass (with a really long passphrase that I haven't shared with anyone) and generating more complex passwords for sites...
Just the same, not sure what the best answer is... Especially considering shared computers, portable devices and other devices which may get stolen or hacked.
I've been very happy with LastPass too. I use it on my desktop and pay for the mobile app. But what I don't get is why we still need to use a password manager extension/app. Why isn't it built into the browser yet?
Google already has all of my passwords saved, and synchronized online across devices for whenever I use chrome (well, the passwords I used before switching to LastPass). Why can't it automatically generate secure passwords for me just like LastPass does?
Google already has all of my passwords saved, and synchronized online across devices for whenever I use chrome (well, the passwords I used before switching to LastPass). Why can't it automatically generate secure passwords for me just like LastPass does?
They're working on it!
Looks like it's enabled in the most recent version of Canary.
http://www.chromium.org/developers/design-documents/password...
http://www.chromium.org/developers/design-documents/password...
Why can't we be using client certificates generated and stored and synced this same way instead of passwords?! Imagine a world without cookies...
Because that would mean you could only log in with computers storing your cert. Passwords might have lots of drawbacks, but it allows you to log in from anywhere on any computer without any other requirements beside remembering it. I don't see this property in any of the proposed solutions to replace passwords thus far.
You remember one password... and then can access your master password list.
And where is stored this master password then? If it's on your browser/computer, it's not portable. If it's online, it's possibly less secure (especially if you're not the one hosting it). A physical token might work, but it's usually too specific and not scalable.
Nothing beats plain old password as convenience, that's why they are still so wildly used despite lousy security properties.
Nothing beats plain old password as convenience, that's why they are still so wildly used despite lousy security properties.
This. Servers are moving to SSL everywhere. Why not have client ssl certs generated when you first install a browser? No cookies, like you said, AND the servers get client authentication built in.
Personally I like that the password manager is independent from the browser. If you switch browsers it's handy to be able to take your passwords with you.
I don't know for other browsers but Safari is suggesting randomly generated password when it detects a registration forms. And it can sync everything through iCloud Keychain.
I'm actually trying to unlock myself from Chrome... although it's still my goto browser, I realized I'd fallen in heavily with Chrome, and my passwords are something I can't really share with, say my Firefox, Safari, or IE instances.
No, you're right. We have password managers built into browsers. That just doesn't work the way we'd like it to. Because of this we have the extra kludge of requiring extensions like LassPass to keep passwords safe and sync'd between browsers/devices. We know that isn't an optimal solution (but it does work...)
Instead, what we really need is some kind of identity management built into the browser. We already have something similar to this in terms of private client certificates. You could setup your browser to authenticate you to supporting websites via a client certificate. The problem is, no one is going to do that... it just isn't practical from a workflow perspective.
Instead, what I'd like to see is some kind of portable identity solution (similar to a certificate) where you could authenticate with your browser, then pass off public keys to websites. When you'd like to login, then the website queries the browser, and the browser either authenticates you by signing a message back to the server (with your private key). It could be quick and easy... hell, the major OS's now have KeyStores specifically available for just such a use-case. It just needs a spec for browsers and servers to be able to implement... if only.
It could also be a federated system setup outside of the browser, but those are also hard to get people to use (although Mozilla has done a good job in trying). My last two jobs (research universities) both had single-sign on options for web applications to use. It was wonderful. Now we just need something that the browser itself can manage.
This is a real chicken vs the egg problem, but if we could get a system like this, where we don't need passwords, life would be so much easier.
Maybe someone needs to re-invent Kerberos, or at least re-brand it :)
Instead, what we really need is some kind of identity management built into the browser. We already have something similar to this in terms of private client certificates. You could setup your browser to authenticate you to supporting websites via a client certificate. The problem is, no one is going to do that... it just isn't practical from a workflow perspective.
Instead, what I'd like to see is some kind of portable identity solution (similar to a certificate) where you could authenticate with your browser, then pass off public keys to websites. When you'd like to login, then the website queries the browser, and the browser either authenticates you by signing a message back to the server (with your private key). It could be quick and easy... hell, the major OS's now have KeyStores specifically available for just such a use-case. It just needs a spec for browsers and servers to be able to implement... if only.
It could also be a federated system setup outside of the browser, but those are also hard to get people to use (although Mozilla has done a good job in trying). My last two jobs (research universities) both had single-sign on options for web applications to use. It was wonderful. Now we just need something that the browser itself can manage.
This is a real chicken vs the egg problem, but if we could get a system like this, where we don't need passwords, life would be so much easier.
Maybe someone needs to re-invent Kerberos, or at least re-brand it :)
> I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it.
What do you think is the best alternative?
What do you think is the best alternative?
I also think that with Chrome/iCloud password storing features (and what's possible in iOS8 so apps can access credentials stored against an approved website), passwords become more secure.
For years I attempted to get my parents to use 1Password (which I've used and promoted since v2), however, with OS/browser builtin password storage, they are doing much better at not reusing weak passwords.
For years I attempted to get my parents to use 1Password (which I've used and promoted since v2), however, with OS/browser builtin password storage, they are doing much better at not reusing weak passwords.
This is interesting. A lot of social networks use this sort of authentication for their email notifications, and weekly/daily digests, but don't treat it as a first class login.
Facebook, LinkedIn, Twitter, Quora, etc... use a short expiration on these, but if you ever forward one of your new notifs to a friend, they will end up logged into your account, which is surprising. It usually only lasts for the session, and some are pretty good about double checking if you are coming from a new location or have cookies for another account set :)
For longer lasting sessions, email security seems like a big concern, especially since most people keep all their email forever (gmail) and it's easy to search through.
Facebook, LinkedIn, Twitter, Quora, etc... use a short expiration on these, but if you ever forward one of your new notifs to a friend, they will end up logged into your account, which is surprising. It usually only lasts for the session, and some are pretty good about double checking if you are coming from a new location or have cookies for another account set :)
For longer lasting sessions, email security seems like a big concern, especially since most people keep all their email forever (gmail) and it's easy to search through.
Almost :-) The tokens are one-time only. Afterwards the session is keeping track of the user. Another login requires a different token.
Regarding the emails of Facebook, etc.: Great example, actually! I guess the problem really is that they don't make it obvious to users that they actually hold an authentication token in their hands.
Regarding the emails of Facebook, etc.: Great example, actually! I guess the problem really is that they don't make it obvious to users that they actually hold an authentication token in their hands.
Yeah I assumed they were one-time only. In examples I've seen, each link had a different token, so if you forwarded something, one of the links may work if you hadn't clicked that particular one.
When ever I explain this to people, and forward them one of my notifs from Facebook, they get pretty paranoid and shocked, then eventually accept it because of the convenience :)
When ever I explain this to people, and forward them one of my notifs from Facebook, they get pretty paranoid and shocked, then eventually accept it because of the convenience :)
I do not see the benefit of this from a usability standpoint.
From a security standpoint it seems like an absolute nightmare. If you lose the password to your email you could lose access to all your accounts.
Most people do not own their own email server and so this could have catastrophic security consequences.
Of course the sites could check for IP location consistency but in order to spot security threats early you would need to track logins to multiple sites. The only way to do this would be to either give another third party company the ability to track logins and implement fail safes. At that point it begins to operate a lot like the companies which allow third party authentication through Facebook/Twitter/Email.
From a security standpoint it seems like an absolute nightmare. If you lose the password to your email you could lose access to all your accounts.
Most people do not own their own email server and so this could have catastrophic security consequences.
Of course the sites could check for IP location consistency but in order to spot security threats early you would need to track logins to multiple sites. The only way to do this would be to either give another third party company the ability to track logins and implement fail safes. At that point it begins to operate a lot like the companies which allow third party authentication through Facebook/Twitter/Email.
Considering that for most websites one can easily reset the password to your account if they have access to your email, this adds no extra security risk (for those situations which are most common websites eg. Amazon, facebook, twitter etc). So this is NOT catastrophic for security because the current situation is already like this.
For websites where security is a larger issue, this obviously wouldn't be the solution.
For websites where security is a larger issue, this obviously wouldn't be the solution.
One thing I like about having different passwords and logins for each site is that I don't have to worry about cascading failures.
This seems like it isn't getting rid of user/pass authentication, it's just pushing it onto someone else, in this case your cell or email provider.
Other users have correctly stated that this doesn't increase the attack surface, however it does increase the value of a single vector.
Please correct me if I've missed a key point in the OP, I didn't spend lots of time reading the finer points of the implementation.
This seems like it isn't getting rid of user/pass authentication, it's just pushing it onto someone else, in this case your cell or email provider.
Other users have correctly stated that this doesn't increase the attack surface, however it does increase the value of a single vector.
Please correct me if I've missed a key point in the OP, I didn't spend lots of time reading the finer points of the implementation.
Your email is already a single vector. Most sites have a "forget my password" link and all you need is the email account to reset the password and access the account.
A similar idea was discussed here (http://www.gnucitizen.org/blog/simple-universal-authenticati...) in 2008.
I think we sometimes forget the number of users who would try and get to your service, then bail because they need to boot-up Outlook, or work in a building with no cell reception.
Someone just made me aware of www.cotap.com - It's probably using a different middleware, but I think a perfect example of where passwordless login makes great sense!
This requires javascript on the client no? That's a no go for me. The little demo site fails for me.
Doesn't this mean that an attacker now only needs the password to the email account and all these passswordless services get compromised as well?
Yes. But this is the case with the current 'forgotten password' system.
Securing your email account can be done without 'only' using a password. I use 2 factor auth on my google accounts, for example.
Securing your email account can be done without 'only' using a password. I use 2 factor auth on my google accounts, for example.
Forgotten password systems are supposed to use challenge questions to authenticate the user before resetting the password. (Of course, those same sites often provide a way to reset using challenge questions and without an e-mail confirmation, which is how celebrity accounts get compromised)
As do I. But I would love to see the stats on the active account (used by a real person) vs active account with 2-factor ratio on GMail. I'm willing to bet the takeup is fairly low.
As I mentioned elsewhere in the thread, I missed the password reset link point. I stand corrected.
As I mentioned elsewhere in the thread, I missed the password reset link point. I stand corrected.
Yeah, but you're not introducing a new failure point. Most services already let you reset your password - as long as you can click a link they send to you in an email.
If you reset the password the user would notice that he can't login next time.
If you steal&delete the email with the one-time login token the user won't notice, so there is a difference...
Of course, missed that somehow.
With that out the way, this is really interesting stuff, although some people may end up with crowded inboxes.
With that out the way, this is really interesting stuff, although some people may end up with crowded inboxes.
Sure, but you're missing the bigger picture- The point is to reduce the total number of passwords a user has to manage in general. The fewer passwords you have to remember, the more likely you are to protect those few 'root identity' accounts (by using a strong auth/password).
One assumes. I am not sure that that would be the case. I remember when my non-tech friends only had email and maybe MSN and their passwords were not secure in any way, even for the time. There is more awareness now, though, so maybe.
If you have someone else's mail you can compromise standard (with password) services as well.
Except in that case you would know it got compromised.
If you reset someone else's password via email you would notice yourself when you want to login that your old password is not accepted anymore.
With these one-time auth tokens there is no way to know you got compromised, since sending another one-time token will 'just work'.
This would be great as part of a 2-factor scheme though.
This would be great as part of a 2-factor scheme though.
I really believe in Persona. This is an interesting evolution of it.
Any Passwordless dev around? Care to shime in on this?
Edit: To be more specific, "token-based auth" is an interesting take on the browser-based auth concept. I still think the latter is what will eventually be the solution to the growing auth needs of the web: Authenticate to your browser and your browser authenticates to web apps for you. We see the same thing happening on mobile with apps (eg. on Android, users log into their google account on the android system itself).
Any Passwordless dev around? Care to shime in on this?
Edit: To be more specific, "token-based auth" is an interesting take on the browser-based auth concept. I still think the latter is what will eventually be the solution to the growing auth needs of the web: Authenticate to your browser and your browser authenticates to web apps for you. We see the same thing happening on mobile with apps (eg. on Android, users log into their google account on the android system itself).
Yes, I'm a developer of passwordless.
Persona is great and similar to passwordless in a way with the only downside being the reliance on JS.
Persona is great and similar to passwordless in a way with the only downside being the reliance on JS.
Please correct me if I understood wrong: Passwordless is very different from Persona (BrowserId), in that it uses a (short-lived) bearer token. BrowserId uses asymmetric crypto to prove the ownership of a key.
Persona is no longer developed by Mozilla -- Persona team has been moved to other Mozilla projects: http://identity.mozilla.com/post/78873831485/transitioning-p...
Maintenance of Persona is funded (and staffed), new development is on a volunteer basis. However, there has been some renewed interest in hacking on the codebase (including some pretty significant cleanup). Our immediate goals are separating out Persona's various components into discrete modules and getting new contributor documentation into place.
If you're interested in diving in, join the dev-identity mailing list and drop me a line: https://lists.mozilla.org/listinfo/dev-identity
If you're interested in diving in, join the dev-identity mailing list and drop me a line: https://lists.mozilla.org/listinfo/dev-identity
Dan, what do you guys need help with? I've attempted joining you guys in the past but the IRC channel was dead for three days and the dev-identity list looks overrun with spam.
> what do you guys need help with?
I'll post some trailheads to dev-identity by Friday; we're just now rebooting some coordinated development effort. Generally speaking, our greatest challenge is an enormous amount of technical debt in the main Persona repo[0]. The cruft and complexity hinder maintenance, slow feature development, and present a huge challenge for potential contributors.
We're specifically trying to tease apart the verifier, frontend, and backend into independent components, but literally any contribution to reduce code complexity / cruft would be welcome. Some ideas: audit / upgrade our node dependencies, replace npm-lockdown with npm-shrinkwrap, try to get Persona running locally and file documentation bugs about what did / didn't work, open a random .js or .ejs file and see if you can make it less verbose or complex. All would be useful contributions.
> the IRC channel was dead for three days and the dev-identity list looks overrun with spam.
Right now our IRC coverage isn't great, but the mailing list should be better. The spam is an unfortunate side-effect of Mozilla's weird NNTP/SMTP hybrid lists -- certain incoming messages are somehow bypassing the filters set up in Mailman. I'll look into it more tomorrow.
Otherwise, if you mention my nick on IRC or GitHub, I'll see it. :)
[0]: https://github.com/mozilla/persona/
I'll post some trailheads to dev-identity by Friday; we're just now rebooting some coordinated development effort. Generally speaking, our greatest challenge is an enormous amount of technical debt in the main Persona repo[0]. The cruft and complexity hinder maintenance, slow feature development, and present a huge challenge for potential contributors.
We're specifically trying to tease apart the verifier, frontend, and backend into independent components, but literally any contribution to reduce code complexity / cruft would be welcome. Some ideas: audit / upgrade our node dependencies, replace npm-lockdown with npm-shrinkwrap, try to get Persona running locally and file documentation bugs about what did / didn't work, open a random .js or .ejs file and see if you can make it less verbose or complex. All would be useful contributions.
> the IRC channel was dead for three days and the dev-identity list looks overrun with spam.
Right now our IRC coverage isn't great, but the mailing list should be better. The spam is an unfortunate side-effect of Mozilla's weird NNTP/SMTP hybrid lists -- certain incoming messages are somehow bypassing the filters set up in Mailman. I'll look into it more tomorrow.
Otherwise, if you mention my nick on IRC or GitHub, I'll see it. :)
[0]: https://github.com/mozilla/persona/
I'm well aware it's no longer funded but it is still maintained.
While this feels similar to a password reset process, it is different:
a. you're sending the auth credentials every single time a user wants to login. If email was secure, that might be fine, but it's not.
b. On a password reset, you typically require a user to actually reset their credentials, and then allow them to continue. In this case, if someone accidentally forwards the email, or enters the wrong email address, the recipient automatically gets access to the account, no questions asked.
It is an interesting concept, though. I don't really know if I like it yet, but it's nice to see people trying to work on this problem.
a. you're sending the auth credentials every single time a user wants to login. If email was secure, that might be fine, but it's not.
b. On a password reset, you typically require a user to actually reset their credentials, and then allow them to continue. In this case, if someone accidentally forwards the email, or enters the wrong email address, the recipient automatically gets access to the account, no questions asked.
It is an interesting concept, though. I don't really know if I like it yet, but it's nice to see people trying to work on this problem.
Account recovery emails should probably use one time tokens, meaning that after you click on the link once, the link becomes invalidated. This would largely solve the issue with point b.
Not only one time tokens, but with limited life-span. So after a while the token expires and is useless. This is a must for such a scheme.
Both of these, plus a differentiator between 'current' and 'new' token requests - without that, it's an easy way to log people out of sites by simply knowing their email address. To the point about not always having access to email, it's a pretty simple denial of service vector.
Can you clarify, what you mean by "differentiator between current and new token requests"? Currently I don't exactly know which attack form you mean and how it could be prevented by such a "differentiator".
(an example would be nice)
(an example would be nice)
In general email is more protected than other passwords: people understand that they need to protect their email.
Without other tools (e.g. PGP) email is not a secure communication medium. Any email can be intercepted from any server or router it passes through between sender and recipient. This weakness has nothing to do with compromising the password of the recipients' accounts, it's a fundamental flaw in the design of email.
That's no longer true. Most end user access to email is over a secure channel (https/imap with tls). While SMTP between most servers uses TLS as well.
The problem is we don't know if the message was sent over secure channels or not. I suppose the password less scheme could refuse to work with SMTP servers that don't encrypt the traffic.
The problem is we don't know if the message was sent over secure channels or not. I suppose the password less scheme could refuse to work with SMTP servers that don't encrypt the traffic.
This does in no way prevent those servers from reading and/or altering your message.
Hint: if your provider checks your email for viruses, it must be able to decrypt them.
b.) wouldn't make a difference if the account is compromised
It would in cases where there wasn't an _intentional_ attack. If I accidentally sent a log in email to my Mom, and she clicked it, odds are she wouldn't know what was going on: there is no challenge screen asking for a new password. She's just see my account.
FD I work for a password manager...but I would still think password managers are better even if I didn't.
1) Password managers have security qualities built into them, example forced logoff after X amount of time. Someone who leaves their email up is still leaving themselves available for an account theft. The password requires a key to decrpyt. This isn't the case for email 2) Email is not meant to be secure and attempts to do so have gone pretty badly. A lot of the big email providers are leaps and bounds ahead of where they were 5 years ago but email as a whole is still broken.
I think this is really cool and has a lot of potential, but these things still need some work. You probably shouldn't be rolling this out on things that require a high level of security.
1) Password managers have security qualities built into them, example forced logoff after X amount of time. Someone who leaves their email up is still leaving themselves available for an account theft. The password requires a key to decrpyt. This isn't the case for email 2) Email is not meant to be secure and attempts to do so have gone pretty badly. A lot of the big email providers are leaps and bounds ahead of where they were 5 years ago but email as a whole is still broken.
I think this is really cool and has a lot of potential, but these things still need some work. You probably shouldn't be rolling this out on things that require a high level of security.
1 seems completely orthogonal to the issue of authentication, and I'm not sure what you mean by 2; basically every site on the internet is built on the premise that your email is secure, and again I don't see how password managers are relevant here.
Password managers are a better solution to prevent people from memorizing a lot of passowrds....Copied straight from the article "there is no risk of users reusing passwords"......That is what they have to do with this conversation.
1) isn't completely orthogonal to authentication. Good security products need to help you maintain good OpSec. Pretty much all password managers have features that try to help users maintain good OpSec and cut down on the mistakes they can make.
1) isn't completely orthogonal to authentication. Good security products need to help you maintain good OpSec. Pretty much all password managers have features that try to help users maintain good OpSec and cut down on the mistakes they can make.
Would it be better if password managers were built into devices in the first place, laptops, phones, etc.?
OS X and iOS have this, it's called Keychain, and it even works cross-device[0] totally securely[1]. Safari recently (I can't remember when) started suggesting passwords, too. Being built into the OS makes it an order of magnitude more likely to be used than a third party application, in my opinion.
[0] http://support.apple.com/kb/ht5813
[1] i.e. Apple (claims it) can't access your passwords, despite syncing them across devices.
[0] http://support.apple.com/kb/ht5813
[1] i.e. Apple (claims it) can't access your passwords, despite syncing them across devices.
Yes, password managers are absolutely the better solution, if we can convince every person to use one :-)
How about a review of the top password managers.
I've been using Keeper but the last software update spooked me (couldn't access db). Thinking about migrating to LastPass. Ideally want to store more than just passwords. For example, images of personal and business documents.
I've been using Keeper but the last software update spooked me (couldn't access db). Thinking about migrating to LastPass. Ideally want to store more than just passwords. For example, images of personal and business documents.
[deleted]
Using SMS for this may work better than email. Email passwordless tends to get bogged down in little problems. Like the email is slow or goes to the spam folder. Or on mobile, clicking a link in an email may not take you into the web browser you actually want to use the app in. SMS at least should improve on these two problems.
Passwordless would allow you to do that quite easily. Only risk are the shorter tokens (can be balanced by shorter validity, though). There is a short description of how to do it in the documentation
Is there any advantage of this over using Oauth to 'Sign-in with Google/FB' other than being platform agnostic? similar workflow except tokens are being exchanged between server-server vs sever-email.
No, except that SSO via such a service is more secure than the email approach. However, being platform agnostic is quite an important reason.
A lot of times websites start requesting permission to know your name. With email only, they wouldn't have the option.
The very website they link to [1] via its HN thread [2] states correctly that:
"No, email is not a secure medium. It was never designed to be one. It’s susceptible to Man In The Middle (MITM) attacks and a slew of other issues. Users might also have their email accounts abused or hacked into (how many people do you know who have left their GMail logged in on a public computer?). And what about if their email provider gets hacked or their backups stolen?"
Mozilla should know that email is not an adequate medium for one-time password delivery.
They are replacing strong authentication (2 factors) with its second factor alone.
[1] http://plaintextoffenders.com/faq/devs [2] https://news.ycombinator.com/item?id=7943365
"No, email is not a secure medium. It was never designed to be one. It’s susceptible to Man In The Middle (MITM) attacks and a slew of other issues. Users might also have their email accounts abused or hacked into (how many people do you know who have left their GMail logged in on a public computer?). And what about if their email provider gets hacked or their backups stolen?"
Mozilla should know that email is not an adequate medium for one-time password delivery.
They are replacing strong authentication (2 factors) with its second factor alone.
[1] http://plaintextoffenders.com/faq/devs [2] https://news.ycombinator.com/item?id=7943365
> They are replacing strong authentication (2 factors) with its second factor alone.
Are they? They don't mention anything about replacing 2 factor here.
A typical login is compromised if you know the password or if the email is compromised. This is not increasing the attack surface.
Are they? They don't mention anything about replacing 2 factor here.
A typical login is compromised if you know the password or if the email is compromised. This is not increasing the attack surface.
One problem is that SMTP itself [1] is just a plaintext email format. Sure, you can send it over a secure connection and most do, but that's left completely up to the provider to decide and therefore never guaranteed.
[1] https://www.ietf.org/rfc/rfc0821.txt
[1] https://www.ietf.org/rfc/rfc0821.txt
This is by no means a very secure option but do you really care if your www.anime-planet.com or konachan.com account don't use 2 factor authentication.
Some websites just don't need such a high level of security plus you could argue they are probably less careful with your password than say Google is with your email.
Now it can still be hacked but you could argue this is probably an increase in security although it does create a central point of failure just like password managers.
Nobody says Google or Amazon should start using this but websites with a lower requirement of security shouldn't inconvenience their users unnecessarily.
If you're only need is to identify the user for something banal that couldn't do much damage if it gets hacked then this is a good solution.
Some websites just don't need such a high level of security plus you could argue they are probably less careful with your password than say Google is with your email.
Now it can still be hacked but you could argue this is probably an increase in security although it does create a central point of failure just like password managers.
Nobody says Google or Amazon should start using this but websites with a lower requirement of security shouldn't inconvenience their users unnecessarily.
If you're only need is to identify the user for something banal that couldn't do much damage if it gets hacked then this is a good solution.
I'm liking this:
https://fidoalliance.org/adoption/video/how-the-nok-nok-solu...
Or this maybe: https://www.grc.com/sqrl/sqrl.htm
It's a QR-based system, but according to that page it says it can work via a tap or click on the QR code, too. So you don't have to point a camera at the QR code.
https://fidoalliance.org/adoption/video/how-the-nok-nok-solu...
Or this maybe: https://www.grc.com/sqrl/sqrl.htm
It's a QR-based system, but according to that page it says it can work via a tap or click on the QR code, too. So you don't have to point a camera at the QR code.
Yup, similar to SQRL, and here are implementations of it...
https://www.grc.com/sqrl/implementations.htm
Wordpress, Android, .Net Client, Node, PHP, Ruby, Windows Phone, and Haskell. Unfortunately, having people download an app to login to your website kind of ups the bar a little. Still, they can just scan the code with their phone as well.
https://www.grc.com/sqrl/implementations.htm
Wordpress, Android, .Net Client, Node, PHP, Ruby, Windows Phone, and Haskell. Unfortunately, having people download an app to login to your website kind of ups the bar a little. Still, they can just scan the code with their phone as well.
This looks suspiciously like OpenID with the identifiers changed from URLs to email addresses and updated to use modern pop development tools.
I really liked OpenID, even though it had a few issues. The best part was that you could put a few HTML tags at the URL you used as your identity and delegate the authentication - but not the identity - to a 3rd party. Because you controlled the identity, you could drop the 3rd party and use someone else (or implement the OpenID protocol yourself locally) just by changing some tags.
If "Passwordless" can provide this can provide the same level of autonomy, it could easily become my authenticator of choice.
It looks like it's tied to an email account? Slightly annoying, but trivially worked around if necessary.
I really liked OpenID, even though it had a few issues. The best part was that you could put a few HTML tags at the URL you used as your identity and delegate the authentication - but not the identity - to a 3rd party. Because you controlled the identity, you could drop the 3rd party and use someone else (or implement the OpenID protocol yourself locally) just by changing some tags.
If "Passwordless" can provide this can provide the same level of autonomy, it could easily become my authenticator of choice.
It looks like it's tied to an email account? Slightly annoying, but trivially worked around if necessary.
I don't know how it's implemented, but I see no reason why adding/removing emails to/from an existing account (while logged in) wouldn't be trivial to implement.
The only thing you need to be careful with is to send a notification to the email being removed, send notification to all emails when a new one is added, and enforce some kind of expiry period before a removed email becomes inactive/added email becomes active.
The only thing you need to be careful with is to send a notification to the email being removed, send notification to all emails when a new one is added, and enforce some kind of expiry period before a removed email becomes inactive/added email becomes active.
It is not necessarily linked to an email account. It's up to the lookup middleware that has to be programmed by the implementer how to translate the login into an email address / phone numbers
One of drawbacks of this mechanism compared to Persona is that a web server needs to be configured to send emails with tokens using site's own email credentials. This isn't easy to setup reliably for a small site. A malicious user can easily trick the server to send many tokens to different accounts and cause the sending email to be included on spam blacklists.
How is that different from registering many user accounts with many different emails, or using the "Forgot Password" feature using many different emails?
If you use Persona, the site doesn't need to send any emails (As I wrote this is a drawback in comparison to Persona, a traditional password based mechanism has the same problem).
Is this the fourth or fifth try of Mozilla to replace passwords? Surely it will work _this_ time…
Edit: …which makes it totally sensible to invest time building your site up relying on this stuff.
Edit: …which makes it totally sensible to invest time building your site up relying on this stuff.
I only hope that an intention of this project isn't to "smoothly" kill support for Persona. From a PR perspective this could look nicely: we kill the project that you depend on, but here is some quite inferior alternative that has zero maintenance cost for us.
I don't believe that's at all the intention. However, I am quite interested in this approach, and will be watching Webmaker closely as they roll out a similar scheme. If it works, I'd likely be in favor of transitioning the Persona fallback from long-lived passwords to single-use email tokens. After discussion on the mailing list, of course.
(FWIW, dochtman and I maintain Persona)
(FWIW, dochtman and I maintain Persona)
>Is this the fourth or fifth try of Mozilla to replace passwords?
No. https://news.ycombinator.com/item?id=8459114
No. https://news.ycombinator.com/item?id=8459114
I implemented something like this as an alternative to the OpenId logins when I was at Fast Company. I believe it's still in use there if you click the person icon to login at the top right, select other options, and then "send me a one time link". Try it out?
We did this because we had people that didn't have Twitter or Facebook logins and needed to use some service that we had. I didn't want to build out a password database so came up with this work around.
Surprisingly we didn't receive that much hate mail about it, and we have a fair amount using it per day, so I'd say that people like it.
We did this because we had people that didn't have Twitter or Facebook logins and needed to use some service that we had. I didn't want to build out a password database so came up with this work around.
Surprisingly we didn't receive that much hate mail about it, and we have a fair amount using it per day, so I'd say that people like it.
The main problem I have with this approach is a theoretical one: What if I can't get a cell phone or permanent email address?
You have to pay to have a phone and possibly have approval from the network/government to join.
Email is a lot better since it's a totally open network. However, Even then I'm leaving myself open to MITM attacks, being locked out of my email by government orders, ISP complaints, company lawsuits.
I will never be locked out of my passphrase.
With that said, after almost creating swiftlogin to do this very thing, I would support this effort as long as this does not become the one true way.
You have to pay to have a phone and possibly have approval from the network/government to join.
Email is a lot better since it's a totally open network. However, Even then I'm leaving myself open to MITM attacks, being locked out of my email by government orders, ISP complaints, company lawsuits.
I will never be locked out of my passphrase.
With that said, after almost creating swiftlogin to do this very thing, I would support this effort as long as this does not become the one true way.
[deleted]
Previous HN discussion: https://news.ycombinator.com/item?id=8446232
A major drawback here is that it's incompatible with password managers which are a better, more generally-applicable solution. Relying on email means that if your email delivery is high latency or having an outage or an aggressive spam filter then your account access in impacted. Keep in mind not everyone gets their email right away -- many people (my mom) are on >10 minute pull intervals.
A major drawback here is that it's incompatible with password managers which are a better, more generally-applicable solution. Relying on email means that if your email delivery is high latency or having an outage or an aggressive spam filter then your account access in impacted. Keep in mind not everyone gets their email right away -- many people (my mom) are on >10 minute pull intervals.
I agree, that eMail as transport media is far from optimal, but it is the only general available media currently.
I still think that from the point of usability a passwordless solution is better for many applications, where security is not the top priority.
Because so many applications in the web force you to have a password, security in general is at risk. Most people get tired of passwords and use either bad passwords or just one for all. And those passwords are endangering those applications that are really security sensitive.
I would rather like to see, that only a few services (like banks, ...) want to have a password and the others just authenticate their users with less intrusive means.
I still think that from the point of usability a passwordless solution is better for many applications, where security is not the top priority.
Because so many applications in the web force you to have a password, security in general is at risk. Most people get tired of passwords and use either bad passwords or just one for all. And those passwords are endangering those applications that are really security sensitive.
I would rather like to see, that only a few services (like banks, ...) want to have a password and the others just authenticate their users with less intrusive means.
> Most people get tired of passwords and use either bad passwords or just one for all.
That is what password managers fix. iCloud Keychain has gone a long way towards mainstreaming this. It's built in to Safari and securely stored, encrypted with your OS/device's master password -- which is an improvement on Firefox & Chrome's approach, where master passwords are optional.
From a usability standpoint that email method is way worse, at a minimum due to the latency issues. Waiting a minute for an email to arrive can feel like an hour when you're trying to log in to do something urgent. Password managers work "magically".
For a security standpoint the email method is also worse, because it is only usable with very long-lived sessions -- which is not the best security practice. The article even heavily qualifies this method as not appropriate for sites users "visit frequently".
So by the author's own logic, this method is only appropriate for sites that NO users visit frequently. Which is no sites.
Finally, the nail in the coffin for the email approach is that it's incompatible with the more general password manager solution. So those users who do need to visit a given site frequently can't use a password manager (at least without redirecting themselves to an alternative method, which is also poor usability).
That is what password managers fix. iCloud Keychain has gone a long way towards mainstreaming this. It's built in to Safari and securely stored, encrypted with your OS/device's master password -- which is an improvement on Firefox & Chrome's approach, where master passwords are optional.
From a usability standpoint that email method is way worse, at a minimum due to the latency issues. Waiting a minute for an email to arrive can feel like an hour when you're trying to log in to do something urgent. Password managers work "magically".
For a security standpoint the email method is also worse, because it is only usable with very long-lived sessions -- which is not the best security practice. The article even heavily qualifies this method as not appropriate for sites users "visit frequently".
So by the author's own logic, this method is only appropriate for sites that NO users visit frequently. Which is no sites.
Finally, the nail in the coffin for the email approach is that it's incompatible with the more general password manager solution. So those users who do need to visit a given site frequently can't use a password manager (at least without redirecting themselves to an alternative method, which is also poor usability).
This is a circular thinking: Password managers are superior to this approach, because this approach is not compatible to password managers, the "more general" solution.
It is like saying: "We need tv sets because tv sets are the only (valid) means of entertainment."
It is like saying: "We need tv sets because tv sets are the only (valid) means of entertainment."
Absolutely false. Password managers are superior because they don't suffer the vulnerabilities I listed with email: high latency, outages, spam filters, and less secure long-lived sessions.
I already understood your point, but your argumentation is a little to black and white at times.
The FIDO alliance has a working solution to the annoyance of the 2nd factor. It requires mobile device support or a hardware token (Yubikey Neo as of October supports the FIDO protocol), but it's much better than standard existing 2-factor because it doesn't require typing in a code from a dongle or app. Instead, the app or dongle authenticates directly once user presence (or in some cases, depending on the dongle or app, biometrics) are confirmed.
That means, for low-security applications, users can reuse passwords, or not have passwords, using only this second one-time-password factor, as long as they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery protocols are at the discretion of different services, but a recovery code that you keep in a secure location is one way way to do it, or emails or text messages for less secure applications).
For high security applications, it avoids the annoying scrolling through a list of 2-factor accounts to get the right code, then typing it in manually.
Email or text message, even if secure (text messages are not, and emails are probably not) require internet access. Mobile internet access isn't always available when logging into a service from some other device that has a different internet connection. Similarly, the mobile network (for text messages) is not always available, either. Even if it's done through email, email service might be down; the machine used to login could be compromised so you wouldn't want to input your (hopefully very secure) email password on the same machine you're using to access some other service. If you don't have internet access via a separate more trusted device, the rationale for having 2 factor is weakened.
A good presentation on FIDO is here: http://www.yubico.com/2014/07/future-online-authentication/
There's nothing preventing a FIDO-enabled service from also using email or text message for users that don't have FIDO devices, and account recovery can be done via recovery code, text, email, backup FIDO device, phone call, or a combination. It's all up to the service.
That means, for low-security applications, users can reuse passwords, or not have passwords, using only this second one-time-password factor, as long as they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery protocols are at the discretion of different services, but a recovery code that you keep in a secure location is one way way to do it, or emails or text messages for less secure applications).
For high security applications, it avoids the annoying scrolling through a list of 2-factor accounts to get the right code, then typing it in manually.
Email or text message, even if secure (text messages are not, and emails are probably not) require internet access. Mobile internet access isn't always available when logging into a service from some other device that has a different internet connection. Similarly, the mobile network (for text messages) is not always available, either. Even if it's done through email, email service might be down; the machine used to login could be compromised so you wouldn't want to input your (hopefully very secure) email password on the same machine you're using to access some other service. If you don't have internet access via a separate more trusted device, the rationale for having 2 factor is weakened.
A good presentation on FIDO is here: http://www.yubico.com/2014/07/future-online-authentication/
There's nothing preventing a FIDO-enabled service from also using email or text message for users that don't have FIDO devices, and account recovery can be done via recovery code, text, email, backup FIDO device, phone call, or a combination. It's all up to the service.
Sorry, I don't watch hour-long presentations when all I want is a bullet list of features and requirements. So I have no idea how FIDO actually works.
Here's what I will say: the best combination of security and usability would come in the form of an app that bridges an automatic communication (such as from an SMS, e-mail, or existing [https?] connection) to a TOTP token provider (either in software or hardware) and a prompt to the user to submit the token over a secured connection to the requesting provider. For internet-less use, you'd simply generate and copy the token the way Google Authenticator works now.
From the looks of the NEO & U2F yubico page, it sounds like this is similar to what they're going for; is that correct?
Here's what I will say: the best combination of security and usability would come in the form of an app that bridges an automatic communication (such as from an SMS, e-mail, or existing [https?] connection) to a TOTP token provider (either in software or hardware) and a prompt to the user to submit the token over a secured connection to the requesting provider. For internet-less use, you'd simply generate and copy the token the way Google Authenticator works now.
From the looks of the NEO & U2F yubico page, it sounds like this is similar to what they're going for; is that correct?
It uses asymmetric crypto. It generates a unique keypair for each service you register with, each key linked to a specific dns or service domain. It uses USB or NFC (and requires app, i.e. browser, support) rather than displaying a code and having the user type it in somewhere. The app or hardware key confirms user intent (by requiring a button-press or sampling biometrics), so for example a plugged-in NEO won't auto-authenticate to a site. Beyond that, it works pretty much how you'd expect.
Adding FIDO 2-factor to a service, when the browser/app stack supports FIDO, is as simple as adding a prompt and button press on the NEO to the process (either account setup, adding 2nd factor, or during login, it makes no difference). All the details of creating a keypair or authenticating to a service using a key associated with that service are under the hood.
There's nothing preventing FIDO devices from having additional requirements. They could require a PIN. They could require biometrics. They don't have to be a separate minimal hardware dongle (although, obviously, for the best security, you'd want them to be). (The S5 Paypal + FIDO demo uses the phone itself as a FIDO device, and a fingerprint swipe.)
Adding FIDO 2-factor to a service, when the browser/app stack supports FIDO, is as simple as adding a prompt and button press on the NEO to the process (either account setup, adding 2nd factor, or during login, it makes no difference). All the details of creating a keypair or authenticating to a service using a key associated with that service are under the hood.
There's nothing preventing FIDO devices from having additional requirements. They could require a PIN. They could require biometrics. They don't have to be a separate minimal hardware dongle (although, obviously, for the best security, you'd want them to be). (The S5 Paypal + FIDO demo uses the phone itself as a FIDO device, and a fingerprint swipe.)
Cool. So it is similar to what I describe, with perhaps one or two differences. For example, you say it requires app support, so.... if you're logging in through your desktop, does your desktop app need to support it? Or can your mobile handle the authentication independent of your desktop?
The reason I ask is that requiring one device to complete the authentication is less secure than two independent devices. While it's great that the NEO can plug into your desktop to auth with the browser, or that NEO plugs into your mobile to auth a mobile app, what I actually want is to start authentication on the desktop and finish it on the mobile, independently.
The reason I ask is that requiring one device to complete the authentication is less secure than two independent devices. While it's great that the NEO can plug into your desktop to auth with the browser, or that NEO plugs into your mobile to auth a mobile app, what I actually want is to start authentication on the desktop and finish it on the mobile, independently.
I don't know if that's possible with the protocol.
I guess it would require associating a key with a kind of authentication API endpoint for that service, stored on the device, and forcing the service provider to maintain that authentication API url indefinitely (or would have to force regenerating 2-factor keys when the auth endpoint changes).
It would also require that your FIDO authentication device has separate internet access (either itself or by proximity/connection to a smartphone). That's unreliable, and one of the reasons I hate it when routine authentication tokens have to be sent from the service over data links. It also takes additional effort to pick up your phone, unlock it, get to a FIDO middleware app, select the site you're authenticating to, and then completing the authentication. I don't even know if that's possible... it would require a device (computer or smartphone) to be able to enumerate accounts stored on, for example, a FIDO hardware token. That "feature" could be bad. It would also have to violate the (typical?) FIDO protocol where a hardware token is responding to a specific authentication challenge. Sending authentication authorization blind, which would be required if it were sent out-of-band from a different device, breaks the continuous thread of login attempt, then challenge, then response, then mark the user logged in [and set a browser cookie]. The separate device authenticating out of band can't know that there was even a login attempt. It could be sending authentication tokens continuously, only restricted by service-side rate limits.
> requiring one device to complete the authentication is less secure than two independent devices
What security vulnerability is there with using the same internet-connected device to authenticate with the FIDO 2nd factor, that can't also be done by malware waiting until after authentication and hijacking or doing malicious things with the account then? Is your concern about malware on the computer compromising the hardware token? Malware on a smartphone could compromise a hardware token too, in that case.
I think there's a much bigger problem: FIDO implementations that don't have a separate hardware dongle; for example, using a Samsung S5 to log into some service, and using a FIDO-enabled app that stores credentials in normal private app storage space on the S5 itself. A secure computing enclave (like on Apple phones, does the S5 or any android have that) makes that marginally acceptable, but far from ideal.
I guess it would require associating a key with a kind of authentication API endpoint for that service, stored on the device, and forcing the service provider to maintain that authentication API url indefinitely (or would have to force regenerating 2-factor keys when the auth endpoint changes).
It would also require that your FIDO authentication device has separate internet access (either itself or by proximity/connection to a smartphone). That's unreliable, and one of the reasons I hate it when routine authentication tokens have to be sent from the service over data links. It also takes additional effort to pick up your phone, unlock it, get to a FIDO middleware app, select the site you're authenticating to, and then completing the authentication. I don't even know if that's possible... it would require a device (computer or smartphone) to be able to enumerate accounts stored on, for example, a FIDO hardware token. That "feature" could be bad. It would also have to violate the (typical?) FIDO protocol where a hardware token is responding to a specific authentication challenge. Sending authentication authorization blind, which would be required if it were sent out-of-band from a different device, breaks the continuous thread of login attempt, then challenge, then response, then mark the user logged in [and set a browser cookie]. The separate device authenticating out of band can't know that there was even a login attempt. It could be sending authentication tokens continuously, only restricted by service-side rate limits.
> requiring one device to complete the authentication is less secure than two independent devices
What security vulnerability is there with using the same internet-connected device to authenticate with the FIDO 2nd factor, that can't also be done by malware waiting until after authentication and hijacking or doing malicious things with the account then? Is your concern about malware on the computer compromising the hardware token? Malware on a smartphone could compromise a hardware token too, in that case.
I think there's a much bigger problem: FIDO implementations that don't have a separate hardware dongle; for example, using a Samsung S5 to log into some service, and using a FIDO-enabled app that stores credentials in normal private app storage space on the S5 itself. A secure computing enclave (like on Apple phones, does the S5 or any android have that) makes that marginally acceptable, but far from ideal.
This actually makes malware less of an issue, because you'd need to target both a desktop and a mobile device of a particular user in order to MITM. The only things that are happening 'automatically' is the request being sent to the user's mobile device, and the entire process can be verified cryptographically to ensure an attacker doesn't send a false request.
You're not sending authorization "blind", though. You have to request the login from one device with a password, and approve it from another with a button push. In this way, only logins that you requested get sent to you, and only requests you approve get sent back, and both devices would have to be hacked by an attacker to intercept either part of the authentication process. Well, unless they both have your cracked password and inject malware on your mobile. Perhaps putting the button-pressy part on the hardware keyfob is safer :)
Even if none of this were cryptographically signed, look at the typical 2-factor SMS with this process. A user attempts a login and a text is sent to them with a code. The user then puts this code back into the login screen and presses return. If they could simply press a button on their phone they could approve the login without having to type the code in. Of course, we want to require a button press, because an automatic login means anyone who initiates the login (like an attacker with a stolen password) could log in automatically. And what i'm proposing is basically this, but with actual secure connections instead of SMSes or e-mails, and the ability to confirm on the device that the request was legit and not part of an elaborate phishing expedition.
All of this would work without a data connection because you could use QR codes to enter the challenge token into the device and it would spit out the response in a variety of formats.
(HTTPS)
Client -> Server: LOG ME IN PLEASE
Server -> Client: Do you have a cookie?
Client -> Server: NO, BUT HERE's MY PASSWORD
Server -> Client: I've just sent you a request for an additional auth token. Please confirm it to log in. And please stop shouting.
(Email, SMS, HTTPS)
Server -> Client's Mobile Device: Here's a token. Sign it with some crap you've already got and give it back to me.
CMD generates new token after confirming origin of original request; uses software, or talks to hardware token.
(App, Website)
CMD -> User: IS THIS REQUEST OKAY? CAN I SEND THIS THING?
User -> CMD: Yeah sure, I requested this login. *pushes button*
(HTTPS)
CMD -> Server: HERE'S YOUR NEW SIGNED TOKEN
Server -> CMD: Thanks. Here's a cookie to remember me by.
Server -> Client: Page refresh! We got the right token from your mobile device, so here's your new cookie, you're logged in.
You're not sending authorization "blind", though. You have to request the login from one device with a password, and approve it from another with a button push. In this way, only logins that you requested get sent to you, and only requests you approve get sent back, and both devices would have to be hacked by an attacker to intercept either part of the authentication process. Well, unless they both have your cracked password and inject malware on your mobile. Perhaps putting the button-pressy part on the hardware keyfob is safer :)
Even if none of this were cryptographically signed, look at the typical 2-factor SMS with this process. A user attempts a login and a text is sent to them with a code. The user then puts this code back into the login screen and presses return. If they could simply press a button on their phone they could approve the login without having to type the code in. Of course, we want to require a button press, because an automatic login means anyone who initiates the login (like an attacker with a stolen password) could log in automatically. And what i'm proposing is basically this, but with actual secure connections instead of SMSes or e-mails, and the ability to confirm on the device that the request was legit and not part of an elaborate phishing expedition.
All of this would work without a data connection because you could use QR codes to enter the challenge token into the device and it would spit out the response in a variety of formats.
I don't think FIDO conflicts with what you want to do. It simply doesn't mandate it.
If you wanted a 2nd channel confirmation like that, I suppose you could set up the service to link a mobile device (there might even eventually be some FIDO app that accepts FIDO challenge push notifications in a way that's not service-specific). Then FIDO would be used exclusively on the second channel (parenthentical stages 2, 3, 4 in your example). The web interface in that kind of setup would have nothing to do with FIDO.
I don't understand the MITM malware threat model you're envisioning that can hijack an in-band public key crypto exchange, but that can't simply hijack the session on the browser after you've completed (validly) the out of band verification.
Some of the complexity of FIDO is there to enable reasonably secure single-channel authentication (as might be expected, there are trade-offs between easy SSO and subdomain/origin policy security). But I think FIDO would still be valuable if you wanted to do out of band confirmation without a browser. The hardware dongles are standardized (although the requirements to unlock a key can vary from a button press like on the NEO to, hypothetically, biometrics in advanced dongles). Mobile apps would also be standardized, much like TOTP is now, so you could use any FIDO app with any FIDO dongle (or no dongle, if an app offers less secure on-phone secret storage). Without a hardware standard, you either have to store secrets on the mobile device, or you run into the existing problem of needing N hardware dongles for N services.
If you wanted a 2nd channel confirmation like that, I suppose you could set up the service to link a mobile device (there might even eventually be some FIDO app that accepts FIDO challenge push notifications in a way that's not service-specific). Then FIDO would be used exclusively on the second channel (parenthentical stages 2, 3, 4 in your example). The web interface in that kind of setup would have nothing to do with FIDO.
I don't understand the MITM malware threat model you're envisioning that can hijack an in-band public key crypto exchange, but that can't simply hijack the session on the browser after you've completed (validly) the out of band verification.
Some of the complexity of FIDO is there to enable reasonably secure single-channel authentication (as might be expected, there are trade-offs between easy SSO and subdomain/origin policy security). But I think FIDO would still be valuable if you wanted to do out of band confirmation without a browser. The hardware dongles are standardized (although the requirements to unlock a key can vary from a button press like on the NEO to, hypothetically, biometrics in advanced dongles). Mobile apps would also be standardized, much like TOTP is now, so you could use any FIDO app with any FIDO dongle (or no dongle, if an app offers less secure on-phone secret storage). Without a hardware standard, you either have to store secrets on the mobile device, or you run into the existing problem of needing N hardware dongles for N services.
Kudos to Mozilla for trying a new way to simplify passwords. Very similar to something we implemented at Shop It To Me in June and that appeared in Hacker News. Here's the link with the conversation: https://news.ycombinator.com/item?id=7818584
And here's the announcement. http://blog.shopittome.com/2014/05/29/bye-bye-passwords/
Overall it has worked very well for us and is no less secure in my opinion than all the reset password options. 2-factor authentication is still better though and should be used for the sites requiring the most security.
And here's the announcement. http://blog.shopittome.com/2014/05/29/bye-bye-passwords/
Overall it has worked very well for us and is no less secure in my opinion than all the reset password options. 2-factor authentication is still better though and should be used for the sites requiring the most security.
It's not a Mozilla solution, though, says the developer :-) Hacks is simply publishing about it
There are a lot of websites that are not worth the hassle of registering for, but this can make registering on them easy and they may get more registrations.
For important accounts I would still prefer a password only stored in your head and two phase authentication. But for various forums, this type of a setup is better than using third party password manager or same-username-password combination for general purpose.
For important accounts I would still prefer a password only stored in your head and two phase authentication. But for various forums, this type of a setup is better than using third party password manager or same-username-password combination for general purpose.
Great idea, I can see that this would be awesome on services I use seldom and often forget my password anyway. But do the average user really care enough to bother with email? or for SMS, will they give away their phone number?
Remembering users for a long time also opens up for other breaches. Anyway it is awesome that people are working alternatives!
I've tried throw-away email based passwords twice in the last five years. Every time I try it I run into the same problem: guaranteed speed and guaranteed delivery of email (both in general and that it'll always arrive in the inbox).
Average users get annoyed very quickly when they have to wait even minutes for an email to show up.
I still run into this problem even when using quality services such as Mailgun.
For this approach to work, it requires at least three things
1) Much greater security for email
2) Guaranteed speed of delivery for every email, such that the throw-away password arrives in seconds at a 99.x% rate
3) Guaranteed delivery, such that throw-away passwords arrive in the inbox at an extremely high rate of success (at least 99.9%)
Email will never be able to deliver on these requirements. As such this system will never be effective for deployment on a service that average users use.
Average users get annoyed very quickly when they have to wait even minutes for an email to show up.
I still run into this problem even when using quality services such as Mailgun.
For this approach to work, it requires at least three things
1) Much greater security for email
2) Guaranteed speed of delivery for every email, such that the throw-away password arrives in seconds at a 99.x% rate
3) Guaranteed delivery, such that throw-away passwords arrive in the inbox at an extremely high rate of success (at least 99.9%)
Email will never be able to deliver on these requirements. As such this system will never be effective for deployment on a service that average users use.
I think a good middle ground would be to implement this idea into a password manager. You have one strong password to unlock your manager. Sites that support passwordless Would send it to the password manager. Otherwise use it as normal. As long as the password manager is supported on all platforms I think this would be the best solution. As for how it would communicate I always prefer pull rather than push.
Passwordless logins, as implemented today, are less secure than password logins.
Flaws in the passwordless login system:
1. Authentication is done on unsecured connections. With all of the shouting over privacy and security, here we are abandoning secured, encrypted connections for SMSes and e-mail, two unencrypted, unauthenticated, somewhat unreliable, easily intercepted, plaintext messaging systems.
2. Replacing an out-of-bound token with one stored purely online. Any actor who controls the network (or your computing device) can subvert the login.
3. Depends on a pre-existing authentication, which itself uses passwords (or none at all), leaving you at the exact same state of security as you had before. Instead of two passwords that are the same, you have one password (the e-mail password) that is the same, or zero authentication with SMS.
4. No mandate for multiple-factor auth, nor out-of-bounds auth.
5. Zero security for the tokens (cookies) stored on the user's system, so data at rest is at risk, unless your browser encrypts cookies with a master password. Of course this is moot considering the total lack of encryption on the smtp/sms side and the lack of out-of-bounds auth.
Reasons why password logins are more secure:
1. Uses secured, encrypted connections to transmit secrets. Prevents man in the middle attacks and interception of logins.
2. Provides an out of bounds auth token. The only way to subvert this is to intercept it as it goes into a computing device, meaning either the client or server would have to be compromised at the time of login.
3. Data at rest is encrypted and only the user's cached token (cookie) can be used to steal a pre-authenticated login.
4. Password can be unique to the service, so a compromise of one system does not compromise all.
5. Industry standard is already to require multiple-factor authentication to be combined with this method for increased security.
Flaws in the passwordless login system:
1. Authentication is done on unsecured connections. With all of the shouting over privacy and security, here we are abandoning secured, encrypted connections for SMSes and e-mail, two unencrypted, unauthenticated, somewhat unreliable, easily intercepted, plaintext messaging systems.
2. Replacing an out-of-bound token with one stored purely online. Any actor who controls the network (or your computing device) can subvert the login.
3. Depends on a pre-existing authentication, which itself uses passwords (or none at all), leaving you at the exact same state of security as you had before. Instead of two passwords that are the same, you have one password (the e-mail password) that is the same, or zero authentication with SMS.
4. No mandate for multiple-factor auth, nor out-of-bounds auth.
5. Zero security for the tokens (cookies) stored on the user's system, so data at rest is at risk, unless your browser encrypts cookies with a master password. Of course this is moot considering the total lack of encryption on the smtp/sms side and the lack of out-of-bounds auth.
Reasons why password logins are more secure:
1. Uses secured, encrypted connections to transmit secrets. Prevents man in the middle attacks and interception of logins.
2. Provides an out of bounds auth token. The only way to subvert this is to intercept it as it goes into a computing device, meaning either the client or server would have to be compromised at the time of login.
3. Data at rest is encrypted and only the user's cached token (cookie) can be used to steal a pre-authenticated login.
4. Password can be unique to the service, so a compromise of one system does not compromise all.
5. Industry standard is already to require multiple-factor authentication to be combined with this method for increased security.
Why not PAKE?
"The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to dictionary attacks mounted by an eavesdropper, and it does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server. In revision 6 of the protocol only one password can be guessed per connection attempt. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision 6a."
You can salt/password manager/email retrieve on the client side however you want to strengthen you passwords or escrow keys without needing to share state with third party services at all. And they never get a copy of your creds. The server side can easily rate limit guesses per account, report access times, and/or require CAPTCHA challenges.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
"The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to dictionary attacks mounted by an eavesdropper, and it does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server. In revision 6 of the protocol only one password can be guessed per connection attempt. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision 6a."
You can salt/password manager/email retrieve on the client side however you want to strengthen you passwords or escrow keys without needing to share state with third party services at all. And they never get a copy of your creds. The server side can easily rate limit guesses per account, report access times, and/or require CAPTCHA challenges.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
With the exception of automatically grabbing the token, it's pretty much the same as BYU's SAW[0]. I worked for a startup that was trying to commercialize this technology, but it's nearly impossible to commercialize an authentication tech. It's unfortunate, too, because I think it would make a much better option than most password managers.
0. http://isrl.byu.edu/projects/simple-authentication-for-the-w...
0. http://isrl.byu.edu/projects/simple-authentication-for-the-w...
The basic reasons users hated it was that a login mechanism needs to be reliable. In particular, we make business software, so if the user was ever unable to get into the system it was a big problem.
While it may seem that you "always" have access to your email, or sms. Not all users (especially non-technical users) always have access to these things. Meaning, even if they have access 98% of the time, that other 2% of the time infuriates them.
It was also a usability nightmare among non-technical users. Traditional login mechanisms dont necessarily mean a more usable experience, but its a pattern that everyone knows.
I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it.