Double Hashing Passwords (Page 1 of 2)

well sha1 is used where avalible and if you password is a reasonable length it will take along time to bruteforce it

what is "random salt"?
where can I read about it?

as for converter for doublehashed passwords:
1. add boolean field "dblhashpass" to "users" table
2. in all places using md5 - check this field, and if true - use md5(md5()).
3. when registering new user or changing password - make it "true".

well. a sort of

Here's a decent article on password hashing.

surely md5(md5()) just takes twice as long to bruteforce?

Damn. I'm confused.
How will it helps anyway? If brutforce will be through login.php - there will be no difference how to hash passwords...
also he would be able to stole salt string
and find out that md5(md5()) is used...
no sense...

well, you need to limit db activity only to http server (by firewall). after that you won't be able to access db directly.
but hackers often use php scripts holes, to execute selects from dbase.
i wonder, is there any hole in punbb, to execute custom selection, or even update and other sql commands?

there were problems with someting like
[b ][b ][/b ] or [code ][code ][/code ]

or cascaded BBCodes..
or maybe variables entered in url string?
well, phpbb were hacked through url string (path and variables)

Double hashing take far more than two times the time to brute force, because instead of being able to do a dictionary based hack, you have to find a string of letters and numbers.  If the origional passoword was forums, it would be encrypted to 68daf8bdc8755fe8f4859024b3054fb8 the first time.  That could be broken in about 5 seconds using a dictionary brute force.  But if you run 68daf8bdc8755fe8f4859024b3054fb8 through md5 again, it gives you 471b357e0fdd976f770343b94a1e012c.  The effective time it would take to brute force that would be somewhat longer than your lifetime.  Random salt hashing would work well, to, but after you get one pass, wouldn't you have the salt for all the other passwords?

Well, randomsalt algorythm also will need a sort of migration module...
And boolean field in "users" table, shows that password is randomsalt hashed, and password hash check, using that field.
And all "change password" and "register new user" have to use randomsalt hashing.
Anyways you'll be unable to "rehash" all users passwords hash codes to new ones.
So, this task could be resolved only on clear dbase OR when password migration scheme will work.

I wonder, why the password maximum length is 16?? why not 32?
Also, is there any "restore forgotten password" possible? I think not. So, what about it?

Oh I see that, but it generates a new password, not actually restores them.
Related to the topic - there must be "forced" password change to every user, to migrate on new hash generation algorythm.

Well if you check the article Rickard pointed to you find these words that descripe the essence of the random salt

Dictionary attacks with pre-generated lists of hashes will be useless for the same reason - the attacker will now have to recalculate their entire dictionary for every individual account they're attempting to crack.

So even though they would know the random hash it doesn't matter, you've added an N to the calculation so instead of 1 dictionary for 100 users they would need 100 dictionaries(1 dict * 100 users) for the attack and that is assuming they have access to your DB and know your random salt string.

it will have a sense if this "unique_site_code" won't be stored in DB.
and $member_id in hash - will make membership unchangeble.
maybe you mean $user_id ?