3 ms·

Application designers want to control the login/logout experience for users This could have been achieved by allowing a custom form in the 501 response page.

by mansr 16y ago

Application designers want to control the login/logout experience for users This could have been achieved by allowing a custom form in the 501 response page. Where do you put the "Forgot password?" option on a site that uses HTTP auth? Also in the 501 response. 404 pages have been tailored to great extremes. Why not the 501s? The "advanced" stuff you can do with HTTP auth [...] isn't a real security win, especially vs. form-auth and TLS. Digest auth has the distinct advantage that the password is never sent to the server at all. With forms over TLS the password can be intercepted on the server doing the validation. With digest auth this is not possible. There are a couple minor changes all browsers could make [...]; this would cost many tens of millions of dollars The real question is, why didn't browsers evolve in that direction to begin with, before too much was invested in form-based authentication?

tptacek 16y ago
Ok, your proposal is, "application designers will control the login experience by invoking a browser-controlled popup box over which they have virtually no control, and then, when that popup fails, they can do a really creative error page". I think you're making my point for me. Your point about the security of digest auth appears to be the actual inverse of reality. Allowing for the fact that I could be wrong, since I think about HTTP Authentication very rarely in my professional career, since nobody uses it and nobody ever will, can you account for the fact that in order to verify digests, the server actually needs to store the plaintext of the password, and not a hash? This is exactly the problem SRP was designed to solve. Browsers didn't evolve in this direction because HTTP Auth was never a win over form auth. Form login is prettier than HTTP authentication, it's more usable, it's less intrusive, it's more flexible, it's easier to implement, 90% of it is required anyways since every app in the universe still needs a secure session store, and its future-proof.
- falien 16y ago
  >can you account for the fact that in order to verify digests, the server actually needs to store the plaintext of the password, and not a hash? That was my first thought too, but apparently doesn't have to be the case. http://en.wikipedia.org/wiki/Digest_access_authentication#Advantages http://en.wikipedia.org/wiki/Digest_access_authentication#Ad... On the other hand, wikipedia also points out my other gut reaction to the article, which is that forms over https basically provide all the same advantages without most of the drawbacks.
  - tzs 16y ago
    At first that appears to not store the plaintext of the password, but looking closer, isn't it really using the hash as a password? That is, if the bad guys got a copy of the hashes stored on the server, they could use a modified client to log in. The protocol is requiring the client to prove that the client knows that hash, not that the client knows the password, if I'm reading it right (I might not be).
    - tptacek 16y ago
      Yes, the intermediate hash is password-equivalent, but at least you haven't (directly) handed over your Google Mail password at the same time. SRP was designed, in part, to make the serverside storage of passwords crypto-hard to break. It's an elegant protocol, but it's a little more complex than digest auth. None of this stuff is anywhere nearly as safe as bcrypt and TLS with form auth. Digest HTTP auth can, in fact, make you even less safe than unencrypted form auth.
  - tptacek 16y ago
    You're right; if you go out of your way, you can instead store an extraordinarily viciously crackable derivative of the password. I'd stick with basic auth and use BCrypt on the server; you're far more likely to lose your whole password database than you are to lose a significant number of basic auth logins to interception.
- caf 16y ago
  No, that's not his proposal. The 401 message (which is what he meant to say) is what prompts the browser to display the popup box in the first place. The idea would be that if you provide a custom form there, the browser displays your custom form (in the browser window) in place of the default popup. Then all you need to add is a couple of Javascript methods to allow that custom form to set the HTTP Auth parameters and retry (you could even use a special form target for that, if you wanted to, avoiding Javascript entirely).
epochwolf 16y ago
Don't you mean 401 (Unauthorized) not 501 (Not Implemented)? http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
- mansr 16y ago
  Yes, sorry. Too long since I messed with it.
mseebach 16y ago
501 is "not implemented", I don't see how that's relevant? The server sends a "401 Unauthorized", which is what prompts the browser to show the password prompt. The thing is, I've seldom seen such a page -- because the browser shows me a login prompt. On face value, I tend to agree with the OP that it would be cleaner if we could use HTTP auth for real things. In practise, there's simply so much missing from the equation, combined with a very mature selection of software that makes this very easy to do in any webapp, to be something worth wasting efforts on.
- tptacek 16y ago
  Is it really even cleaner? I understand why people say that --- because web services clients usually don't have a notion of "cookies" --- but at pretty much the same level of security and convenience as HTTP Authentication, you can also issue persistent access tokens. I don't see how a token is in any way inferior to embedding authentication in an HTTP header.
  - mseebach 16y ago
    It's cleaner because you, in theory, can outsource an entire functionality class to your infrastructure. Less complexity for you to deal with. A bit like serving static files - you put your files in a directory, and they're not only served, they're served faster, better and more reliably and scalable than whatever you can code as part of your app.
    - tptacek 16y ago
      The end to end argument suggests that stuffing things down into lower layers of the stack usually isn't cleaner.
      - mseebach 16y ago
        I don't understand the end to end argument then? I'd say it's a huge win for cleanliness that I never need to touch a buffer in my life, but can still build and deploy high performance web apps, because I can build on the Apaches/nginx/whatevers of the world. Requiring users to log in in modern web stacks is indeed just a question of setting a flag, and it's done for you, you never need to know about, let alone consider encryption of, session cookies, so this is outsourced down the stack (and sufficiently clean for anything I can think of). Just not as far down as the HTTP standard suggests is possible.

