4 ms·
>If the user types qwe123 to log in, and you hash that in Javascript to 200820e3227815ed1756a6b531e7e0d2 ... By your own words it's already been run through on
by rl3 6y ago
>If the user types qwe123 to log in, and you hash that in Javascript to 200820e3227815ed1756a6b531e7e0d2 ...
By your own words it's already been run through one hash algorithm. Even considering it's being hashed again on the server, that still isn't plaintext.
The plaintext here is qwe123, because that's the raw user input. If it avoids further pedantry, we can agree to call it cleartext if you prefer.
- thaumasiotes 6y agoA hash algorithm is not a supernatural function which changes the metaphysical character of data. Whether something is plaintext or ciphertext depends on what you're doing with it. And to the server in this example, 200820e3227815ed1756a6b531e7e0d2 and qwe123 are exactly equivalent strings. All the server does is run a hash function and record the result. That result is the ciphertext, and the input is the plaintext, no matter how the input was generated.
- rl3 6y ago>A hash algorithm is not a supernatural function which changes the metaphysical character of data. Again with the condescension. >And to the server in this example, 200820e3227815ed1756a6b531e7e0d2 and qwe123 are exactly equivalent strings. Except they're not, because the former is presumed to be salted client-side, and it is not always true that the attackers [who have compromised the server in some manner] will end up knowing that salt. There are innumerable schemes that can render gaining knowledge of the salt difficult if not impossible, especially in the case of a server exploit that's limited in scope.