I applaud the attempt to move away from passwords, but this seems like a pretty annoying solution. I don't want access to my email to be tied to my access to "The Magazine". If I'm going to need to access some other service to log in, I'd prefer a Google Authenticator style solution where my access code is always a single click away from my phone's home screen. Maybe Marco/The Magazine could use Google Authenticator and just accept any password as long as the auth code is right, it seems like that would provide the same level of security as this solution.
As a side note, wouldn't someone trying to gain access to my account result in a deluge of password-link spam to my inbox? Or do they have some elegant solution for that.
I think this is a big factor, and why I think this is a really bad UX. I've actually considered this method of authentication in the past, but the only thing this fixes is this site having to remember a password for you (and the accompanying side effect of the vulnerability of your password being compromised).
Now, the user not only has to hold onto the login email (or request a new one), but they have to access that email every time you use the site -- or, bookmark the URL (yuck). Not to mention the issue if they're on another device that doesn't have access to the email address.
This may work as a secondary, optional method of authentication. But having it as the only method isn't a good UX.
Interesting. I did not make an account to try it out, so the following suggestions are for this kind of scheme in general.
1. The mailed login link should be only good for a single use.
2. This should be handled as a service by a third party site (similar to the way OpenID works). The mailed login link would link to the third party site, which then redirects to the destination if the login is valid.
The idea behind #1 is that if someone gets into your email, they should not be able to simply follow any old login links you've failed to delete. Best practice would be to delete the mails as soon as you click the link, but people will forget so the system should be designed with that in mind.
The idea behind #2 is that someone who gets into your email should not be able to tell from your old login links where you have accounts. If he could, he could simply go to those sites and make then initiate sending a new login link.
3. When you tell a site to send you a login link, the site should assign a random PIN to that login link and tell you (on the website) that PIN. The login link validator site should require you to enter that PIN before redirecting to the final destination site.
This is to prevent an intruder in your email from getting to an unused login link before you do and using it.
What if the email account has been compromised? Right now, having unique passwords for each account allows me to compartmentalize access to my accounts. In this case, the attackers would have one less thing to worry about.
Also, is this behavior carried over to the mobile apps?
edit: Nevermind. I was not thinking right. Password resets, as pointed out by many, are always possible with email access.
I have a feeling this is an initial marketing feature for him.
You pull in users who value the convenience and ease of signup and once you reach critical mass the feature no longer yields the percentage of conversion that makes/breaks your venture.
The thing that Instapaper did was different. It allowed you to create an account that did not require authentication at all.
This new thing always requires authentication. It just doesn't use password authentication. You authenticate by verifying that you can use your e-mail account.
I built NoPassword (https://nopassword.alexsmolen.com/), an open source Rails implementation of this design. It was on the front page of Hacker News a few months ago. I use it on another site I'm working on, Agave Society (http://www.agavesociety.org).
I first looked into this sort of solution after reading an article about it what must have been 1.5 years ago. We then implemented it for Toptranslation.com (user can create a password or just use a link to login to their dashboard). I also remember two or more stories about this scheme on HN since, which (of course) I cannot find right now :(
I suppose I started noticing it more once I had actually implemented this process in a public product.
That's an excellent comparison, but from my understanding there's not a concept of ongoing users beyond the author of any individual post. Great point, though, that seems like the highest-profile similar example.
At first this seems to be no different from the password auth: both the password method and the login URL method essentially implement the shared secret scheme, and the rest are technical details.
Except the devil is in the details, as usual: passwords are (or should be) kept and transferred in encrypted form, whereas with the login URL the shared secret is exposed even if transferred over HTTPS.
Other than that, of course, it would be such a relief to dump passwords altogether!
The URL isn't any more exposed than any password would be over HTTPS, that is to say not at all unless you are being MITM'ed by someone who controls a CA in your browser.
True but there's still a way. Unless you've got HSTS enabled most users, if they manually type in the URL, will leave out the protocol altogether which means the server needs to redirect you to https. That's no problem but there's always the chance that someone can perform an https stripping attack and catch the connection before the redirect occurs. Even with HSTS enabled the first time a user does this they're still vulnerable as HSTS cannot be activated until you have an initial https connection.
Chrome's HSTS list solves this but you have to make sure you send the Chromium team an email to add you to the list and even then not everyone uses Chrome. I had them add my app to the list recently which makes me feel warm and fuzzy but its not bullet proof.
In the end, yeah it's a real narrow edge case but as we all have been warned and seen so many times here on HN, those edge cases, no matter how narrow, often end up becoming real at some point. That's not to say I think it'll happen, just saying there is a way.
Right, but that's not the point. I'm not trying to say this passwordless login is flawed or worse than password based login. I just saw a flaw that stuck out and pointed it out. Nothing more.
Wouldn't the URL be in their web server logs? Since the URL only last for an hour it would be a small window (plus their web server was hacked), but you could access other user accounts that way.
Usually username and password are sent via POST not GET so the logs don't have that data (unless you're IEEE and user GET and have your logs available through FTP).
The URL is only valid once, the web server can easily be configured to not log URLs on that subdomain/virtualhost, and if an attacker can read your web server logs you have probably other things you should be more concerned about.
Hmmm, it looks like you might be right. I tried it earlier with one in a private window and it worked twice, but when I just tried again it was invalid/expired (though the email is 50 minutes old).
And I certainly agree that if the server is compromised you've got more problems, but in the IEEE example the server wasn't hacked they just made a mistake by making the logs available.
Edit: yup, I must have made a mistake (not closing private window or using non-private window) in my test.
"but in the IEEE example the server wasn't hacked they just made a mistake by making the logs available"
It seems a bit harsh to judge the strength of an authentication scheme on the metric of "How well does it stand up to a system administrator storing and serving publicly all in-use authentication credentials?"
Sure, this scheme makes errors like that possible, there's always some "assumed competence" about the people deploying the web-app. I'd strongly disagree with, for example, WordPress using this as a default installation option (since there's an assumption that many WordPress users don't understand these sorts of issues) - but for someone like Marco to choose to do this on some software he's written and will likely be the only person to deploy? I'd be happy with him choosing this and understanding the simple risks and the obvious ways to ameliorate them.
(Especially since the only party "hurt" by a failure in the auth scheme is him - worst case scenario seems to me to be that someone stealing a paying subscribers auth url gets to read articles for free - it's not like this is going to expose a potentially useable-elsewhere password or allow the attacker to incur any extra costs to the subscriber.)
> It seems a bit harsh to judge the strength of an authentication scheme on the metric of "How well does it stand up to a system administrator storing and serving publicly all in-use authentication credentials?"
Is it harsh? Would it be harsh to judge an authentication scheme that stores all passwords in plaintext? Server logs don't typically contain data that should be considered secret. IF this authentication scheme led to secret information being stored in a file that wasn't expected to be secure, that would be a major problem, wouldn't it?
This type of authentication hasn't stood up to a large amount of scrutiny, so it is important to think through some attack vectors that might be opened up. This was one I thought up, but it isn't an issue since the tokens are one-shot.
For the record, I like this authentication scheme but that doesn't mean it shouldn't be challenged.
"Is it harsh? Would it be harsh to judge an authentication scheme that stores all passwords in plaintext? Server logs don't typically contain data that should be considered secret."
You're right, but server logs are also not considered to be publicly available, and someone made that mistake in the IEEE example. Server logs can also be configured to store form post data, there's a "simple misconfiguration" that in concert with ther IEEE's error would defeat just about any common auth scheme (it'd even put TOTP 3 factor auth logins at risk for the minute the magic nuber is valid).
You're right - it _should_ be challeneged. But it seems petty clear that the risks associated with auth disclosure here are effectively zero and all borne by Marco not the paying subscriber who's credential is mis-used, and there's no possibility to leverage an exploit of an account here to gain further access elsewhere, even if Marco _did_ fuck up so badly to allow easy discovery of login credentials, this scheme is still entirely suitable for this application. But I don't want my bank to use it.
Oh yes, in this case there is almost no risks for the client but I'm assuming someone will make a django plugin/ruby client/whatever plug-and-play version of this which may not have the same low bar of getting subscriber content on a site where paying is opt-in only.
(I wouldn't mind my bank using this, it's better than what they have in place...)
I do something similar for a small message board used by about 10 friends that has a shared password. All you do is look in your email for the link or bookmark and use the bookmark to log in.
It might seem strange, but some people probably prefer it this way. If your app has a reset password link that grants a session, some percentage of users are going to use reset links pretty much exclusively to get into the app.
This kinda this is what inspired to me to use google authenticators time based OTP's and try to make a service out of it (shameless plug: http://www.gauthify.com), I think theres a solid benefit to be gained from OTPs in a login setting since they're rotated, not memorized, and random.
I built this one night as a sort of example for GAuthify.
Real simple, just checks a user's email against a database, retrieves their unique GAuthify ID, and checks that against the GAuthify API.
This would work if your email address was somehow tied to your browser for "remote logins" (via native implementation? add-on?), and a little popup just showed up.
Or, I think a mobile version where you got a text would work (since typing on a little screen is harder than opening a notification).
Your mobile device has email, right? Mine does. You'd just type your email into the site on mobile, then get the link for your device's browser. You'd have to type email, app switch, the click link. I don't think that is too bad actually.
In fact - it's probably more secure than a normal password scheme! No password hash database to be stolen, no brute force attacks to dodge, no chance of your account being compromised without noticing because you'll get an email if someone tries anything (assuming the cookie is safe and SSL'ed)
This is so obviously useful (it simply skips a few steps in my almost weekly "forgot my password" routine) that there must be a reason why it is not more widespread...
It's not widespread because it adds extra steps for those who do remember their password (switch tab, wait for email, open email, click link), or for those who don't have their email client open (go to gmail.com, log in, open email, click link).
Marco's audience likely reads the magazine from within the appe (where the practice is keep the user logged in indefinitely) or they always have their email client open.
An email can take a long time to reach your inbox, which would make it fairly frequent to have users wait more than one minute (up to several hours) to log in.
Seems to be punting a lot of the security responsibilities regarding the Magazine to the user and email provider. Clever, but perhaps too clever by the half.
Perhaps, but in this particular case - that's probably a perfectly fine trade-off. The "worst case" exploit of this scheme seems to be that someone other than a subscriber gets to read the Magazine. The marginal costs to Marco for that occasionally happening are practically zero - someone who is prepared to steal passwords or read other peoples email accounts to get access to a website was super-unlikely to ever become a paying subscriber anyway. Marco has made it easier for the people who are/might be paying subscribers, and the tiny cost to him of potentially serving up his content to people who steal credentials from real paying subscribers. Since that cost is so low, and the added convenience is of value - why would he _not_ choose this?
(Hell, even if the only result of this scheme was this discussion on HN, I bet it'll turn out revenue positive in spite of the increased fraud risks...)
And I have the same opinion of those sites whose only security is sending reset links to a user's email. But at least with those you don't have to hop back and forth between your email and the site anytime you use a different device or browser.
This link will expire after an hour and can only be used once. To log into multiple browsers, send a login request from each one.
---
It works well, they click the e-mail link, and it saves a cookie to log them in. I think it's a decent solution. It comes down to preference, would you rather type in a password, or click a link e-mailed to you. At times, I have complex passwords, so they take a while to type, and other times, I'd rather type in a password, than access my e-mail on a computer or network of questionable security.
In the end, passwords need to change, and I think in the future they'll disappear. We need smart cards or something along those lines. Click the login button, pass the card over your phone or computer, and you're instantly logged in. The card remains in your wallet like any other.
It would be based on cookies, no different than logging in with a password, then returning at a later date. Instead of typing a password, you click an e-mail link. That's the only difference, and like I said, it comes down to preference.
A number of people have said it provides weaker security, but I disagree. You can guess passwords, you can record or watch someone type a password, or catch the password over insecure protocols. The e-mail approach doesn't have these holes. The link is valid once, so if you login and someone else tries to use the same URL after snooping, it's not possible. With password logins, people can use the password for that site, or your e-mail password to reset the login. With the e-mail method, they need your e-mail password, that's the only way they'll be able to login to your account.
However, you do need secure access to your e-mail. I know there are times when I'm on a public or friends computer, and I need to quickly login to a service. I'd much rather enter my password only used on that service, instead of entering my e-mail password. This way, if it becomes compromised, it would be a much smaller concern.
As a side note, wouldn't someone trying to gain access to my account result in a deluge of password-link spam to my inbox? Or do they have some elegant solution for that.