Picking an Auth Library

[eluser]theshiftexchange[/eluser]
Fuzzy - it works like this:

Lets assume firstly that you did NOT hash passwords - but stored them as plain text.

If someone looks into your database (dont ask me how - just pretend they did), they would be able to see each user, and look at the next field and see the password in plain text.

Now, lets assume we are using MD5 and hash the password. If someone looks into your database, they would see the user, but still not know what the password was. Except, what they can do now, is get that "hash" password - and go to a site such as http://tools.benramsey.com/md5/ and see what the MD5 value represents; thus its effectively now storing it as plain text.

The reason this works is because MD5 is a known algorithm, people just create a massive database, and start by hasing (a, b, c,...,aa,ab,ac....,wfefwf,32r32r,5233) up to a certain number of chars - say 10 (a common maximum for passwords). All they need to do is compare their MD5 with the database, and see what their MD5 Hash represents.

EDIT: The reason 'salt' works well, is because the MD5 look-up tables are now basically useless. Even if the hacker knew what 'salt' you were using (using source code), they would have to effectively create a new hash md5 lookup table, with YOUR salt key, which takes forever (I think doing up to 8 characters takes 205 days to compute), thus saving your users from secruity risks

[eluser]Dam1an[/eluser]
Carrying on with what theshiftexchange said

As soon as you salt them, its not a simple lookup, even if you have the salt and hashed password infront of you. The reason for this, is because they would need to try every single hash of your salt to get the hashed password, so they would try a.$salt, b.$salt.... (they would also need to check $salt.a etc)

So they now don't have these existing lookup tables, as its not the standard MD5 algorithm, so they have to try each one themselves

That cleared things up a bit?

EDIT: shiftexchange just updated hist post to include what I just said lol

[eluser]theshiftexchange[/eluser]
[quote author="Dam1an" date="1242497569"]
EDIT: shiftexchange just updated hist post to include what I just said lol[/quote]

Sorry mate - I edited my post when I realised I forgot to say what salt actually was - lol

[eluser]TheFuzzy0ne[/eluser]
Everything up to the last paragraph I already know, but I still don't understand this thing with the salt, however. In most cases I've seen, the salt is simply concatenated with the password. So simply decrypting it with the key reveals the password with the salt at the end. That's the part I don't get. Do you know of any useful documents on the subject?

[eluser]TheFuzzy0ne[/eluser]
[quote author="Dam1an" date="1242497569"]That cleared things up a bit?[/quote]

Unfortunately not. I still don't understand the difference between the salt and the site key. I assume that this is not the same as the salt, and I guess that if someone figures that out, then it's game over? Or does the salt add yet more security? I'm still looking for docs that explain this, so I can save you people some time having to reply to a thread which I've now hijacked. :/

[eluser]theshiftexchange[/eluser]
The idea is that when the hacker reverses the MD5 with salt, he has some text, but doesnt know which part is the password, and which part is the salt.

Yes - he could 'socially' engineer and look at the text to determine if it's obviously - such as "mypassword23235" - but if you have a strong password (f32tjt32) - its harder. And the idea behind salt is to stop a brute force stealing of ALL user passwords. Its not foolproof, and thats why MD5+salt is falling out of fashion compared to other encryption options.

This obviously fails if he has the salt and the source code - but security is not a single key - its about layers and layers of protection. Salt is just another layer.

This may help: http://en.wikipedia.org/wiki/Salt_(cryptography)

[eluser]TheFuzzy0ne[/eluser]
I see. OK, now that makes more sense to me. It just adds another layer of security, but it's not totally unhackable. It just compliments the rest of the security measures you have in place.

Thanks for clearing that up for me.

Just out of interest, does anyone here actually use a password that doesn't contain words? I use two words, one of which isn't in any dictionary, and a combination of numbers. It's 26 characters long in all, but if they password was revealed in plain text with a salt added to it, it would be obvious.

But let's say for example, my password was bkldoiugaofesfp and it had a salt on the end of it, again just as random, that would only leave strlen($password . $salt) possibilities. which kind of brings us back to where we started. I guess at the end of the day, the smart thing to do might be to keep your password database on another server. Although this does make things a little more difficult for the developer, it does mean that there is a list of passwords, but no usernames to go with it, unless the would-be hacker had the contents of both databases.

[eluser]Dam1an[/eluser]
At the end of the day, anything is hackable given enough time and resources, the idea of this, is to make that time and effort needed so great, it no longer becomes worth it

Is as theshiftexchange said earlier, it takes 205 days to compute a rainbow lookup table, that would oly be vallid for one user... there aren't many cases that I can think of where you would thinks its worth it to throw that much at it... and in most cases, the password would have changed by then

[eluser]TheFuzzy0ne[/eluser]
That is unless you have a trojan on 10,000 PCs, and have them do the work for you.

[eluser]Dregond Rahl[/eluser]
but then that's brute force attack and that's what throttling is for ^^
*attacks you with delay and sends password reset info to your email account after 50 tries*