7

What is the maximum password length I can use with PHP 5.5 password_hash() and password_verify()?

AbraCadaver
  • 78,200
  • 7
  • 66
  • 87
standac
  • 1,027
  • 1
  • 11
  • 26
  • Did you read the doc page on that function? – Justin Wood Sep 13 '13 at 18:56
  • Yes I did. I'm confused because BCRYPT does have a maximum password length. http://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length – standac Sep 13 '13 at 19:05
  • 3
    It's just as stated in linked question - up to 72 characters, but it is not `password_hash()` limit but algorithm limit. Default algorithm may be changed in future, so can number of significant bytes used by it. And it's not really limit, since you can use longer password, just don't expect hash to differ for two passwords that differs only after that character limit. – dev-null-dweller Sep 13 '13 at 20:09
  • @boblapointe Have a look at my update ;) – kelunik Sep 17 '13 at 16:37

4 Answers4

14

Ok, let's go through this.

The function does have a password length limit. Just like all strings in PHP, it is limited to 2^31-1 bytes.

To be clear, there's no way for PHP to deal with anything larger than that (today at least).

So the function itself is limited. But what about the underlying crypto algorithms.

BCrypt is limited to processing the first 72 characters of password. However, this is not commonly a problem as explained in this answer.

So in short, yes it does have an effective limit (it will only "use" the first 72 chars with the default and only algorithm), And no this is not a problem and nor should you try to "fix" or "mitigate" it.

Community
  • 1
  • 1
ircmaxell
  • 163,128
  • 34
  • 264
  • 314
  • 3
    72 character limit on a password / passphrase is certainly a problem, even more when it silently fails to inform you that the extra characters are just ignored. – Toni Homedes i Saun Mar 20 '16 at 07:03
2

password_hash itself doesn't have a length limit.

Blowfish, however

has a 64-bit block size and a variable key length from 32 bits up to 448 bits. It is a 16-round Feistel cipher and uses large key-dependent S-boxes. In structure it resembles CAST-128, which uses fixed S-boxes. (Wikipedia)

Which means an effective limit of 56 characters when using CRYPT_BLOWFISH as the cipher (which is the default).

DaveRandom
  • 87,921
  • 11
  • 154
  • 174
Madara's Ghost
  • 172,118
  • 50
  • 264
  • 308
1

The function doesn't have any limit, you just have to keep your memory_limit in mind, that should be all.

Edit: You should limit the password length, otherwise it could slow down your server (depending on the algo)
see django: https://www.djangoproject.com/weblog/2013/sep/15/security/

Edit 2: to clarify: there shouldn't be a limit to 14-20 characters, it should be 4KB or more.

kelunik
  • 6,750
  • 2
  • 41
  • 70
  • 1
    Wrong! Limiting the password's length is not a good idea. It does not slow the server and only decrease the entropy of your passwords. – Madara's Ghost Sep 17 '13 at 16:42
  • @MadaraUchiha well, do you really think it's a bad idea to set a limit at about 4 KB (see the link in the answer)? Or do you really think anyone would use a 4 KB long password? – bwoebi Sep 17 '13 at 16:48
  • @bwoebi: I don't think there should be a hard limit enforced by your system. Besides, blowfish will cut your password off after several characters. It all depends on your algo. – Madara's Ghost Sep 17 '13 at 16:51
  • @MadaraUchiha Relying on this is not forward-compatible. The might be added another algo which doesn't cut off anything, you just quickly change the algo… and then the problem is there. – bwoebi Sep 17 '13 at 16:55
  • @bwoebi: It is forward compatible if you declare which algo you're using with `password_hash` instead of replying on the default. – Madara's Ghost Sep 17 '13 at 16:56
  • @MadaraUchiha that's not what I meant: I said … when you change it manually (do you really think one would look up how exactly it works?) and then just don't think about this. Then the problem will be there. – bwoebi Sep 17 '13 at 16:59
  • @MadaraUchiha: Please show me anyone who can remember a 4KB password if you want to, 16KB. I just said, a limit, not where the limit should be ;) – kelunik Sep 17 '13 at 17:06
  • @Recode: I sometimes like to provide a hashed string as a password (32 for MD5 or 40 for SHA1). I bet I can find a 4k hash string should I look around, also, regardless of that 4k is a *reasonable* limit. Many sites limit at around 14-20 characters, which is outrageous. – Madara's Ghost Sep 17 '13 at 17:08
  • @MadaraUchiha: I added it to my answer to clarify this. – kelunik Sep 17 '13 at 17:13
  • For ref: [a recent article on this subject](http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/) – Spudley Sep 17 '13 at 20:36
  • @Spudley .@kelunik That django example only shows that a bad *implementation* can cause trouble. They seem to have written PBKDF2 so it scales like WorkFactor * PasswordLength. A decent implementation scales like WorkFactor + PasswordLength, so password length has a negligible effect on performance. The most absurd part of this story is that they "fixed" it by limiting password length, instead of simply fixing their implementation. – CodesInChaos Nov 27 '13 at 11:25
0

There should not be any length limitation to the password_hash function.

Jite
  • 5,761
  • 2
  • 23
  • 37
  • 1
    At least not one that anyone's likely to hit via typing. – Sammitch Sep 13 '13 at 18:57
  • Well yes. I would guess that it could hit memory limits or similar. But I can't imagine that the function itself has any string length limitation. – Jite Sep 13 '13 at 18:59