4 ms·

Which cryptographically strong hashing algorithm to use? It depends on situation. I think adaptive one ( PBKDF2, bcrypt, and scrypt) should be used all the time

• huxley 13y ago
  Django reverted the password limit change: "In Django 1.5.5, we’ve reverted this change and instead improved the speed of our PBKDF2 algorithm by not rehashing the key on every iteration." Incidentally Bcrypt does have a 56 byte limit which I understood to be a Blowfish limitation (you can use longer bcrypt passwords by doing a SHA256 pass first) edit: typo
  • borando 13y ago
    Incidentally Bcrypt does have a 56 byte limit This is incorrect; bcrypt has a 72-character limit. Try this in python: import bcrypt, sys salt = "$2a$10$2TmO7iAhRfimvNwvpBn.7e" print bcrypt.hashpw(sys.argv[1], salt) Nearly identical 56 and 57-char inputs produce different hashes: $ python pass.py 12345678901234567890123456789012345678901234567890123456 $2a$10$2TmO7iAhRfimvNwvpBn.7e701F3mp2Z7fpuY/4lu6vUUkrlMEmMou $ python pass.py 123456789012345678901234567890123456789012345678901234567 $2a$10$2TmO7iAhRfimvNwvpBn.7ejJV9jpN0Ahp2RmNAdUGaRxRZndRAs9y Nearly identical 72 and 73-char inputs produce identical hashes: $ python pass.py 123456789012345678901234567890123456789012345678901234567890123456789012 $2a$10$2TmO7iAhRfimvNwvpBn.7e9w2f6/fKQ2QBu1eaIXp4A1WheruxtGK $ python pass.py 1234567890123456789012345678901234567890123456789012345678901234567890123 $2a$10$2TmO7iAhRfimvNwvpBn.7e9w2f6/fKQ2QBu1eaIXp4A1WheruxtGK you can use longer bcrypt passwords by doing a SHA256 pass True, but: Beware! Imagine you're doing bcrypt in C, and the first sha256 output byte is a 0-byte. bcrypt() sees the NUL / empty password and produces a hash trivially breakable by anyone aware of this issue. :-) So I'd recommend doing Base64 on the sha256 hash, if you're using C and you want such long passwords with bcrypt. But plain bcrypt will give the best results. Hopefully the above illustrates the general wisdom of avoiding DIY crypto of any kind. edit: code formatting
    • huxley 13y ago
      EDIT: I was attributing the 56 byte limit incorrectly to hashing, see the reply I made to this comment for what the limit actually seems to be. Maybe it's changed but the paper which defined Bcrypt specifically states: "Finally, the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string)." https://www.usenix.org/legacy/events/usenix99/provos/provos_html/node4.html https://www.usenix.org/legacy/events/usenix99/provos/provos_... which is a subpage of: https://www.usenix.org/legacy/events/usenix99/provos/provos_html/bcrypt.html https://www.usenix.org/legacy/events/usenix99/provos/provos_...
      • huxley 13y ago
        To clear up my own confusion, the 56 bytes only comes in when using bcrypt for encrypting vs hashing, however the "72 character" password limit for hashing is actually 18 words of 32-bits. http://www.gossamer-threads.com/lists/wiki/wikitech/430719#430719 http://www.gossamer-threads.com/lists/wiki/wikitech/430719#4... "Note that much confusion on the web about key lengths with bcrypt ('72' vs. '56' bytes) comes from the fact that there are TWO algorithms called 'bcrypt' which both happen to use Blowfish. One is an encryption algorithm, and the other is a hash algorithm. While they share a common core component, the purposes are thereby entirely different. For the sake of the bcrypt HASHING/key-strengthening algorithm (which we care about now), the 72-byte input parameter is in no way a theoretical problem at all, even for non-Latin UTF-8 based passphrases which eat up 3 bytes per unicode point. The reason is because the text-based passphrase itself needs to 'somehow' be converted into 18 words of 32-bits each anyway. (If we were _encrypting_ then the 56 bytes limit for THAT algorithm would come into play.) Even if you restrict your attention to ASCII it would not be ideal to simply convert ASCII code points to a (zero-padded) juxtaposed stream of 32-bit chunks anyway, because, well for one thing, you would be throwing away entropy due to not using the upper 1-bit range in each char, not to mention the range of unavailable non-printable ASCII characters."
• a3n 13y ago
  > I hate when passwords require certain patterns. I think people started doing this when passwords were typically short, to increase the search space. Although one unwanted side effect is that it also reduces the search space, since if you know that pattern requirement then you know not to brute force anything that doesn't have two letters, two digits etc. But assuming a required pattern of a certain length does the job (whatever the system administrators think "the job" is), I wonder how much longer a password needs to be, with no pattern requirement, and be as difficult or more to crack than the shorter patterned password.
  • M2Ys4U 13y ago
    >I think people started doing this when passwords were typically short, to increase the search space. What annoys me most is when systems have a maximum password length which is something on the order of 10-12 characters. It's needlessly reducing the search space.
    • mistercow 13y ago
      Similarly, when they disallow ordinary ascii characters like punctuation and spaces.
      • a3n 13y ago
        Well, then they're harder to format when printing. :)
  • yeukhon 13y ago
    I think a good password would be something like, instead of writing the letter "a" in ascii, you use "a" in another encoding (I forgot what that called). I supposed no one ever thought of cracking such password yet. The worst I have seen is from USCIS. See this image: http://i.imgur.com/hvyziAx.png http://i.imgur.com/hvyziAx.png
    • eru 13y ago
      > I supposed no one ever thought of cracking such password yet. Good luck with that!