Welcome Guest, Not a member yet? Register   Sign In
Picking an Auth Library
#11

[eluser]phpserver[/eluser]
By my own comparison freakauth is well documented and is ready to go but you gotta be prepared to untangle a lot of unnecessary resident css/jquery styles.The other option is dx_auth(i recommend it).Simple and concise with a touch of class.No css styles and no jquery
(just the way you like it).The final option is tank auth.While it talks of being a really reworked version of dx auth,the only 'visible' change is on the way passwords are stored.Tank auth uses phppass while dx auth goes with md5,both of them being very cool and efficient too according to me.

The final option is one sad case of cl auth.No further work has been done to date.Kind of very cool though and borrows somewhat from freakauth.
#12

[eluser]Dregond Rahl[/eluser]
there is alot of argument over what should be used now days MD5 is now crackable, and SHA1 is taking a lead, but as we know bcrypt and PHPpass are becoming more significant. Not to mention bruteforce attacks. Its crazy a world.
#13

[eluser]Dam1an[/eluser]
[quote author="Dregond Rahl" date="1242492579"]there is alot of argument over what should be used now days MD5 is now crackable, and SHA1 is taking a lead, but as we know bcrypt and PHPpass are becoming more significant. Not to mention bruteforce attacks. Its crazy a world.[/quote]

The reason MD5 is considred to be so insecure, is that rainbow tables are easily available (a rainbow table has the MD% hashed value of pretty much every combination between 1 and X characters)
SHA1 being 40 bytes means more possible combinations, so its more effort to do it then MD5 but still doable.

I just hash using SHA1 and salt (and hash again)
#14

[eluser]Dregond Rahl[/eluser]
Some methods use the persons ip as the salt key =/ it would be no different then using a random salt key right?
#15

[eluser]Dam1an[/eluser]
Assuming you store the IP they used to sign up as the salt, otherwise they could have a differant one each time, which wouldn't work lol
#16

[eluser]Adam Griffiths[/eluser]
[quote author="Dam1an" date="1242492799"][quote author="Dregond Rahl" date="1242492579"]there is alot of argument over what should be used now days MD5 is now crackable, and SHA1 is taking a lead, but as we know bcrypt and PHPpass are becoming more significant. Not to mention bruteforce attacks. Its crazy a world.[/quote]

The reason MD5 is considred to be so insecure, is that rainbow tables are easily available (a rainbow table has the MD% hashed value of pretty much every combination between 1 and X characters)
SHA1 being 40 bytes means more possible combinations, so its more effort to do it then MD5 but still doable.

I just hash using SHA1 and salt (and hash again)[/quote]

You really shouldn't hash twice. It's more secure to hash a password with a salt, than to hash it again. This is because the second hash is from a hash of a set size, 32 with MD5, so it's more easily crackable. Whereas when you have a password in a salted hash it's much harder to get the cleartext because passwords can be any length and so can the salt so the hash is likely to be very different.
#17

[eluser]Dam1an[/eluser]
Both hashes use SHA1, so the second hash is on a 40 character hash plus the 32 character salt
Code:
$hashed_password = sha1(sha1($password).$salt);

I assumed that would be more secure as there's 2 levels of hashing
And I double anyone would have a password of 40+ characters
Although I might change that now
#18

[eluser]TheFuzzy0ne[/eluser]
I'm sure I missing something here, but I hear a lot of people going on about security, and how insecure MD5 hashes are. Of course, security should be paramount for any developer, and I understand that rainbow tables exist, but I don't understand how any would-be hacker would obtain that MD5 hash in the first place. Can someone fill me in here on what I'm missing?

Thanks.
#19

[eluser]Dam1an[/eluser]
Fuzzy, this is assuming they manage to get hold of a database dump
Its the same reason people stopped storing passwords in plain text Wink
#20

[eluser]TheFuzzy0ne[/eluser]
I think I need to look into this more. The only reason I didn't before, is because I don't "get it". So I guess it makes things a bit more secure in that respect, so long as they don't get hold of the app code? If that's the case, wouldn't that leave you a bit screwed when it comes to open source projects?

Oh wise Dam1an. Please could you point me in the direction of some docs that will explain this to me a bit better? I don't understand all this with salts. I know what a salt is, but I don't understand how it can be any more secure if the salt is stored within your database. Sorry for sounding thick here, but I clearly need to up my security.




Theme © iAndrew 2016 - Forum software by © MyBB