using account names as salt

Question

So I'm making a website for a game. Nothing that will get popular :P

Right now I'm thinking about password security, I'm gonna use salting but instead of adding a new column in account table I was thinking about using the account name as salt since it cant be changed, and is "unique". I mean 2 users cant have the same account name.

But I was thinking how safe it would be if lets say someone has the account name banana. I mean that word gotta be popular in these wordlist hackers use.

Lets say the account name is banana and the password is hello (hashed with sha1), that would be pretty easy to reverse am i right?

Answer 1

No, you should follow standard practice and generate a new unique salt per user, and just store it right along side the other fields in the database, it's not hard to do.

Answer 2

The hacker can lookup the sha digest in the rainbow table and find that it matches the input 'bananahello' (considering that 'bananahello' is something already in the vehiculated rainbow tables). He can see that the user name is 'banana', ergo the password is 'hello'.

I would hash something similar to HTTP Digest HA1 hash: sha1(username . realm . password). Now a rainbow table customized for your realm ('example.com') is pretty hard to come bye. A side benfit is that you can actually implement Digest authentication on your site, which is sooo much better than Basic and forms.

Answer 3

It would be preferable to not using a salt, but would not be as secure as a random salt.

Answer 4

At least computationally permute the username somehow known only to you to get the salt. While hashes are not easy to reverse, you want to protect yourself against brute-force attacks. If you use the un-permuted username as the salt, you have made it easier to break with a dictionary attack.

Answer 5

There's no risk. The usernames are public knowledge anyway. And the hash is never easy to reverse - that's the whole point of hash.

As for the dictionary attack, you protect against it by having a password complexity policy.

Edit: yeah, to prevent a rainbow attack just prepend the salt with a longish arbitrary string. SHA1("whooooohooomysiteisthebest_bananahello") is not likely to be in a rainbow table.

Answer 6

Salting just prevents pre-calculated attacks. It's possible to have rainbow tables with dictionary salts already calculated, and it still doesn't prevent traditional bruteforcing, which will stumble across Remus's example of "bananahello" example pretty quickly.

By using public usernames verbatim, you've removed the value of the salt, the only task would be to calculate a rainbow table for that known salt. So to answer your question, yes, your implementation would be easy (but maybe not quick) to reverse.