Welcome Guest, Not a member yet? Register   Sign In
phpass HAVE BEEN CRACKED! What is the solution?
#21

[eluser]Dregond Rahl[/eluser]
don't we have to save the random salt in the database table so we can retrieve it for comparing ?

and if we use a method like

hash('sha256', encryptionkey.password.randomsalt);

would that be enough?
#22

[eluser]bretticus[/eluser]
[quote author="trs21219" date="1245217044"]
mine does both. it uses a random salt for each user combined with their password and on the other end is what i call 'pepper' which is exactly like the encryption key but a different string. this way if they steal your db they don't have the one that is in the code. which makes it impossible to access the passwords (without 500 super computers and about 10,000 years)[/quote]

So you store some random salt with the user record? Then you hash that with the user's real password, plus your "script-side" static string to make the password hash in the user record?

That would go a very long way to prevent a rainbow table from exploiting the password if the data were stolen, but I would think just hashing the real password + the "script-side" code with sha256 (or better) ought to be sufficient as a collision is the only thing the hacker needs. To gain access to your website, if he or she can produce a password, which combined with your static salt, will result in the desired hash (which is why md5 is not really safe) then that is good enough without ever knowing the real password. If you used a strong hashing algorithm (you can upgrade php hashing algorithms via the suhosin extension) and a moderately strong "script-side" randomly-generated static string, you'd have my approval easy. Smile

EDIT: Apparently "hash" has the same upgraded hash algorithms if you have PHP 5 >= 5.1.2 (as demonstrated in above post.)
#23

[eluser]slowgary[/eluser]
What's the benefit of a random salt when it has to be stored in the database table? If someone gains access to the table, they have the salt. Maybe if you just used another field instead of having a salt field, the hacker would not know that the field had anything to do with the salt (user's email address, for instance).

Also, does it really matter what you use to hash passwords with? Unless they have direct access to your database, a brute force attack would be done using actual dictionary words, not hashed words. Your site should not allow someone to fail more than a few login attempts before they're locked out for a short time and you log their info.
#24

[eluser]Dregond Rahl[/eluser]
How do you even test for bruteforce attacks? is there a site or some script to run to try your login system and see if it can survive a bruteforce attack ?
#25

[eluser]Thorpe Obazee[/eluser]
Dregond, see lmgtfy andpost #11
#26

[eluser]Dregond Rahl[/eluser]
[quote author="bargainph" date="1245233983"]Dregond, see lmgtfy andpost #11[/quote]

hahaha, iv googled it before and I read the post too XD. but I mean, even if we use fancy hashing methods or lock out methods, the problem is that if you do get attacked it still means a lot of database queries which will slow down the system, and if you lock out users if its a heavy attack it could cause a lot of locked accounts very often.

So thats what I ment by if there was away to test the system implemented, for example the method where a cookie is set and if it reaches 5 attempts it will lock the user with the cookie from being able to see the login page for 5 mins. If a brute force attack was done would it even store cookies? and if it doesn't, would saving the attempts in a DB more effective? I don't think so tho because that would just lock out the user, not the hacker in specific or bot.
#27

[eluser]bretticus[/eluser]
An attacker can easily not send cookies back, so cookies are probably useless in this scenario. I would also assume that an attacker could spoof ip addresses, yet, how would he know if successful if the response never reaches him? So, you might store attempts in the database by ip. However, if the attacker has a bot net, that is impossible to defend. However, if the attacker has that capability, he'll just shut you down anyhow. If only http were a stateful protocol. Smile

If you do go for storing ips, to avoid the database lookup each time, use apc instead. Once that ip gets in your cache, just do a nice little die() or exit() on a match (just make sure it's not a proxy ip for aol or something!) The beauty with caching is that you can set a TTL and the cache will expire all by itself.

Keep in mind that there are ways of detecting bots too. Although CAPTCHA on login could be very annoying. Perhaps, we don't have to be quite so locked down.
#28

[eluser]n0xie[/eluser]
[quote author="slowgary" date="1245228774"]What's the benefit of a random salt when it has to be stored in the database table? If someone gains access to the table, they have the salt. Maybe if you just used another field instead of having a salt field, the hacker would not know that the field had anything to do with the salt (user's email address, for instance).[/quote]
If you read my link you'd know Wink

It's really simple actually. A rainbow table is a pre generated dictionary of hashes. So let's assume you take all the words in the English language and you take a few simple extra's (adding a 1 to the end, replacing the 'e' for a 3, the 'a' for a 4 etc etc.) and you hash all these words and save these along with the 'password'. You end up with a huge dataset of hashes. Now you compare those hashes to the 'stolen/ hacked' database. If a match is found, you just cracked a password. The very simple method of protecting against this is making sure the word is not in that dictionary. So you add a random piece of garbage data just so the 'word' isn't in the dictionary. The hash will come out different and voilĂ , your password can't be cracked.

The problem rainbow tables have is that it's impossible to store all the hashes, so they have only a small portion (even millions of key/value pares are considered small) of the most commonly used passwords. This is both a time and a speed limitation (which is basically all security is).

Now if you have a 'fixed' salt, and the salt gets discovered, an attacker could just simply generate a rainbow table, based on your salt, thus rendering the salt obsolete. Using a random salt, an attacker has to regenerate the entire rainbow table for EACH row in your database for that particular salt. So even though he has the salt, it would take him years (if not longer) to decipher even a fraction of all the passwords.

Quote:Also, does it really matter what you use to hash passwords with? Unless they have direct access to your database, a brute force attack would be done using actual dictionary words, not hashed words. Your site should not allow someone to fail more than a few login attempts before they're locked out for a short time and you log their info.
Preventing against a brute force dictionary attack is common sense, not security Wink. To prevent people from shooting their own foot, the most used practice is to make the retry time exponentially long. So the first few tries are free, after that the retry time goes up for t = e^x.

Also never underestimate 'losing' a database. Sure most people are very careful when it comes to the live site. But how about backups? How about human error? How about common theft? Physical access to the machine? The list goes on and on.
#29

[eluser]slowgary[/eluser]
I never considered losing a db backup, makes sense either way to secure it the best way possible. What doesn't make sense to me though is storing your random salt in the same database. If the database is stolen, they have the salt. I though that was the purpose of having salt, it requires the source code to recreate the hash, so now a hacker needs your database and source code. It would make sense though if you used an existing field as your hash, like the user's zip code or email address. Then there's no obvious 'salt' field in your database table.
#30

[eluser]Dam1an[/eluser]
@Gary, yes thay may have the salt and the hashed password as they're in the same table, but the whole point is, it would take them so long (like really, really, really long) to create a rainbow table for each row to potentially get the password

Also, the fact it takes them howevery many tens of years to crack a password, you can have done something to prevent it by then lol




Theme © iAndrew 2016 - Forum software by © MyBB