1

I've been reading lots on stackoverflow specifically about security for login passwords. I read that security is enhanced when a variety of character sets are used and/or longer passwords. Thus, something other than a-z, A-Z, 0-9 to include things like 'special' French, German or Spanish characters (umlauts, accents etc), and passwords that are 20 characters are better than passwords with eight characters.

This got me thinking - let's say I force my users to input a password, minimum 8 characters in length, to include number, uppercase, lowercase character. Let's say that I always apply a 1000 character fixed string to the password (so its hardcoded in the javascript and viewable to the client via view source).

Once a strong hash is made out of this extended string, have I enhanced my security in anyway, or is the fact that the hard coded string being public not offer me anything extra?

I suspect that if someone wanted to perform a dictionary attack, by appending a 1000 character string to the source I slow them down because the hash would take longer to compute since it would be computed on an extra long string? True or not?

Anders
  • 65,052
  • 24
  • 180
  • 218
fiprojects
  • 151
  • 6
  • 3
    Extra security isn't really achieved by forcing users to use extended character sets. It is achieved by *allowing* them. If I allow users to use a mix of case, numbers and special characters, even users who don't use them get some benefit. If only against brute force though not against dictionary attacks of course. – Julian Knight Sep 17 '16 at 19:53

3 Answers3

6

No, this is not a good idea. Since the appended string is public, the attacker would just append it as well to all the words in the dictionary when doing a brute force attack.

You argue that the increase in time from hashing a long string instead of a short would slow down the attack, but the effect would probably be small. More importantly, modern hash functions like PBKDF2 and bcrypt are already designed to be slow and have a build in way to make them slower by allowing you to set a cost factor parameter. If you want to slow an attacker down, just increase that. No need to come up with your own home brewed solution.

If you are not using a modern password hashing algorithm, then this is the time to fix that instead of considering hacks like this.

If you were to keep the string a secret (by appending it at the server instead of at the client) then it would be a pepper. That is a commonly used technique to increase the security of password hashes, but it could be argued that just encrypting the hashes is a better solution.

Community
  • 1
Anders
  • 65,052
  • 24
  • 180
  • 218
2

Yes and no. If you change your solution a little, append a lot of random bytes on server side, and different random bytes for each user, you will have a 'salt', it's a good approach and make your passwords resistant to rainbow tables.

But in your case, no, you will just make a mess. Think about migrating this system, some javascript code on client side, will be hard to find and port. As password hashing/salting is something that is almost a universal pattern to implement on server side.

About the cracking complexity, let's talk about your scenario. Let's imagine that some attacker get your whole database, 10k users, and he knows your random 102400 bytes prefix, and all the users use the same prefix. If you use md5 for example (something that I don't recommend), you have the processing cycles, where some amount of data is read and processed into the algorithm, changing its internal state, which will change the final hash value.

If you have some initial big string, you just input it to md5 algorithm, then, copy the memory state (also called context), and just update it with the password that you are trying. After that, if the password is wrong, you just drop that memory state (or free, as you wish to call this operation), restore the previous calculated state, and update it again with the next possibility.

Technically speaking, there is no much improvement in your solution.

OPSXCQ
  • 336
  • 1
  • 5
  • Q said 1000 not 102400 bytes and appended not prepended, so the partial precompuation doesn't work. OTOH MD5 of about8+1000 bytes on a modern CPU is about a microsecond -- and if an attacker has numerous targets (e.g. the database as you postulate) and GPUs or custom hardware they can do billions and likely trillions of trials per second. – dave_thompson_085 Sep 18 '16 at 13:06
1

Hashing using modern methods doesn't usually take long with any small object. Using something slower, like SHA1, would become much slower in relation to the size of the string, but is itself insecure. If your 'salt' (the 1kb string) is public, then it doesn't really help with dictionary attack. It will, however, stop a rainbow table attack using a standard hash algorithm unless the attacker compiles their own.

Perhaps if you stored a list of randomly salted hashes in conjunction with administrating user password requirements, it would be more secure.

Brian
  • 31
  • 3