Passwordless authentication: Secure, simple, and fast to deploy
hacks.mozilla.org
hacks.mozilla.org
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.
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/...
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.
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?
http://www.chromium.org/developers/design-documents/password...
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 :)
Nothing beats plain old password as convenience, that's why they are still so wildly used despite lousy security properties.
What do you think is the best alternative?
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.
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.
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.
(an example would be nice)
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.
"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
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.
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.
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://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.
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.
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.
[0] http://support.apple.com/kb/ht5813
[1] i.e. Apple (claims it) can't access your passwords, despite syncing them across devices.
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.
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.
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?
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.)
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 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.
(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.
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.
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.
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.
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).
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
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. :)
Persona is great and similar to passwordless in a way with the only downside being the reliance on JS.
"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...
Edit: …which makes it totally sensible to invest time building your site up relying on this stuff.
(FWIW, dochtman and I maintain Persona)
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.
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 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.
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).
It is like saying: "We need tv sets because tv sets are the only (valid) means of entertainment."
0. http://isrl.byu.edu/projects/simple-authentication-for-the-w...
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.
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.
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.
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.
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.
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 :)
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.
For websites where security is a larger issue, this obviously wouldn't be the solution.
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.
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.
Securing your email account can be done without 'only' using a password. I use 2 factor auth on my google accounts, for example.
As I mentioned elsewhere in the thread, I missed the password reset link point. I stand corrected.
With that out the way, this is really interesting stuff, although some people may end up with crowded inboxes.
This would be great as part of a 2-factor scheme though.
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.