4 ms·

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 sc

by 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?!
    - thayne 5y ago
      If a database of passwords is compromised, but the passwords are properly hashed and salted (server-side, not client-side), then you would need a rainbow table for each salt in order to actually get something usable from the compromised data.
      - bullen 5y ago
        Ok, how does HTTPS help with that? And who cares if you need a rainbow table?
        thayne 5y ago
        > how does HTTPS help with that Ignoring all the other benefits of HTTPS, it means you can securely transfer the password itself to the server, or a deterministic hash of the password which the server hashes again. Not to mention that you can use a stronger hashing algorithm, like bcrypt. There might be other ways to do this, but https is definitely the most practical. > who cares if you need a rainbow table? If the passwords are moderately strong and you are using a good hashing algorithm (that is salted), then creating a big enough rainbow table (or brute forcing) is intractable.
catlifeonmars 5y ago
This is vulnerable to 2nd preimage attacks. As a rule of thumb, you should use HMAC whenever you are concatenating values.
- bullen 5y ago
  Can you exaplin what a "2nd preimage attack" is and how HMAC solves it? If it's an attack you can do after the database is compromised it's not very interesting, and if it's an attack you can do over the wire then you can just limit the number of login attempts per some duration no?
  - catlifeonmars 5y ago
    I can try to explain, but this answer on the theoretical computer science stackexchange does it much better: https://cstheory.stackexchange.com/a/591 https://cstheory.stackexchange.com/a/591 There are numerous ways to accidentally introduce a weakness to 2nd preimage resistance. Using an HMAC is a way to “reset” the entropy of a hash key and eliminate any unwanted source of information leakage.
- thayne 5y ago
  which is itself a problem with using the Digest method from RFC 2617

by thayne 5y ago

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?!
  - thayne 5y ago
    If a database of passwords is compromised, but the passwords are properly hashed and salted (server-side, not client-side), then you would need a rainbow table for each salt in order to actually get something usable from the compromised data.
    - bullen 5y ago
      Ok, how does HTTPS help with that? And who cares if you need a rainbow table?
      - thayne 5y ago
        > how does HTTPS help with that Ignoring all the other benefits of HTTPS, it means you can securely transfer the password itself to the server, or a deterministic hash of the password which the server hashes again. Not to mention that you can use a stronger hashing algorithm, like bcrypt. There might be other ways to do this, but https is definitely the most practical. > who cares if you need a rainbow table? If the passwords are moderately strong and you are using a good hashing algorithm (that is salted), then creating a big enough rainbow table (or brute forcing) is intractable.

catlifeonmars 5y ago

This is vulnerable to 2nd preimage attacks. As a rule of thumb, you should use HMAC whenever you are concatenating values.

bullen 5y ago
Can you exaplin what a "2nd preimage attack" is and how HMAC solves it? If it's an attack you can do after the database is compromised it's not very interesting, and if it's an attack you can do over the wire then you can just limit the number of login attempts per some duration no?
- catlifeonmars 5y ago
  I can try to explain, but this answer on the theoretical computer science stackexchange does it much better: https://cstheory.stackexchange.com/a/591 https://cstheory.stackexchange.com/a/591 There are numerous ways to accidentally introduce a weakness to 2nd preimage resistance. Using an HMAC is a way to “reset” the entropy of a hash key and eliminate any unwanted source of information leakage.
thayne 5y ago
which is itself a problem with using the Digest method from RFC 2617