• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
phpass HAVE BEEN CRACKED! What is the solution?

#31
[eluser]slowgary[/eluser]
I see. So basically you could name your salt field 'password_salt' and it doesn't really matter that it's apparent, because it will also be apparent to the 'hacker' that using the rainbow table method won't work - UNLESS, of course, they're only after 1 password because it something like sensitive financial data and getting 1 password means jackpot. I still vote for using an existing field as the salt because it still serves the same purpose except now the hacker doesn't know the salt unless they also have the code - in that case, the hacker would be YOU!

#32
[eluser]Dam1an[/eluser]
I like the idea of using an existing field, something like the email address, which is unique
If you want to fool someone, you could also put a salt field which has content, but serves no purpose, that'll fool them (until they get the source code as well, and see you're login function)

#33
[eluser]n0xie[/eluser]
It would be considered 'security by obscurity' but in this case, I think it's a pretty decent idea, since even if this 'secret' would be out in the open, it wouldn't change the fact that it's still a 'random' salt.

#34
[eluser]Dregond Rahl[/eluser]
I currently use sha256 with a salt of the config encryption key and the email address field. It seems to work quite well so far. The config key itself is random and 50 characters long. I think email address is a good field to use because it can contain characters like " . - @ _ " too.

Another thing i noticed is alot of people use "password" for the password field. I insted use Hash_1, Hash_2 and Hash_3 and such so then you can't find out if its the token for the auto login, or password, or the session key and such.

Another field you could add to the password string is the signed up timestamp.

#35
[eluser]bretticus[/eluser]
So if the hacker gets your database with your random salt (or even the decoy salt field and the real salt field) and gets your source code with yet another static salt, he or she can still create a rainbow table for each record. In other words, it really can't take too long to hash a dictionary against your static and random salt because he or she knows what order to do so, for one. If hashing took tremendous amounts of time, we wouldn't use it. So a weak password with all the salting in the world is still weak if the hacker has access to your system. Thus, I think a strong randomly-generated static salt string in your code is good enough for the situation that the hacker gets away with the database and not your code. However, I do see that a random salt would slow the hacker down significantly in the situation that the hacker got code and data. I guess it comes down to how long it takes to hash an entire dictionary of weak passwords.

Tell me if I'm wrong, but we're back to enforcing strong passwords now, right? Smile

#36
[eluser]Dregond Rahl[/eluser]
hahah yesh we are back to that XD. What do you guys think should be the minimum length of a password ?

#37
[eluser]bretticus[/eluser]
good question, there is the possibility of a short password being cracked by brute force alone (not against your login but if someone with malicious intent gets your data.) Not really sure, but I see a lot of password policies being 8 or more numbers and letters with at least one capital and one punctuation character ([email protected]#$%^&*())

I was thinking, surely, one of these dictionaries or rainbow tables exists for download somewhere. Why not get that and check against it. If it were a plain text dictionary, you could gen a rainbow table using your hashing salt. If you get a match, tell the user his or her password is too weak (that ought to drive them completely nuts.) Smile

#38
[eluser]rogierb[/eluser]
That is why I randomly generate password paswords on specific apps.
This way I can make sure it is always a certain length and has a minimum of special characters in it.

This wouldn't work for social networks and such, but since we have limited user(<10.000), they just have to do as I say;-)

So with a SHA512 pasword, random and static salt with strong(er) passwords, it is a bit harder to crack or make colorfull rainbows

#39
[eluser]Dregond Rahl[/eluser]
The problem with generating random passwords for the people I that they tend to fgt it, or write it down somewhere. -.-

#40
[eluser]dmorin[/eluser]
Quote:Thus, I think a strong randomly-generated static salt string in your code is good enough for the situation that the hacker gets away with the database and not your code. However, I do see that a random salt would slow the hacker down significantly in the situation that the hacker got code and data. I guess it comes down to how long it takes to hash an entire dictionary of weak passwords.

I think you're underestimating how effective per row salts really are. Generating rainbow tables takes a good amount of time but even more importantly they are large. I have 8GB rainbow tables that I consider of medium to small size. So say I need to generate rainbow tables for 100k users, that alone would take months if not years to do, and would be 781 Terabytes in size. How many crackers do you know with access to more than three quarters of a petabyte of storage! Compare that to generating a single rainbow table for all accounts and it's a huge difference.

I highly recommend this for authentication overviews: http://stackoverflow.com/questions/549/t...eta#477578

and this for people interested in login cookies: http://www.cse.msu.edu/~alexliu/publicat...cookie.pdf


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.