7 ms·

Funny that old things like basic HTTP auth are regularly rediscovered by developers. There are also other flavours of authentication that can be used in this c

by ale42 5y ago

Funny that old things like basic HTTP auth are regularly rediscovered by developers. There are also other flavours of authentication that can be used in this context, like Digest, supported by all major browsers and only sending hashed passwords (even on plain http connections).

boondaburrah 5y ago
I looked it up and the apache manual apparently recommends HTTP basic over SSL instead of Digest these days since apparently the extra protection isn't considered as worth it relative to just HTTPS-ing the connection.
jamespwilliams 5y ago
Digest auth itself isn't very good though really, even ignoring the obvious problems of not using HTTPS. In the most secure configuration of digest auth, the server stores MD5(username:realm:password), and to authenticate, the server sends server_nonce, and the client sends back client_nonce and MD5(MD5(username:realm:password):server_nonce:client_nonce). The nonces are used to avoid a replay attack. The server MD5s its stored hash with server_nonce:client_nonce and checks if it matches against what the client sent. But if those stored hashes get leaked, an attacker can use them to authenticate. You're in a better position than storing plaintext passwords, because the underlying cleartext probably won't be leaked (they're hashed with MD5, so it's not certain), so your users' credentials can't be used in future credential stuffing attacks, etc. But the attacker still has their credentials on your site. In the other configurations of digest auth, the server ends up storing plaintext passwords (or reversably-encrypted passwords, which is just as bad). See also https://en.wikipedia.org/wiki/Digest_access_authentication#Disadvantages https://en.wikipedia.org/wiki/Digest_access_authentication#D... Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point.
- bullen 5y ago
  I don't understand your point, if the database is leaked the security is compromised... well yes red is red, and green is green and HTTPS improves NOTHING of that. HTTPS is a huge waste of electricity. A more frugal way of securing logins is to use this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Registrations would need additional security but HTTPS with centralized root certificates is NOT one of them.
  - jamespwilliams 5y ago
    Do you agree that storing passwords in plain text is a problem? My point is that storing passwords in a way compatible with using Digest authentication is essentially equivalent to storing your passwords in plain text, at least with respect to your own site’s authentication.
    - bullen 5y ago
      You don't store them as plain text, you store them as hashes. And then you send a server salt/nonce and the browser hashes the plain text password with the salted hash in your database and then with the server salt/nonce. Still HTTPS solves nothing of that. I don't even know what Digest is... I'm talking this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289
  - thayne 5y ago
    You shouldn't store a password in plaintext in your database. So if your database is leaked, they don't have the user's actual passwords. But with the digest scheme, you can't store a hash of the digest, because if all you have is Hash2(Hash1(username:realm:password)) and the nonces, then you can't compute Hash1(Hash1(username:realm:password):server_nonce:client_nonce), assuming that Hash2 is irreversible, which you want it to be.
    - bullen 5y ago
      > Hash1(Hash1(username:realm:password):server_nonce:client_nonce) client_nonce? This is how the RFC works: Hash(Hash(username:password):server_nonce) What is the difference between Hash1 and Hash2? Hash(username:password) is what you store in the database != plain text. Also what is realm?
      - thayne 5y ago
        > client_nonce? Yes, the client also generates a nonce that is included in the digest. The full digest (according to RFC 2617) is (assuming qop is used): request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> > What is the difference between Hash1 and Hash2? Hash1 is the hash algorithm for the authorization digest, so MD5 or maybe SHA256 (although only firefox currently supports that). Hash2 is the hash algorithm (including salting) used on the server to hash the hash of the username password before storing in the database. > Hash(username:password) is what you store in the database != plain text. The password isn't plaintext, but if the Hash(username:password) is compromised that gives an attacker enough information to impersonate that user. The attacker can just use that `Hash(username:password)` to compute the digest, they don't need to know the original password.
- ale42 5y ago
  > Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point. Totally makes sense...
deleted 5y ago
[deleted]
bullen 5y ago
A long time ago we had to work around disabled cookies by appending the session to every request URL... that was a fun time adding the session to all those <a href>... But for the simple hashing it's an old RFC that I like to quote to HTTPS fools: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Way better login than moving your whole site, including cat pictures, to encryption.
- AtlasBarfed 5y ago
  OMG, do you know how hard it was back in the early cHTML/WML/HDML days and dozens of different browsers? Glad that was a temporary state of things.

