4 ms·

Entropy is defined by the password. The hash is deterministic.

• xondono 6y ago
  Maximum entropy is defined by the password, the hash can reduce it.
  • MiroF 6y ago
    As long as the entropy of the client hash and of the server hash is the same, I still fail to see how this is a problem.
    • xondono 6y ago
      AFAIK there isn’t a good reason to do that. To be useful the hash should turn your password into a OTP, at which point it’s no longer a hash
      • lordlimecat 6y ago
        > To be useful the hash should turn your password into a OTP I'm not clear why you think this would be so. Hashes (with salts) prevent attackers from being able to derive the password, and can also be used in conjunction with nonces to prevent replay attacks.
        • xondono 6y ago
          The point is that you are not achieving much. You need both parties to know the nonce and the salt for this to work, so you’ll need to send it over. At this point what value are you gaining over just sending the password?
          • lordlimecat 6y ago
            >You need both parties to know the nonce and the salt for this to work, so you’ll need to send it over. I get the impression you don't understand what the nonce and salt are, so I'll break it down. The salt is used to make the hashes for particular values unique to this site. It generally does not change across the site, but it makes it impractical to use pre-computed hash tables to find the original values for a given hash. By using a salt, the site ensures that transmitted hashes cannot be trivially reversed. The nonce is used to allow the use of an HMAC to create a one-time hash that cannot be reused. This would typically be implemented as follows: 1. Service sends NONCE, SALT 2. Client Sends password as SHA256(SHA256(ClientPasswd + SALT) + NONCE) 3. Service Computes SHA256(StoredSaltedHash + NONCE), confirms that it matches what the user sent 4. If the two match, the user is authed. An attacker cannot reuse what the client sent because the nonce is not reused, and he cannot fake the nonced hash because he does not know either the password or the StoredSaltedHash.
            • dancodes 6y ago
              As a 3rd party who thought he understood this, but then realized he didn't: thank you for explaining it
            • xondono 6y ago
              Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same password, and that can make the hash way less effective in obscuring the passwords if/when leaked. There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts. There are a bunch of them covering the most frequent passwords. Since you are using the same salt for the whole site, two users with the same password have the same StoredSaltedHash, so you order by number of repetitions, and the most frequent is likely one of those ("123456" tended to be the most popular the last time I checked). This exposes your salt and then it's game over. What I'm trying to get across (and failing apparently) is that this is still vulnerable to lots of attacks, which means that you'll have to use HTTPS underneath all of this. Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security.
  • lordlimecat 6y ago
    Hashes do reduce it, by an amount determined by the hash size and algorithm. This has nothing to do with client vs server. SHA1 of STRING will always have the same entropy wherever it is computed; it must, for the hashing to work. EDIT: I suspect you are confusing PRNGs or KDFs with hashing. Entropy is relevant with the former, not the latter.