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.
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?
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.
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.
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 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.
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).
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.
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.
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.
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.
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.
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/
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.
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.
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...
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 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 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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
> 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.
> 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.
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
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 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.
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.
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.
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.
159 comments
[ 141 ms ] story [ 570 ms ] threadBesides, I don't think they are claiming to be innovative. I think they just point out there is a redundant step which we can remove from the process.
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).
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?
This is not the case when using two factor authentication.
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.
That is to say, yes, a compromised primary e-mail _is_ catastrophic, but seems like an already accepted risk. Why is this worse?
I didn't mean to imply that this was worse, only that it doesn't really change the threat.
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.
I've wanted to move Persona in this direction for a while. I'm really excited to see if Webmaker is successful with this auth model.
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.
That is not the case. It will remember you every time you come back. You just never set a password when registering.
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.
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.
[0] https://fidoalliance.org/adoption/videos
1. Navigate to Settings, Finger Scanner, Pay with Paypal
2. Select Install FIDO Ready Support, then Install NNL fingerprint scanner
3. Select Link to Paypal, then Link Fingerprint
4. Login to paypal with username and password
5. Agree to terms
6. Swipe finger to link fingerprint
7. Install paypal app.
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.
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.
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.
If by push notifications, you mean mobile devices, then surely that would only log them in on that device rather than on their computer?
"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.
That's why I shop in Waitrose http://scaryduck.blogspot.co.uk/2011/05/death-to-ten-items-o...
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.
Why not one of these on a thin enough tag to stick on your phone? Sounds like a very good solution for me.
(1) http://en.wikipedia.org/wiki/Security_token#Disconnected_tok...
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.
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).
I guess whatever the scenario 2-factor + email round trip is more of a hassle than 2-factor + password.
Thanks for your response!
+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.
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?
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.
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.
[1] https://sendgrid.com/blog/sendgrid-and-the-future-of-email-s... (I work at SendGrid)
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.
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.
(Hashed) Password storage is moved to a third-party database (the email provider). Presumably the client "remember me" links are meaningless by themselves.
I'm not sure what you're saying here:
> (Hashed) Password storage is moved to a third-party database (the email provider)
There is no hashed password? It's just a challenge response using an alternative path.
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 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.
[1]: http://notebook.ideapublic.org/wp-content/uploads/sites/5/20...
https://chrisdecairos.ca/one-time-passwords-pt-2/
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).
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.
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.
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).
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.
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.
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.
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/
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.
BTW: I also described a similar idea some time ago in a blog post: http://strategieneu.blogspot.de/2014/06/email-only-registrat...
After I wrote it, that such ideas where discussed at HN even some time ago.
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)
For a lot of sites I use with low frequency my login procedure is basically just reset password, and login with new password.
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.
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.
[1] https://news.ycombinator.com/item?id=5743057
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.
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.
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.
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
If you really wanted, you could shorten the session lifetime and automatically renew it upon each use, perhaps up to some limit.
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.
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.
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.
[1] https://sendgrid.com/blog/lets-deprecate-password-email-auth... [2] https://vimeo.com/90883185