note 101834 deleted from function.hash by danbrown

Note Submitter: ped at 7gods dot org ---- to kevin at bionichippo dot com: "This way, even if someone can produce a rainbow table for your algorithm, and has the salt to do it with, they will never know where in the hash parameter the second salt was placed, because they don't know the length of the actual password." This is misunderstanding how rainbow tables work. If you posses the password encoding (hashing) algorithm including the salts, the rainbow tables can be produced. Your floating centerSalt makes no difference in this production, and there's no need to know original password length, because rainbow tables are used to search for hash-colliding string to be used instead of original password, they are not used to recover original password string. And the colliding string is (by the design of R.tables) another hash, so its length is well known to attacker and it knows exactly where to put your 'centerSalt' during tables generation. That $username part will hurt attacker much much more (and it's good to extent it by a static nontrivial text, so even the 'centerSalt' in your example does add to protection a bit, but not because of it's dynamic position). Still as far as I know (I'm not expert in this field), to generate rainbow tables is far from cheap operation. Basically to have full tables you would need at least 2^bits_of_hash hashing operations, and that's when the hashes can be chained trough and don't produce any closed cycles, so it's trivial to split them into table and to be sure you have all of them covered.