by ale42 5y ago

boondaburrah 5y ago

I looked it up and the apache manual apparently recommends HTTP basic over SSL instead of Digest these days since apparently the extra protection isn't considered as worth it relative to just HTTPS-ing the connection.

jamespwilliams 5y ago

Digest auth itself isn't very good though really, even ignoring the obvious problems of not using HTTPS. In the most secure configuration of digest auth, the server stores MD5(username:realm:password), and to authenticate, the server sends server_nonce, and the client sends back client_nonce and MD5(MD5(username:realm:password):server_nonce:client_nonce). The nonces are used to avoid a replay attack. The server MD5s its stored hash with server_nonce:client_nonce and checks if it matches against what the client sent. But if those stored hashes get leaked, an attacker can use them to authenticate. You're in a better position than storing plaintext passwords, because the underlying cleartext probably won't be leaked (they're hashed with MD5, so it's not certain), so your users' credentials can't be used in future credential stuffing attacks, etc. But the attacker still has their credentials on your site. In the other configurations of digest auth, the server ends up storing plaintext passwords (or reversably-encrypted passwords, which is just as bad). See also https://en.wikipedia.org/wiki/Digest_access_authentication#Disadvantages https://en.wikipedia.org/wiki/Digest_access_authentication#D... Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point.

bullen 5y ago
I don't understand your point, if the database is leaked the security is compromised... well yes red is red, and green is green and HTTPS improves NOTHING of that. HTTPS is a huge waste of electricity. A more frugal way of securing logins is to use this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Registrations would need additional security but HTTPS with centralized root certificates is NOT one of them.
- jamespwilliams 5y ago
  Do you agree that storing passwords in plain text is a problem? My point is that storing passwords in a way compatible with using Digest authentication is essentially equivalent to storing your passwords in plain text, at least with respect to your own site’s authentication.
  - bullen 5y ago
    You don't store them as plain text, you store them as hashes. And then you send a server salt/nonce and the browser hashes the plain text password with the salted hash in your database and then with the server salt/nonce. Still HTTPS solves nothing of that. I don't even know what Digest is... I'm talking this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289
- thayne 5y ago
  You shouldn't store a password in plaintext in your database. So if your database is leaked, they don't have the user's actual passwords. But with the digest scheme, you can't store a hash of the digest, because if all you have is Hash2(Hash1(username:realm:password)) and the nonces, then you can't compute Hash1(Hash1(username:realm:password):server_nonce:client_nonce), assuming that Hash2 is irreversible, which you want it to be.
  - bullen 5y ago
    > Hash1(Hash1(username:realm:password):server_nonce:client_nonce) client_nonce? This is how the RFC works: Hash(Hash(username:password):server_nonce) What is the difference between Hash1 and Hash2? Hash(username:password) is what you store in the database != plain text. Also what is realm?
    - thayne 5y ago
      > client_nonce? Yes, the client also generates a nonce that is included in the digest. The full digest (according to RFC 2617) is (assuming qop is used): request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> > What is the difference between Hash1 and Hash2? Hash1 is the hash algorithm for the authorization digest, so MD5 or maybe SHA256 (although only firefox currently supports that). Hash2 is the hash algorithm (including salting) used on the server to hash the hash of the username password before storing in the database. > Hash(username:password) is what you store in the database != plain text. The password isn't plaintext, but if the Hash(username:password) is compromised that gives an attacker enough information to impersonate that user. The attacker can just use that `Hash(username:password)` to compute the digest, they don't need to know the original password.
ale42 5y ago
> Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point. Totally makes sense...

deleted 5y ago

[deleted]

bullen 5y ago

A long time ago we had to work around disabled cookies by appending the session to every request URL... that was a fun time adding the session to all those <a href>... But for the simple hashing it's an old RFC that I like to quote to HTTPS fools: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Way better login than moving your whole site, including cat pictures, to encryption.

AtlasBarfed 5y ago
OMG, do you know how hard it was back in the early cHTML/WML/HDML days and dozens of different browsers? Glad that was a temporary state of things.