6 ms·

You are only storing the hash of the password so there is no reason to have arbitrary length constraints like 32. Why not make it several thousand characters?

• masklinn 7y ago
  Yep. You do want a limit though as you don’t want random attackers to DOS your login server by feeding megabytes you your kdf.
• txcwpalpha 7y ago
  There is actually a reason (though 32 seems pretty short. Something like 256 is probably more reasonable). Several thousand characters (or worse, unlimited length) opens up your attack to a form of DDoS where you can exploit the fact that password hashing is a computationally heavy operation. See here: https://arstechnica.com/information-technology/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/ https://arstechnica.com/information-technology/2013/09/long-... > Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large—and guaranteed-to-fail—passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher. This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.
  • tomtomtom777 7y ago
    Isn't this mitigated by hashing the password on the client (in addition to hashing it on the server).
    • GordonS 7y ago
      But couldn't an attacker just skip the client-side hashing?
      • Dylan16807 7y ago
        Then the server will reject it for being the wrong size.
        • GordonS 7y ago
          The GP suggested it would also be hashed by the server - presumably because you can't trust client input.
          • Dylan16807 7y ago
            You would hash it on the server because you don't want to turn the 'hash' into a plain-text password. But instead of the server accepting an arbitrary string, it only accepts hexadecimal or base64 strings of a specific length. Which solves the problem.
            • GordonS 7y ago
              I'm not quite understanding the protocol here. If the client sends only a hex/base64 string, how can the server trust that it's the result of a password being fed to a KDF?
              • Dylan16807 7y ago
                It doesn't matter. The threat model is: Password is too long, lots of CPU is wasted, denial of service. By only accepting strings of a certain length, the threat is defeated. The client could send an intentionally bad password even if they weren't lying. If they lie, only the client is harmed, and in a non-new way. So this scheme has one notable upside, and no notable downside. There are better solutions, but this one is valid.
                • GordonS 7y ago
                  Hmm, I can see some benefits to the scheme, such as using the client's CPU cycles, and the plaintext password never having to be sent to my servers. Maybe it's just that it's not the norm, but I'm still unsure I'd actually use this scheme. As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries. TBH, my preferred solution here is never to silently truncate passwords, and just to set a "sensible" limit on password length, e.g. 256 characters. Yes, it's still an arbitrary limit, but it should be long enough to cover 99.9999% of users.
    • Hamuko 7y ago
      How?
  • Dylan16807 7y ago
    The real problem there is using an algorithm that gets slower on longer passwords. There's no need to have a cap bigger than a kilobyte though.
    • rcxdude 7y ago
      Is there a cryptographic hash algorithm that doesn't? It seems like that would make it non-cryptographic (since you will need to read each byte at least once).
      • Dylan16807 7y ago
        Reading each byte once only takes a few microseconds. That's not the issue. What you need is for the slow core of the algorithm to be fixed-speed. Either by only reading the input bytes during initialization, or by only feeding a fixed number of input bytes into the core during each round.
  • SAI_Peregrinus 7y ago
    55 would make sense if they are using bcrypt. But since it's 32, they're probably not actually securely storing (password hashing) them at all.