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