note 90652 deleted from security.database.storage by danbrown

Note Submitter: neoatnhng at users dot sf dot net ---- Let me say this first: I'm not a cryptographer, if you need real high security hire one and let him check your code Having said this I want to comment on some of the techniques mentioned, because I think they're dangerous as they make the situation worse @centurion54 at hotmail dot com: Introducing that many collisions into your hash function doesn't make sense to me, it's completely against the idea of a hash, being that if you have the hash of two pieces of information you can tell with a high probability whether the information was the same without knowing what the actual information was. You're right when you're saying that even if an attacker could attack the hash function (be it cryptographically, via rainbow tables or by brute force) he couldn't know the original password (which is important if you use the same password in more than one place, which most people do) because there are too many possibilities. The point you're missing is, that he could use any of these possibilities to break into your site and given the high numbers of collisions he won't need much time. ----- @Ketos: What you're proposing is essentially using the username as salt for the hash, which is better than using no salt but it doesn't add much. This is for two reasons: 1. Usernames are usually not long enough, thus an attacker who computed a rainbow table for passwords up to 12 characters would have a good chance to just look up the produced hash in his table, the only restriction is that username and password together must not be more than 12 characters long (e.g. the username Ketos with a password up to 7 characters would be unsafe) 2. Usernames might be words that occur in dictionaries so if the attacker computes uses a combination of the dictionary attack and rainbow tables (i.e. using the random combinations for the first part of the hashed information and words contained in the dictionary for the second part) he can get a significant speed up in producing rainbow tables for longer password + username combinations or an extended character set for the password (due to the reduced search space) which leads us back to 1. ----- @Fairydave at the location of dodo.com.au: What you're proposing (the second part, obfuscating how the hash is computed) is basically security by obscurity which is not necessary and might be dangerous because of the following reasons: 1. The sense of the salt in a hash is to protect against attackers which use rainbow tables (basically large tables which contain the hash for every string up to x characters – well it's not that easy but that explanation should do it) by adding a custom string to the actual information (e.g. the password) and thus making the hashed information longer without having to remember a password of 100 characters. The point is that the only requirements for the salt are that it has to be custom (only few people use the same salt, ideally it would be unique) and it has to be long enough to stretch the length of the information to a size beyond the capacity of rainbow tables (I guess there are rainbow tables with at least up to 20 characters on the black market and some organisations might have even bigger ones). It's however NOT a requirement for the salt to be secret, you could just print it next to the log in box, it wouldn't do any harm. 2. As the salt doesn't have to be kept secret you don't have to introduce weird coding to confuse potential attackers this only confuses yourself too and therefore might lead to bugs that are much worse for security. The idea to use data that you store anyway as salt is a nice one, you should however check whether you've taken care of the things I noted for the posting of Ketos. ----- @roysimkes at hotmail dot com: "But if they can see that files, you are already dead in the water" If that's the case your "security concept" doesn't deserve it's name. You are right however that using a concept that tries to tackle the problem from many sides is probably the best.