4 ms·

While this is true, hashes use a set number of characters. For example, SHA-256 hashes can be stored in 32-character hex strings. In that sense, there's no poin

While this is true, hashes use a set number of characters. For example, SHA-256 hashes can be stored in 32-character hex strings. In that sense, there's no point in allowing for a variable length field for password hashes.

pyre 14y ago
It's not only dealing with password length. You could DoS the server by tying up all threads in processing the upload. Uploading 4GB isn't instantaneous.
- just2n 14y ago
  That's why the client should perform the hash and only submit the result.
  - derefr 14y ago
    No; this is effectively the same as doing no hashing at all. If your database gets stolen, people can replay the "hashed" passwords from it to the server, without having to hash them themselves.
    - ema 14y ago
      Couldn't you solve that by hashing it again on the sever?
      - codesuela 14y ago
        I'm not sure about the added security benefit. Basically the only additional security is if someone gains access to your server they can't capture plain text passwords anymore but once someone gains access all bets are off and they might as well just switch out the Javascript. In any case you should run a strong hashing algorithm like bcrypt with a salt and oh I don't know 1000 iterations? Also last time I tried something like that (which was a few years ago) I ran into big problems with different hashing algorithm implementations providing different results (JS.md5("password") != Python.md5("password")). Also please correct me if I'm wrong.
        quasque 14y ago
        The added security benefit of server-side hashing is the same as if plain text passwords are sent, to prevent knowledge of the authentication secret if the database contents are disclosed to malicious third parties. The client side hash of the password is only to ensure that a fixed length secret is sent and subsequently processed, to avoid DoS attacks on the server.
        codesuela 14y ago
        Ah I see, thanks for pointing that out. Haven't thought of it myself.
    - just2n 14y ago
      I didn't mean to imply that you'd just store the hash the client comes up with. That's idiotic, of course. Not everyone uses SSL, even though they should, and it's not always secure, and even with the use of SSL, it seems that there would be a potential length attack that could be employed to effectively guess a user's password length. So in all cases, IMO, it makes more sense to be receiving a fixed-length thing that is fairly insensitive to attack in itself. So perhaps a user has 2 salts associated with their account, per password: an auth salt and a storage salt. Then an auth looks something like this: hash(saltFromServer + hash(password)) And then the server would do hash(user.salt + clientHash) I'm not sure, but this seems reasonable to me.
      - ajanuary 14y ago
        Now you have quite a restricted domain, so if your database is compromised there are a lot fewer values an attacker needs to enumerate to try and crack the password.
        just2n 14y ago
        That reasoning doesn't really sit well with me as a mathematician. I would expect the image of MD5 on its codomain is almost a bijection (would love to be demonstrated wrong here, if anyone knows of a paper that studies this, but it seems reasonable that any good hash would have this property). This doesn't really protect against a dictionary attack, but to guarantee a collision, an attacker would still need to try approximately 2^128 passwords for each password in the database, which is already the worst case for the attacker, so no strength is really lost.
      - icebraining 14y ago
        If you don't use SSL and the attacker can sniff the stream, chances are he can inject JavaScript to send him the password. SSL is just indispensable nowadays for authentication.
        drdaeman 14y ago
        And if you have SSL anyway, why use passwords when you can use certificates?
- fruchtose 14y ago
  I'm not arguing with that. I wholly agree with you that a client should not be able to upload 4 GB for the password field. I think I misread your first point as if it dealt with server-side storage.
- jbrechtel 14y ago
  For the application code to complain about password length then the 4gb upload has to have already occurred. Protecting against a DoS attack this way is done in the webserver, which doesn't care about individual fields. Sure this means there's an implicit password length limit, but not in any application-level sense.

pyre 14y ago

It's not only dealing with password length. You could DoS the server by tying up all threads in processing the upload. Uploading 4GB isn't instantaneous.

just2n 14y ago
That's why the client should perform the hash and only submit the result.
- derefr 14y ago
  No; this is effectively the same as doing no hashing at all. If your database gets stolen, people can replay the "hashed" passwords from it to the server, without having to hash them themselves.
  - ema 14y ago
    Couldn't you solve that by hashing it again on the sever?
    - codesuela 14y ago
      I'm not sure about the added security benefit. Basically the only additional security is if someone gains access to your server they can't capture plain text passwords anymore but once someone gains access all bets are off and they might as well just switch out the Javascript. In any case you should run a strong hashing algorithm like bcrypt with a salt and oh I don't know 1000 iterations? Also last time I tried something like that (which was a few years ago) I ran into big problems with different hashing algorithm implementations providing different results (JS.md5("password") != Python.md5("password")). Also please correct me if I'm wrong.
      - quasque 14y ago
        The added security benefit of server-side hashing is the same as if plain text passwords are sent, to prevent knowledge of the authentication secret if the database contents are disclosed to malicious third parties. The client side hash of the password is only to ensure that a fixed length secret is sent and subsequently processed, to avoid DoS attacks on the server.
        codesuela 14y ago
        Ah I see, thanks for pointing that out. Haven't thought of it myself.
  - just2n 14y ago
    I didn't mean to imply that you'd just store the hash the client comes up with. That's idiotic, of course. Not everyone uses SSL, even though they should, and it's not always secure, and even with the use of SSL, it seems that there would be a potential length attack that could be employed to effectively guess a user's password length. So in all cases, IMO, it makes more sense to be receiving a fixed-length thing that is fairly insensitive to attack in itself. So perhaps a user has 2 salts associated with their account, per password: an auth salt and a storage salt. Then an auth looks something like this: hash(saltFromServer + hash(password)) And then the server would do hash(user.salt + clientHash) I'm not sure, but this seems reasonable to me.
    - ajanuary 14y ago
      Now you have quite a restricted domain, so if your database is compromised there are a lot fewer values an attacker needs to enumerate to try and crack the password.
      - just2n 14y ago
        That reasoning doesn't really sit well with me as a mathematician. I would expect the image of MD5 on its codomain is almost a bijection (would love to be demonstrated wrong here, if anyone knows of a paper that studies this, but it seems reasonable that any good hash would have this property). This doesn't really protect against a dictionary attack, but to guarantee a collision, an attacker would still need to try approximately 2^128 passwords for each password in the database, which is already the worst case for the attacker, so no strength is really lost.
    - icebraining 14y ago
      If you don't use SSL and the attacker can sniff the stream, chances are he can inject JavaScript to send him the password. SSL is just indispensable nowadays for authentication.
      - drdaeman 14y ago
        And if you have SSL anyway, why use passwords when you can use certificates?
fruchtose 14y ago
I'm not arguing with that. I wholly agree with you that a client should not be able to upload 4 GB for the password field. I think I misread your first point as if it dealt with server-side storage.
jbrechtel 14y ago
For the application code to complain about password length then the 4gb upload has to have already occurred. Protecting against a DoS attack this way is done in the webserver, which doesn't care about individual fields. Sure this means there's an implicit password length limit, but not in any application-level sense.