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...)