by mansr 16y ago

tptacek 16y ago

Ok, your proposal is, "application designers will control the login experience by invoking a browser-controlled popup box over which they have virtually no control, and then, when that popup fails, they can do a really creative error page". I think you're making my point for me. Your point about the security of digest auth appears to be the actual inverse of reality. Allowing for the fact that I could be wrong, since I think about HTTP Authentication very rarely in my professional career, since nobody uses it and nobody ever will, can you account for the fact that in order to verify digests, the server actually needs to store the plaintext of the password, and not a hash? This is exactly the problem SRP was designed to solve. Browsers didn't evolve in this direction because HTTP Auth was never a win over form auth. Form login is prettier than HTTP authentication, it's more usable, it's less intrusive, it's more flexible, it's easier to implement, 90% of it is required anyways since every app in the universe still needs a secure session store, and its future-proof.

falien 16y ago
>can you account for the fact that in order to verify digests, the server actually needs to store the plaintext of the password, and not a hash? That was my first thought too, but apparently doesn't have to be the case. http://en.wikipedia.org/wiki/Digest_access_authentication#Advantages http://en.wikipedia.org/wiki/Digest_access_authentication#Ad... On the other hand, wikipedia also points out my other gut reaction to the article, which is that forms over https basically provide all the same advantages without most of the drawbacks.
- tzs 16y ago
  At first that appears to not store the plaintext of the password, but looking closer, isn't it really using the hash as a password? That is, if the bad guys got a copy of the hashes stored on the server, they could use a modified client to log in. The protocol is requiring the client to prove that the client knows that hash, not that the client knows the password, if I'm reading it right (I might not be).
  - tptacek 16y ago
    Yes, the intermediate hash is password-equivalent, but at least you haven't (directly) handed over your Google Mail password at the same time. SRP was designed, in part, to make the serverside storage of passwords crypto-hard to break. It's an elegant protocol, but it's a little more complex than digest auth. None of this stuff is anywhere nearly as safe as bcrypt and TLS with form auth. Digest HTTP auth can, in fact, make you even less safe than unencrypted form auth.
- tptacek 16y ago
  You're right; if you go out of your way, you can instead store an extraordinarily viciously crackable derivative of the password. I'd stick with basic auth and use BCrypt on the server; you're far more likely to lose your whole password database than you are to lose a significant number of basic auth logins to interception.
caf 16y ago
No, that's not his proposal. The 401 message (which is what he meant to say) is what prompts the browser to display the popup box in the first place. The idea would be that if you provide a custom form there, the browser displays your custom form (in the browser window) in place of the default popup. Then all you need to add is a couple of Javascript methods to allow that custom form to set the HTTP Auth parameters and retry (you could even use a special form target for that, if you wanted to, avoiding Javascript entirely).

epochwolf 16y ago

Don't you mean 401 (Unauthorized) not 501 (Not Implemented)? http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

mansr 16y ago
Yes, sorry. Too long since I messed with it.

mseebach 16y ago

501 is "not implemented", I don't see how that's relevant? The server sends a "401 Unauthorized", which is what prompts the browser to show the password prompt. The thing is, I've seldom seen such a page -- because the browser shows me a login prompt. On face value, I tend to agree with the OP that it would be cleaner if we could use HTTP auth for real things. In practise, there's simply so much missing from the equation, combined with a very mature selection of software that makes this very easy to do in any webapp, to be something worth wasting efforts on.

tptacek 16y ago
Is it really even cleaner? I understand why people say that --- because web services clients usually don't have a notion of "cookies" --- but at pretty much the same level of security and convenience as HTTP Authentication, you can also issue persistent access tokens. I don't see how a token is in any way inferior to embedding authentication in an HTTP header.
- mseebach 16y ago
  It's cleaner because you, in theory, can outsource an entire functionality class to your infrastructure. Less complexity for you to deal with. A bit like serving static files - you put your files in a directory, and they're not only served, they're served faster, better and more reliably and scalable than whatever you can code as part of your app.
  - tptacek 16y ago
    The end to end argument suggests that stuffing things down into lower layers of the stack usually isn't cleaner.
    - mseebach 16y ago
      I don't understand the end to end argument then? I'd say it's a huge win for cleanliness that I never need to touch a buffer in my life, but can still build and deploy high performance web apps, because I can build on the Apaches/nginx/whatevers of the world. Requiring users to log in in modern web stacks is indeed just a question of setting a flag, and it's done for you, you never need to know about, let alone consider encryption of, session cookies, so this is outsourced down the stack (and sufficiently clean for anything I can think of). Just not as far down as the HTTP standard suggests is possible.