4 ms·

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 s

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.
      - bullen 5y ago
        Yes, again if the database is compromised, it's compromised... I don't understand why so many people keep mentioning that when HTTPS does not solve that either?!
- SahAssar 5y ago
  If the site isn't served over https why would you trust anything on it with sensetive info like passwords, personal info or payment details? if "HTTPS is a huge waste of electricity" can you please explain to me how to currently secure (in transit) user information entered on my site without it?
  - bullen 5y ago
    1st you shouldn't trust any site with anything. BUT if you trust it with anything it's a password so that only you can prove that you are you. And then you use server side nonce hashing to ONLY compute that part securely wasting only the required cycles one each end to proove you are you period! Then, if for some reason you need additional security on some ulterior action, say a payment, you just do the same trick again. That way you save your servers and the electricity grid from encrypting every meaningless cat picture in the world just because you are paranoid. Electricity is not an energy source, we are going to pay a very high price for it soon. It's the most liquid energy form we have and therefor when oil becomes illiquid (both litteraly and economically because the quality of oil is degrading at a rapid pace) prices in electrons (which have no quality properties that differ) will explode! Again read the RFC https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289, and think about where you want to spend you energy, more customers or less energy for your own kids.
    - SahAssar 5y ago
      > 1st you shouldn't trust any site with anything. Okay, so your proposal is to never use any private info, anywhere, ever on the internet? > Again read the RFC Page 2 of that RFC says > It does not prevent a network eavesdropper from gaining access to private information and does not provide protection against either "social engineering" or active attacks How do you propose to prevent MITM attacks? How do you propose to be able to send private data to a server in a way that is readable by the server?
      - bullen 5y ago
        Nothing is private if you send it somewhere. Embrace the chaos, hide in the noise and save energy!
ale42 5y ago
> Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point. Totally makes sense...

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.
    - bullen 5y ago
      Yes, again if the database is compromised, it's compromised... I don't understand why so many people keep mentioning that when HTTPS does not solve that either?!
SahAssar 5y ago
If the site isn't served over https why would you trust anything on it with sensetive info like passwords, personal info or payment details? if "HTTPS is a huge waste of electricity" can you please explain to me how to currently secure (in transit) user information entered on my site without it?
- bullen 5y ago
  1st you shouldn't trust any site with anything. BUT if you trust it with anything it's a password so that only you can prove that you are you. And then you use server side nonce hashing to ONLY compute that part securely wasting only the required cycles one each end to proove you are you period! Then, if for some reason you need additional security on some ulterior action, say a payment, you just do the same trick again. That way you save your servers and the electricity grid from encrypting every meaningless cat picture in the world just because you are paranoid. Electricity is not an energy source, we are going to pay a very high price for it soon. It's the most liquid energy form we have and therefor when oil becomes illiquid (both litteraly and economically because the quality of oil is degrading at a rapid pace) prices in electrons (which have no quality properties that differ) will explode! Again read the RFC https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289, and think about where you want to spend you energy, more customers or less energy for your own kids.
  - SahAssar 5y ago
    > 1st you shouldn't trust any site with anything. Okay, so your proposal is to never use any private info, anywhere, ever on the internet? > Again read the RFC Page 2 of that RFC says > It does not prevent a network eavesdropper from gaining access to private information and does not provide protection against either "social engineering" or active attacks How do you propose to prevent MITM attacks? How do you propose to be able to send private data to a server in a way that is readable by the server?
    - bullen 5y ago
      Nothing is private if you send it somewhere. Embrace the chaos, hide in the noise and save energy!

ale42 5y ago

> Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point. Totally makes sense...