Is it worth padding passwords?

Question

I'm using phpass (bcrypt) to hash the password and SSL when it's transmitted, and using PDO (with PHP) to stop injections, is it worth padding the password, so that if the user enters "123456" as the password before it's hashed a prefix and/or suffix are added, so for example

becomes

abcZYX123456£%$£@&$%

(prefix "abcZYX" and suffix "£%$£@&$%")

which is then salted and hashed.

the prefix and suffix could be the same or different for every password

or could it be better to require minimum lengths and combinations

For example:

Must be at least 10 characters, and have a capital letter, number and symbol

Or is it better to just hash and salt the password?

You could run into problems with inconsistent representations of the `£` character. — Keith Thompson, Jun 03 '13 at 18:29
@KeithThompson I've never had that problem yet (I'm using UTF-8 in the db and code), any idea what may cause that problem? — Ray Britton, Jun 04 '13 at 09:05
For example Windows likes to use UTF-16 (or Windows-1252) for non-ASCII characters. Using UTF-8 consistently is probably the best solution, but not all languages have very good Unicode support. — Keith Thompson, Jun 04 '13 at 15:44

score 2 · Accepted Answer · answered Jun 03 '13 at 15:03

2

You are better off enforcing a length requirement, since you are already using a strong password hashing algorithm. Since the "padding" is added in the code of your site, it is not strongly protected. Even in the best case, when an attacker does not know the padding, if a user is allowed to pick a short enough password, it is conceivable that it would be cracked, revealing the padding scheme.

For complexity requirements, it is probably best to just give some instant feedback (JavaScript) on the strength of the password to the user as they choose their password. Users will balk at strictly-enforced policies (other than length, within reason), and your choice of algorithm should provide enough resistance to cracking for passwords of a reasonable length.

answered Jun 03 '13 at 15:03

bonsaiviking

11,456
1
27
50

I was just about to ask why it makes no difference, and then it stuck me why it was useless. In fact it seems obvious now. – Ray Britton Jun 03 '13 at 15:45
Actually, I have a question, I can think of these scenarios: 1) Database is stolen, code on server is fine 2) Database is stolen, code on server is also stolen 3) Database is fine, code is stolen 4) Niether are stolen, attempted brute force via repeated login (By stolen I mean either view, copied and/or removed) In 2,3,4 the padding makes no difference but in 1 it does, so shouldn't I do it anyway? – Ray Britton Jun 04 '13 at 09:08
1

In general, you shouldn't mess with security functions on your own because 1) you may introduce bugs, 2) you break modularity (e.g. I can't change that, it'll break my padding scheme), 3) you make code maintainers go WTF. For more discussion, see [this question](http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough), where something like your scheme (but even more "unbreakable") is discussed. – bonsaiviking Jun 04 '13 at 14:09
1

@RayBritton In general, the crypto you choose should be good enough that you can trust it. If you have to bolt on your own stuff, then you should instead choose better crypto. One other thing you could do is to seed the database with "bogus" accounts (hashes based on 32 bytes of random garbage) to slow down an offline attack. Just don't make them obviously bogus (same creation date, same name, sequential usernames, etc). – bonsaiviking Jun 04 '13 at 14:12

score 1 · Answer 2 · answered Jun 03 '13 at 15:00

I don't see much point to the padding scheme you describe.

If the attacker is performing an online bruteforce, his attempts will be going through your padding scheme anyway so there isn't a point.

If the attacker has obtained a hash dump and is attempting an offline attack against the hashes, the padding scheme might slow down an attacker somewhat if he did not also compromise your source code in the process. Of course, since the padding scheme is fixed it probably will not take an attacker long to figure out your padding scheme and add it to his password cracking process.

Password complexity requirements can be a good idea as long as you do not overdo it. There are plenty of existing questions on the site addressing this very issue, do a search for them.

Overall, you are on the right track for password storage. bcrypt with a large iteration count should be sufficient. I don't think that padding scheme is necessary or useful.

score 1 · Answer 3 · answered Jun 03 '13 at 15:03

Adding a prefix has value in certain specific scenarios, however in general what you are proposing adds no security. An offline attacker will either know the prefix, or find it out very quickly, at that point the padding has zero effect on the rate at which he can crack hashes.

You are already doing the right thing by using bcrypt, putting you miles ahead of the curve, so good job.

Is it worth padding passwords?

3 Answers3