4 ms·

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,

by mojuba 14y ago

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!

0x0 14y ago
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.
- bpatrianakos 14y ago
  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.
  - 0x0 14y ago
    The same attack you're describing could easily be used to steal a password-based login, too.
    - bpatrianakos 14y ago
      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.
- mjschultz 14y ago
  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).
  - 0x0 14y ago
    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.
    - mjschultz 14y ago
      > The URL is only valid once 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.
      - bigiain 14y ago
        "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.)

by mojuba 14y ago

0x0 14y ago

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.

bpatrianakos 14y ago
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.
- 0x0 14y ago
  The same attack you're describing could easily be used to steal a password-based login, too.
  - bpatrianakos 14y ago
    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.
mjschultz 14y ago
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).
- 0x0 14y ago
  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.
  - mjschultz 14y ago
    > The URL is only valid once 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.
    - bigiain 14y ago
      "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.)