1. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year.[1] That's a long time to go without reauthenticating a client!
2. Authentication is or should be a much more common event than recovering a lost password, and now that's totally dependent on your email provider. One concern is latency.. a minute can feel like an hour while waiting to log in to your account to do something urgent. But also worrisome is provider downtime, spam filters, etc. all can block you from accessing your accounts.
Of course the way they "deal" with #2 is by just trying to avoid authenticating you very often (#1), which is not a generally-applicably awesome security practice. Might be ok in some cases but I wouldn't classify that as an overall "better" way to sign in.
I think a better way to solve this is at the browser/OS level with built-in password generation and management. And that's actually a third drawback to this approach.. it's incompatible with password managers.
> a better way to solve this is at the browser/OS level with built-in password generation and management
I agree. It is also the only method that can guarantee backward compatibility with the millions of existing websites that are not going to move to a different auth method anytime soon.
KeePass, LastPass, et al. have done a tremendous amount of work to make the experience as seamless as possible, but there are still a lot of rough edges because every website has different policies. If most websites agreed to accept strong passwords of a standard format (e.g. 32-byte string of ASCII printable characters), we could finish the automation and just treat passwords like any other key that websites exchange with us all the time.
About a year ago, I proposed that we should come up with a standard login API for websites to adopt, in order to improve the password manager UX [1]. There was quite a bit of discussion, but unfortunately the world seems to be much more interested in getting rid of passwords altogether, no matter how unrealistic it might be. Well, can't blame them, it's always more fun to create something new than to fix something that already exists.
I feel like we're missing the elephant in the room.
The solution they have isn't an authentication system. It is a system that relies on an existing authentication system (your email provider's system) to work.
This is essentially the same as OpenID Connect: you really log in with your email host, be it Google, Yahoo, whatever. It is better, because your websites don't have to support the use of a dozen different vendor-specific login buttons.
But the real authentication happens when you enter your password to access your email.
Therefore, when I read:
> I think a better way to solve this is at the browser/OS level with built-in password generation and management.
All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?
We can have a world where identity is federated through your email account. We can also have a world where it is federated through your browser account. They are fundamentally similar, and I have no way to know which of Gmail or Firefox Sync are more secure, but I do know that they're both inconvenient as is.
Gmail keeps nagging me about 2FA, a very bothersome way to log in (since I don't often have my phone), and wants me to have a backup email address for recovery purposes (which I cannot accept from my main identity holder because, well, it is the main one).
Firefox Sync doesn't enforce the use of a master password for all users, which can easily give the appearance of security. Besides, it won't always detect password fields and won't auto-login when it sees them. In addition, it doesn't have the (UI for the) ability to switch users on the browser — you need to use a private window for that, but then your passwords are still shared with other users. Finally, it doesn't generate strong passwords for you (which makes sense, most websites offering a password have stupid rules).
From the website's side, implementing a login solution relying on an existing email provider is way easier and more secure than relying on your browser's Sync system.
So, is it really a better way to solve this? Not currently.
A few thoughts about the current de facto authentication 'standard':
1. The majority of my accounts are tied to my email account. Now, I can't easily change email providers; I'm locked in, for the most part.
2. Email is slowly dying and will be mostly extinct before long. Most people under 20 don't use email except for authenticating with web sites. Email was traditionally used for asynchronous one-to-one (or one-to-many, in some cases) communication. But, new services have risen that do this better.
3. The near-ubiquitous rise of mobile and smart phones: although you may not have a phone nearby, my phone is pretty much the only thing that I always have with me or nearby. So, I want sites to authenticate me with my mobile device, not email. I see mobile device (an identity proxy) becoming more ubiquitous, not less.
4. But, sometimes I want to authenticate anonymously.
5. I don't want to have to trust my email provider (or any 3rd-party provider) to safely and privately store my account information.
6. And, if I lose or break my phone, I don't want to lose my identity - I want an easy way to encrypt and store my identity at multiple backup locations.
About the 2FA thing, Authy is a Google Authenticator alternative program that allows you to keep several devices, including computers, with the ability to generate those codes. Might be what you need to both use 2FA and not worry about having the phone always with you.
Although, sites that uses 2FA usually don't ask for the phone code very often. They use it more to authenticate the device you're using. If it's your home computer, you only use the code once every month or so.
2FA feels like a chore before you actually uses it. I know because I resisted it for a few years. Now I complain when a service doesn't have it. :P
> All I can think is, it depends on who you trust: the entity that secures your mail, your contacts, your calendar information, or the entity that secures your passwords to get there?
It's not just about trust. There are also a significant technical drawbacks to piggybacking email for authentication, namely the two I mentioned (security/convenience and reliability).
You should take a look at iCloud Keychain. It does a better job at tackling some of the drawbacks you note with Firefox Sync, especially when combined with Touch ID as a more convenient master password.
I think a lot of people do this for infrequently visited sites, but:
1. It generates at least 3 new database transactions each time it happens, not to mention the associated crypto requirements and email.
2. This password recovery system is a common attack vector and vulnerable to social engineering attacks and MITM attacks.
3. It is mostly obviated by the existence of password managers. For those with the knowhow to do this sort of thing, all of this sort of stuff should be happening on the client side.
For your #1: For sites with low security demands that will be Ok. GMail already does it. When I enter GMail it always gets me logged in by an cookie and that lasts for a month or so, only after that period, I have to enter my pw again. Of course, when you do some security relevant changes (like changing passwors ;) ... just kidding ... changing eMail adress), a reauthentication is needed.
I don't think that this scheme is for any site ... banking sites just want to be more secure... but it is very much better, than setting pw="123" on all websites, you don't care to much.
Yes it is. But still Gmail sessions are long-lived. I also would not stretch this system to eMail-access. Blame it on Gmail, that they do not enforce more security.
It works because they aggressively monitor for session stealing attempts and immediately shut them down. So it's long lived but with an impressive amount of monitoring that really isn't within reach for non-Google companies.
I made a small program to access Google Keep automatically. Because I was too lazy to implement proper authentication, I just hardcoded my session keys. The app is started from a different IP, using a different user agent and is STILL able to access the site after weeks!
(Nowadays I have proper authentication in there, but it’s still worrying that stealing sessions from Google is so easy. Especially because some Google services submit their sessions keys via HTTP, without SSL)
That is not enough evidence to conclude that Google does not monitor for session stealing. Lots of people have dynamic IPs and user agent strings are easily spoofed. They're going to be looking at other factors, like where the IP is located.
I can tell you they do. Within seconds of clicking on a compromised URL they had locked down my account requiring a text to unlock it. I was deeply impressed.
The long log-in duration doesn't really bother me in and of itself. No-one uses my computer without my permission, and no-one uses my browser, period (I create new accounts for people).
If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.
That might work for you, but not everyone. General website authentication systems need to work for the masses. And the whole point is shortening the session makes this system very inconvenient to use.
I like the idea. The downside is of course having to switch between the site and your email.
One could bridge that gap by adding two headers to the authentication emails - one containing the URL where the sign in request originated, and one with the sign in URL that must be visited.
A browser extension could then check your emails, and if an incoming mail matches the sign-in page of the current tab, log you in directly.
Bingo! Automating email-based authentication would indeed be pretty cool. In fact, extend this concept a little further, and you will realize that email itself is the ultimate platform to build programmatic exchange of information between persons and services. I wrote an essay about all the possibilities this would open: http://blog.zorinaq.com/?e=76
It's not the ultimate platform. Arguably, it's not even a very good platform. What it is, however, is the best platform we currently have.
The idea of using email for password exchanges is fraught with difficulty, and not only because there's a lot of terrible email providers that don't even support starttls on their mail servers. Net-savvy people have fought a war to have HTTPS implemented across the web, can you imagine how hard it's going to be to get people to fight for implementation of security they can't even see? Ask your nearest non-technically minded friend if he knows if his email is encrypted in transit, and then ask him if his bank website is.
Someone elsewhere in the thread mentioned they'd only just started using key-based SSH login, and how it seemed to them the best thing since sliced bread. Extend that a little further with keyphrase protected keys and ssh-agent/pageant/whatever macs use, and you have a much, much better platform than "emailing a temporary password."
The problem I see with implementing something like that is getting it off the ground.
email itself is the ultimate platform to build programmatic exchange of information between persons and services
I consider my inbox as a notification pool where anyone and anything can send me a message. Now what I would love is different sets of tools/UIs that let me interact with each notification in the right manner.
Example both a newsletter and a my bank statement can come, however the view and actions would be entirely different.
I implemented this style of login in the app I'm currently building. I don't think its necessarily appropriate everywhere; the reason I decided to use it is that its the type of service you very rarely log into. For things like that, a large portion of logins are (anecdotally) going to end up going through the forgot password flow anyway.
I will admit that not being responsible for storing passwords was one of the reasons I used it. I'm by no means a security expert; one less thing I can screw up seems like a major plus.
I've done the same thing in a few prototype-style apps I've built too. Not only do you not need to store passwords, but you can just ignore a whole area of UX.
Enter email to signup -> link gets emailed.
Enter email to login -> link gets emailed.
I use JWT for this and it really makes it easy to get started on the part of the project that matters... and sometimes (not always) I think it's probably going to be fine to leave it this way.
A modern password manager (e.g. 1Password) seems like a way more natural solution that this. Not to mention that many services do not use smtpd+ssl/tls.
I disagree with this. I see services like 1Password as a bandaid for the tech savvy population. They are solving the password problem well, but only if you seek out the tool and understand the need for the tool. Approaches like the author's here solves the password problem for the majority of the population - the non-tech savvy population.
To your second point. Yes, this is true. But this is improving [1]. I'd add that forgot password functionality carries the same risk, and I'd add that the more likely chance of your password being 'discovered' is by brute force or a website hack storing passwords in plain text - rather than intercepting email.
> They are solving the password problem well, but only if you seek out the tool and understand the need for the tool
How about Apple's Keychain? iOS and Mac users get suggested auto-generated passwords that are then automatically saved and synced across devices with no extra installs or options.
I agree. I use KeePassX with both keyfile and passphrase. Keyfile is always offline and database is on Dropbox for syncing purposes. If I want to use it on Android, I manually move the keyfile and access database off the cloud. I create 25 characters long passphrase for each website. Works way better than single sign on. No one can every deny me service or close my account.
I really like this, I was thinking the other day when I used a site that I rarely use, and went through the whole 'forgot resend reenter' password thing that just that could be the 'standard' way of dealing with low impact sites and wouldn't force a password to be generated. It does imply the mail path is workable but that seems pretty common these days.
It's clever but I wouldn't use it. First the user experience of going from one channel (web) to another (email) isn't very natural but the second and biggest reason is that it turns an email account into a central authority to access my other accounts from.
Some say email is already like that but it isn't with services using two factor authentication.
I don't think there is an easy and intuitive way to get rid of passwords without involving some sort of physical component that stays on yourself.
What is your workflow that this would be any more difficult? The first time you sign up for a service you almost always have to do this anyway for confirmation. If you then select the "Remember me" path, your primary computer is whitelisted and you don't have to do the round-trip.
Due to "Forgot my password" workflows email is already a central authority. If you have two factor auth set up for your email account then you're already pretty well protected and having each and every service use a different two-factor method provides diminishing returns in security.
The funny thing about this proposal is that it is exactly the way my non-technical family members use every service. They don't bother with passwords they just use reset links every time. They don't have to remember anything and it's a common workflow.
> What is your workflow that this would be any more difficult? The first time you sign up for a service you almost always have to do this anyway for confirmation. If you then select the "Remember me" path, your primary computer is whitelisted and you don't have to do the round-trip.
This assumes one (or n) devices that belong to you. I typically have to log into multiple services using a large amount of computers for work. In my use case this would be tremendously annoying whereas two factor I can simply log in like normal and type in the code from my phone's app.
> If you have two factor auth set up for your email account then you're already pretty well protected and having each and every service use a different two-factor method provides diminishing returns in security.
I disagree; it prevents someone from getting into my email due to a vulnerability and then being able to get into every other service I'm connected to. Each service I use would, ideally, have two factor (though I obviously do not think two factor is perfect but it's better right now than most alternatives in my opinion).
Interesting, it's clear that in your use case it would be more of a hassle, but in response to the second point it seems you're ok with the hassle of two factor authentication for many services.
I guess whatever the scenario 2-factor + email round trip is more of a hassle than 2-factor + password.
"The funny thing about this proposal is that it is exactly the way my non-technical family members use every service."
+1 to that. My non-technical family and friends do the same.
I spent a month experimenting with this approach myself vs using LastPass. It was actually pretty comfortable - easier than 2 part auth - excepting that sometimes the forgot password links were difficult to find.
You don't have to do that. Persona is pluggable, and what looks like your email address isn't, really. For example, I made a third-party authentication platform that you can use to authenticate, instead of your email provider: https://www.persowna.net/
Sure, 2-factor auth (by its very nature) prevents sign-in from a single source, but 2FA is an additional layer of security on top of passwords, NOT a reason why email isn't already a central way to bypass password security.
To put it another way: This article describes logging in to a service via an email sent to your account. Every major service already has this in-place via the use of the "forgot password" link; if I have access to your email account, I can already log into any service which sends a reset link to your inbox.
2-factor auth is great as an additional layer of security on top of either this method or the traditional password method, so why not just remove the additional vulnerability of permitting logins via passwords stored everywhere else on the internet, too?
> To put it another way: This article describes logging in to a service via an email sent to your account. Every major service already has this in-place via the use of the "forgot password" link; if I have access to your email account, I can already log into any service which sends a reset link to your inbox.
Except with two factor authentication you can't simply reset your password via email and login. It's not perfect but services using two factor authentication prevents email from being a completely centralized way of authentication. I at least like that aspect of it.
I remember this idea from a while back, and I still think it's not going to work. It's too cumbersome to have to access your email every time you want to log into something. I love the creativity of the solution, but I just don't think it's workable on a large scale.
Now that we all have push email in our smartphones, it's not nearly as cumbersome. I already need to pull out my phone every time I want to access a Google app, having 2FA enabled.
But clicking the link on your phone would only log you in on your phone, no?
So your phone can't aid you here. If you're using any type of setup that doesn't use instant-push emails on your desktop, logging in will be very cumbersome.
This is essentially the same system that Netflix and other services use to authenticate devices. Simply include an N character (usually 5) random code that expires in minutes (10-20). They can type in this code on whatever device they want to authenticate.
Include a link in the email in case they are currently on the device they want to authenticate.
This solution is good for long term authentications (registering a device to a service e.g. my Xbox to Netflix), but cumbersome for a service I log into frequently from many unique devices.
This is still nothing more than a password...it's essentially just a password that is emailed to you. I've never understood why we can't instead authenticate ourselves to our browser or device, and get people out of the habit of authenticating to individual websites. This would eliminate phishing and greatly enhance security. Touch ID is a big step in this direction, but still can't be used for websites.
When authenticating, the browser could just send the user's public key, and if a user with that key is in the system, it replies with a session key encrypted with the user's public key. If browser companies would get their act together, we wouldn't have as many authentication issues as we do today.
It is possible to use public key authentication with most modern browsers (not sure exactly which browsers support this). However, it's true that browsers currently don't provide any method to authenticate the user with the browser itself. (Although you could argue whether or not this is necessary since the user has presumably already authenticated with the machine running the browser.)
The biggest problem is that the user experience is pretty terrible for generating and managing the certificates used for authentication. There's also the fact that the certificates are stored by the browser with no obvious mechanism to log in from another machine.
I've been wondering whether the concept in the article could be expanded out using client auth certificates.
So instead of clicking the login button and getting an email every time you need to authenticate (or using really long sessions), you use the "email to login" method once per new device. The resulting page takes the user through creating and uploading a client auth certificate, and stores it (along with a user provided device name to allow revocation).
In-browser cert+key generation is not perfect by any means but it certainly is possible - it's how providers of S/MIME certificates [1] are able to give you a signed certificate without you manually creating a private key+csr and uploading it.
You could login to the browser using a password. It would still be valuable to reduce the design problem space to one username/password, rather than one for every stupid site and app on the internet.
Absolutely. My point was that this is not currently possible without any sort of browser extension. However, I think password managers are a reasonable solution that does indeed generally only require one password. (A bit of a simplification of course since multiple passwords do exist, but at least you don't have to deal with them as a user.)
This essentially mimics my login flow to every site I only use occasionally (e.g. twitter) and therefore can never remember the password for:
1. Go to login
2. Forget password - click reset password
3. Go to email, find reset password email
4. Login.
I wouldn't really mind if this became more common. I don't trust password managers (and access the internet from so many different devices that the only common thing they share between them is that I can access my webmail client or email on my phone.)
LastPass was considered secure on HN in the past, has this changed? Or is there a reason you don't like it? Not attacking, just curious about my own security.
The cynic in me observes that although this post is couched in the language of an improved UX, what it also does is absolves Mozilla from keeping any (hashed) passwords stored in their databases. Only tokens with a very short shelf-life.
(Hashed) Password storage is moved to a third-party database (the email provider). Presumably the client "remember me" links are meaningless by themselves.
Of course - and thats fantastic! There's one less place that people will trust with a shared password.
A very large percentage of users reuse the same password on multiple sites. If you do that, a security breach in any site will leave your password exposed on all sites. And if you're anything like me, you have an account on all sorts of tiny sites.
You really can't trust the security of any startup thats less than 2 years old, or less than 5 people. Most software engineers don't know infosec well enough to implement a proper password database and protect it. Most startups are only 'secure' because they're such small threat targets that they don't have much value in attacking. However, if those small targets store username and passwords that get reused on lots of websites, everybody loses.
If the 'reset password' link sends an email, users have to trust their email security anyway. If I have access to your email, I can reset your facebook, twitter, etc passwords then delete the password reset link & notification from your email account. Google is going to do a better job at password security than a 3 month old startup with 1 engineer.
Absolving mozilla (or anyone else) from keeping passwords improves security.
I don't know if I'd call this "fantastic". It simply relocates the attack. Ostensibly, the thing that is improving security is having a stronger password elsewhere rather than those recycled ones that you mentioned, but this is not guaranteed and, I suspect, not the case in most instances. It's really like using an email account as a password manager.
You get sent an OTP that expires after half an hour. So in order to attack someone, you need to gain access to your victim's e-mail account beforehand. Which is quite hard if if the victim has MFA activated.
If you gain access to your victim's e-mail account, even if you find any passwords in there, you cannot use any of them because they are not working anymore.
So it's not only a stronger, non-recycled password. It's:
1. an OTP
2. that expires very soon
3. that cannot be recycled
4. in a place that's likely to be well-protected
EDIT: 5. that place (#4) is in widespread use
This is beyond a "password manager" which barely covers #3 (it incentivizes not to recycle) – and maybe #4, if you're careful.
Almost all services have a "forgot password" link that will send a reset to your email account.
The solution in this article isn't really "relocating" the attack... more like removing additional attack vectors and limiting it to the email vector (which already exists right now, anyway).
My assumption is that a "login key" is essentially a large piece of data that would be prohibitively inconvenient to use outside of an email account, text, etc. Analogous to a large session cookie without an expiration date.
In contrast, a password is designed to be used from any login point.
In this regime, unless the optional password is used, there is no hashed password stored on Mozilla's servers. Only a copy of the hash of the "login key" is stored, so the attack surface is considerably shrunk if you are attacking Webmaker users.
I'm not totally clear about what the different between a "login key" (short-lived, pronounceable) and whatever is contained in these semi-permanent login email links (~1 year, presumably non-pronounceable).
No the onus is still on the user. How does the onus move to the channel provider?
I don't see a difference in this and 'Reset your password' links in emails that are common place. They are basically the same premise, without the password.
In mobile the sign up flow can even be more streamlined using deep linking:
1. User enters email address.
2. Opens email client and click the link.
3. Link contain app specific schema myapp://login?token=cold_fish etc.
4. App opens and verifies the token with the server.
5. User is logged in.
User has to enter only email address as opposed to email + password (and sometime password confirmation)
Then only needs to click a link in email client to sign up.
Isn't email transferred in plain text? This is not very secure in my mind. Granted, nowadays a lot of service lets you reset your password through email, but that is only a one time thing. Now the whole system is dependent on someone not introspecting the packets flowing in the Internet.
That's historically true but TLS is now really common on both servers and clients. In fact most major email clients I've seen show a warning if the server only supports plain text.
Thunderbird shows a large modal "WARNING! Server mail.myhost.com does not use encryption" dialog.
I don't know if it's fair to say email over TLS is really common yet. It's getting there, but Google's email encryption in transit transparency report shows that only 57% of inbound messages to Gmail were sent over TLS. Outbound 72%. https://www.google.com/transparencyreport/saferemail/ (this is largely concerning server-to-server communication, rather than client-server, but server-server communication happens whenever emails are sent across domains).
To be fair those inbound reports are potentially bloated by a lot of spam that no one reads or cares about. It would be interesting if Google disclosed what percentage of messages that end up being read are sent over TLS (or non-spam messages generally). But we can also see that several top 10 sending domains do not support TLS at all (adsender.us, constantcontact.com, grouponmail.*, sailthru.com - mostly advertisers). Luckily the top receiving domains support TLS (which look like other big-name ISPs).
Compared to website TLS, email TLS as commonly implemented has two significant challenges beyond these percentages. First, since TLS is established by the STARTTLS extension protocol within an existing plaintext SMTP connection, it's easy for an attacker who can modify communication to force it to remain in plaintext (simply don't advertise the TLS capability). Second, that previous attack is hardly even necessary: most email senders are willing to establish connections to receivers who present self-signed certificates. The same scenario when browsing a website will show a security warning and recommendation not to continue. The reasoning goes: it's better to use TLS even with a self-signed cert than fall back to plaintext. There's no human involved who can make a judgment call to abort, like there is when browsing a website. So, while email TLS with self-signed certs may be helpful against passive dragnet surveillance, it's little defense an attacker who can intercept and modify the communication: the attacker can simply present his own self-signed cert instead, and the email will flow.
Solution ideas: Devise a standard by which messages can be stamped "TLS only or don't send", and another standard by which domains can declare their intention to support TLS. Senders will remember that the domain is TLS-enabled and refuse to fall back to plaintext; and will require a certificate from a reputable CA under either protocol.
But the connection between this server and that server is not necessarily encrypted. Not every one uses Gmail, Hotmail or other big email providers that (I hope) properly configures for security.
I too would "like to see [this approach] used and pushed further by other designers and developers."
I'm one of those who have been trying to do so. I created an open source approach called Handshake.js that is re-usable for developers. [1]
I presented this topic to a good crowd at JS.LA [2].
At the current time, I'm finding developers still hesitant to jump into the approach. Passwords are familiar and there are many developer tools/libraries to quickly setup the defacto username/password approach to authentication.
It uses the same idea as in the post, ie the "lost password flow for login", but with XMPP. The latter gives you much higher flexibility in that it actually is thought out as a programmable protocol. You try to login, the server sends a token to any of your connected clients via a bot message, you just repeat it to the bot and you're then granted access.
Playing with NetBSD the other day, and bored, I created an SSH key for the first time and was amazed that I had not been using this for forever. I think keys could replace passwords, or at least, cookie based logins.
Client-authentication has actually been supported in SSL for a long time [1]. Unfortunately, there seems to be little interest in using that form of authentication in browsers. A big part of that is probably making a compelling user interface and teaching users how it works.
[1] summarizes why TLC client auth isn't wide spread, but he also proposes some TLS extensions to improve client auth. Such as Origin-bound certificates [2] so that the user does not have to choose which certificate to use for authenticating.
What's funny is that we're basically doing a very similar thing at my startup, PricePlow (https://www.priceplow.com), and it was actually inspired by discussion earlier here at Hacker News.
It works very well for our purposes. We don't need crazy security because we store no important personal information -- just product preferences. It's insanely easy on the users.
I guess I should get back to blogging about my entrepreneurial lessons learned, as this has been one of many of them....
So instead of directly logging in using the ID provider like FB/Google/Microsoft, which are also the email providers, you send an email to those accounts and ask user to take one extra step of checking and clicking the link. It seems to be inefficient. A much better solution should be for the devices to support accounts natively and integrate authentication directly into the platform.
The idea seems to be that you only have to do this once, then you remain authenticated for every service that integrates with this authentication service. You don't have to remember another password or place trust in a new service not to mishandle it.
This seems like a solution that completely replaces the need for every website to manage their own user signups, which is something you still need to do even if you integrate with Google/Facebook/etc. because not everyone has an account with those and signing up for one is less trivial than having a sign-in link sent to your email.
How is this any materially different than the "I always forget my password and I always use the forgot password link"? I guess you don't have to pick a new password each time? But you could just rapidly type in gibberish and achieve nearly the same effect, no real password, login via email.
The biggest reason for me to pass on implementing an approach like this is what I THINK is the actual most common use case for a typical user when logging into a site at which they are a regular:
They're doing so for the nth time, and on the (or a) device they usually use, and thus their browser (or other password manager) has already got their password remembered and thus it is pre-filled in.
Having to click back and forth between email every time you log in seems way clunky relative to that, which for me is something above 90% of the instances I log in to some web application.
Couple that smoothness with picking a non-reused, strong password for a web application (which password managers make actually practical) and the friction in the user login experience seems to have little if any upside.
In the email, you can click "Sign in & remember me". I guess that sets a cookie in your browser, so next time you come back, you'll still be logged in (until the cookie expires).
Every time I've heard of this system, I've thought that it would make it clumsier to access an account.
I go to a site and my intention is to stay on that site throughout whatever I'm doing there. If you force me off your site for something like logging in (where it's the point of 'I trust your site, give me access') then I've lost focus and you've put your experience in someone else's hands.
If I was doing this, I'd have to open a new tab, go to GMail, wait for it to load, find the tab within GMail that has the email and then click the link. Every so often, I'd probably have to put my Google password in too. That's a lot of effort, considering that your site probably isn't that significant to me.
I really like the way TranferWise (transferwise.com) automatically signs me in when I load the page. It's a way to transfer money online so has to be secure, but uses my email authentication to verify it's me. I don't even have to click a sign-in button! I'm surprised this hasn't caught on more...
The only difference I can see is that they ask you the email to figure if you are coming from yahoo or Google while the most common pattern is to show two buttons.
I don't think asking your email is a good idea, email is a something they should ask to the identity provider instead.
I like this idea a lot, but given the centralization of authority to a user's email account, I do think it requires beefed up security for however the user accesses their email---i.e., would be great to allow this only for users who have 2FA enabled on their webmail, although I have no idea how you'd check or enforce that.
Actually, the "lost password" flow already assumes email as a single point of failure, so I suppose my 2FA comment is moot (in other words, we should be pushing for 2FA for accounts regardless of their password approach on other accounts).
> but given the centralization of authority to a user's email account
This is already the case right now. An attacker who has access to your primary email account can gain access to any of your accounts using Forgot Password.
> the "lost password" flow already assumes email as a single point of failure,
Exactly. I think that was the inspiration for the idea. If we have a single point of failure anyway, why not just use it directly to login?
Yes. This just offloads the security burden from the Webmaker service to your email provider. It means one less password, but a compromise is still catastrophic.
If the goal is to separate the need to remember complex passwords from the application, then a password manager makes much more sense (ideally with 2FA).
In the long game of improving token-based security, this is a step sideways at best.
Assuming an email compromise is catastrophic, as pointed out earlier in this thread, one might as well use a password manager, which allows for maximal password strength, possibly 2FA, total control over the password database, etc.
I didn't mean to imply that this was worse, only that it doesn't really change the threat.
Because, at least for me, it takes a lot longer to visit my email, wait for the email to arrive, open it, click the link, than to just fill in a password (or preferably have my browser/password manager do that).
>
This is already the case right now. An attacker who has access to your primary email account can gain access to any of your accounts using Forgot Password.
This is not the case when using two factor authentication.
The main flaw with this idea as well as pretty much every password reset flow is that email itself is insecure. If I want to attack the login system and I have the ability to intercept the emails at some point, I essentially get access to the link/code in plaintext and now have access to the account. The difference might be that there will be a much higher volume of emails from a system like this than from one that just uses email for resetting passwords, though that's not guaranteed. I'd like to see a system that address this issue.
Startup Digest event submissions use similar method: no account, every login is an email sent to you. The problem I have is that I do use a password manager and like that much a lot more than switching back and forth of email and the site. If I go to your site, I don't want to go to my email...
It really feels like they want to solve my password storage problem for me, in a very opinionated manner without any alternative for me, and while it might be a good solution, it does not feel like one (for me).
Does this handle concurrent logins from multiple devices reasonably? If every login essentially resets the "password", either all other existing sessions are terminated (bad usability) or kept (possibly insecure).
The linked more technical description suggests that the latter is done (sessions on trusted devices are valid for 1 year), so you apparently cannot stop someone with a stolen device from accessing your account (while the session is active / the cookie persists).
I was initially concerned that email is insecure, but then I remember sites already use email for password reset. :) My bank does something similar by also remembering my personal computers by browser fingerprinting and/or IP address.
We shouldn't abuse email for this. Any one of LastPass, 1Password, KeyPass etc. or SSO with Google, Facebook or Twitter can do this way better. You will probably be using extremly long and random strings, i.e. you're storing secure tokens there. You can't call those passwords any longer -- and we should forget about the notion of manually creating and then remembering passwords to sign-in.
If the service is not going to contain any privacy related stuff or need not be so secure why not just keep the cookie after typing in email address.
What i do is i keep all worthy sites'password on the password manager and the rest of the site follow a pattern based password or a common simple password. For e.g. i typically use some this "keepass"or domain of visited web + keepass
This makes a lot of sense. On every device you would use to login to some kind of service, you already have access to your primary email. Clicking a link is easier than typing your password. It also seems to be safer. Your account is safe as long as your primary email is not compromised, in which case the attacker would gain access to your account by Forgot Password anyway.
I've wondered for a while why this pattern isn't more common.
In the past I had thought it would be great if instead of email it could push to your phone so a message would pop up saying "confirm login? Yes/no". It would be a really simple option from a ux perspective but screw going anywhere near making the crypto tech to support it.
Passwords must die. We need to get to the point where there is a modular mechanism for authentication so that individual devs never are tempted to create a users table and add a note field for password storage.
1 is obviously mandatory. 2 could be preinstalled. 3 could be combined, but is mandatory. 5 is stupid. 7 should be already installed if you use paypal.
End result: find the right settings area, select link fingerprint to paypal, login to paypal, swipe fingerprint to link, done.
Don't criticize FIDO based on some half-baked implementation. Any problems you have with the setup flow are either Paypal's fault or Samsung's.
That halfbaked implementation is the featured video on their website. As someone new to fido, I was trying to learn about it and their website was very confusing and this featured video wasn't a great example of the technology. Those are not good signs of the technology.
They're trying to point out that it's usable today with paypal and the S5. They have no control over the steps Paypal and Samsung require to set it up. And although the 12 steps or however many there are are not ideal, it's not as if they left the setup for the user to figure out; all you have to do is follow the video. You're making a huge deal out of some extra steps on a one-time setup.
Don't blame the technology or the FIDO alliance when that video is about the S5 and Paypal, and the video is hosted on Paypal's youtube account.
The new yubikey neo (as of October) supports FIDO, but I don't know about client (browser/mobile) support middleware, and it requires nfc or full sized usb.
Seems like an overcomplicated mostly analog authentication. The last thing I want is being locked out of an account due to failed fingerprint scan or similar. I'm personally okay with a system like 1Password married to 2FA, it just needs to be better integrated like with Chrome's Credential Manager API and similar.
What is analog authentication? FIDO is a general protocol, it doesn't mandate fingerprints or say how to recover if a fingerprint scan starts failing to match... that's up to the implementer (the site you're authenticating to). Watch some other videos or read more docs on FIDO for a better idea of how it works. It's a generic protocol for 2 factor authentication done right.
Good option for B2C services that are not that important (pretty much most of them actually :-)).
Email delivery problems is a factor that needs to be considered though.
Stolen "remember me" cookies is another factor... The password stealing malware will start harvesting those cookies instead of passwords (it's already happening in some cases).
This article claims that the Guardian style guide was unhelpful. Possibly he should have read it:
"fewer/less: fewer means smaller in number, eg fewer coins; less means smaller in quantity, eg less money"
Simply put fewer is for things which can be counted, less is for things which can not. So you have fewer cylinders of air, but less air. If you can say "one X" and have it make sense you should use fewer, otherwise use less.
That's the rule as it's meant to work, the more interesting question is "does the rule matter any more?", to which I'd answer probably not.
You don't see supermarkets with "5 items of fewer" lanes and most people don't really see any difference between the two terms. The reality is that language continues to evolve, as it has always done, and the distinction is really now just one for pedants (guilty as charged). If you need proof of this then the just look at the figures in quoted blog post (assuming they're even vaguely right), which suggest that most Guardian journalists are ignoring their own style guide and their sub-editors (a job title which pretty much comes with pedantry in the job spec) are letting them.
What if I want to have this authentication process on my email account itself? :)
The only other option (soon to be available) is SMS. Seems a bit too limiting and maybe not completely practical.
Sounds like a good idea, but how many sites/companies will adopt it? There are tons of similar ideas, but none of them are as popular as login/password...
I think these two methods are more similar as it looks. It should be noted, that the tokens are only temporary tokens, that should be valid only several minutes. So the eMail system is not a storage, but a transmission medium. You also could use SMS or any other scheme that guarantees that only the valid receiver will get it.
Of course your proposal is superior, but the infrastructure is not available yet. For web-apps with low security demand, I think the discussed scheme would be sufficient (since we already have security implications because of password reset schemes -- and real secure schemes are seldom. In Germany there even where attacks to two-factor authentifications via mobile of banks ... the attackers just ordered a second sim-card in the name of the legal user and intercepted the snail-mail).
Ah, so the expiration issue is smaller than I thought. Thanks for that info. Still, it represents a training issue for users and a new framework to be incorporated into a web app. Those are both barriers to wider adoption.
I agree the security of this solution may be right for certain applications.
Yes, my proposal is an infrastructure play - but I believe it is a more realistically achievable one than most password alternatives.
Yes, I also think that it could be achieved. The problem as everywhere is the adoption. When two or three big companies would stand behind it, it could be easily implemented and I really would like to see a scheme like that.
There are of course some questions, that also would need to be solved. For example: What if an other person has access to my computer -- than I still would need some kind of master-password that had to be remember-able. Also there must be methods, to transfer my keys to an other computer or to "copy" for example onto mobile devices.
The example of the SIM-card for banking just shows, that the "big security" is really a hard problem. Two-factor is one idea, but it is always a game where the attackers are hunting the defenders (or vice versa).
Re: shared device use, yes, you would continue to do password management best practices (fingerprint scans, master passwords, etc.).
I see the transferability as an export/import format issue. W3C, browser vendors and password managers need to agree on a format for keychain export/import.
Note that this technique could still be used in conjunction with multi-factor auth. Since it is just an evolution of passwords, those type of mechanisms are still relevant and compatible (though, eliminating knowledge factors should reduce need for a second factor).
But the mobile app doesn't. Which means you are making the user go from app to email to browser and back to app. If you are lucky, the login link can open in app. If not, you need to transfer login from browser to app.
Problem with this system: it requires input on a single device (the computer), removes an out-of-band authentication option (password), and pushes the requirement for authentication down the stack to a system without a secure connection (e-mail, SMS).
In this new system, the password becomes an optional secondary authenticator. Your primary authenticator is now moved to some pre-authenticated service, such as your e-mail (which you have already logged into, presumably with a password) or SMS messaging (which you have already logged into, presumably with a swipe or pin on your phone). On top of that, neither of these uses a secured connection, so MITM/interception are trivial, to say nothing of phishing+CSRF.
One of the major flaws with existing out-of-band authentication access is that we assume the user only has one form of input: the computer. If the computer gets hacked [via malware] the user cannot protect themselves. But the future is here, and we carry [networked] computers in our pockets! Turns out the most secure way we can authenticate is via two separate networks and two separate computers using two secured connections. Example:
Step 1. User requests to login to HTTPS Site A.
Step 2a. Site A prompts User for a password.
Step 2b. Site A sends an SMS to User with an HTTPS link to click.
Step 3a. User enters password on site.
Step 3b. User clicks link on SMS in mobile device.
Step 4a. Site authenticates password.
Step 4b. Mobile site reads cookie on User's mobile browser.
Step 5. User is authenticated; both mobile device and computer have access to site.
Here you have two different authentication factors on two independent devices which are combined to authenticate the user. The attackers now have to steal a cookie or auth token from two separate devices at once. This is of course completely plausible, but is a much more expensive attack than any currently implemented. Best of all, the user doesn't have to remember the password if they use their browser's password manager or a cookie is stored locally.
It would be trivial to add this dual-auth method to their existing system, so hopefully they implement that instead of throwing the baby out with the bath water.
For what it's worth, of course, here's an attack that could compromise that system. Attacker shows user a phishing password prompt page that uses a browser hack to steal a cookie. Attacker sends an SMS to the user (assuming they found the user's phone number) with a link to another site which also exploits the mobile browser to steal that cookie. Now the attacker has the two cookies and can log in, assuming the site does not use an Authentication Manager that detects attackers who steal credentials (only large-dollar sites use these).
1. Needs a very long-lived session to be convenient. Elsewhere they note their's is a whole year.[1] That's a long time to go without reauthenticating a client!
2. Authentication is or should be a much more common event than recovering a lost password, and now that's totally dependent on your email provider. One concern is latency.. a minute can feel like an hour while waiting to log in to your account to do something urgent. But also worrisome is provider downtime, spam filters, etc. all can block you from accessing your accounts.
Of course the way they "deal" with #2 is by just trying to avoid authenticating you very often (#1), which is not a generally-applicably awesome security practice. Might be ok in some cases but I wouldn't classify that as an overall "better" way to sign in.
I think a better way to solve this is at the browser/OS level with built-in password generation and management. And that's actually a third drawback to this approach.. it's incompatible with password managers.
[1] https://chrisdecairos.ca/one-time-passwords-pt-2/