Log In or Create Account
the-magazine.org
More info on Marco's site: http://www.marco.org/2013/02/24/the-magazine-sharing
I believe this and the way subscriptions are confirmed through the app are elegant solutions.
the-magazine.org
I believe this and the way subscriptions are confirmed through the app are elegant solutions.
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.
Pretty easy to rate-limit that per-email-address. No need to send more than one password-link email per 5 minute or more than a handful a day.
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.
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.
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.
Is this really true? Typically, sites allow you to reset your password with only your email address. What makes this any different?
Interesting to see he is giving it another shot. It looks like the new implementation solves some of the problems brought up in that blog post.
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.
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 suppose I started noticing it more once I had actually implemented this process in a public product.
It now uses either that or Mozilla Persona, which I find better.
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!
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.
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).
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.
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.)
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.
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.
(I wouldn't mind my bank using this, it's better than what they have in place...)
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.
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).
Otherwise, it seems worse than passwords.
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)
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.
(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...)
---
Log into The Magazine by opening this link:
https://the-magazine.org/login/8LvjumLKwNXeBX2zDkxZGuDixUzds...
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.
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.