md5 or sha-1?

[haku]

Only if they knew that the string had been encrypted twice.

 

Not that I agree with him however, I think salts are entirely fine.

[Daniel0]

Only if they knew that the string had been encrypted twice.

 

Well, by the looks of drisate's signature, it seems like he is a developer of an open source project, so chances are he implemented the algorithm he posted above in that project. Finding out is just a matter of downloading the source.

[rockinaway]

SO I could simply use the 64 character long session key (stored for each user i.e. same)

 

So it would be md5($session_id . $password)?

[Daniel0]

No. Two reasons:

 

1) A session id is not secret. It's send to the user.

2) A session id changes. The salt must remain the same. Otherwise the password will not be usable in the next session.

[rockinaway]

No worries, I have my 64 character salt .. different for every user But stored secretly (in DB)

 

I have one question though.. how long should the hashed password be with md5?

 

I am trying the password test555 with my 64 character key and I just get e36110053df3 as my output, very short :S Is that right?

[Daniel0]

I have one question though.. how long should the hashed password be with md5?

 

I am trying the password test555 with my 64 character key and I just get e36110053df3 as my output, very short :S Is that right?

 

MD5 hashes are always alphanumeric strings with a length of 32 characters (^[a-z0-9]{32}$).

[rockinaway]

Yup my bad.. database structure wrong

[GingerRobot]

Storing the salt in your database?! The whole point of salting is that people can't brute force the password with the encyrpted password - if someone's able to get the encrypted password from your database, they're more than likely able to grab the salt too!

[rockinaway]

So, I shall store in files? That better?

[rockinaway]

I mean, shall I store the key in one of my core files so that I canm refer to it, it won't change this way too..

[Daniel0]

Yes. Or perhaps in some sort of configuration file.

[drewbee]

I would think storing the salt in the db once again defeats the purpose of the salt.

 

here is an example of a salt that is specific to a user (this is under the assumption the hacker doesn't have access to the source code files, preventing them from seeing the hash (or how it is generated for each user).

 

You could do something like this:

 

Lets say we have our accounts table

 

account_id, username, email

 

the salt could be an md5() of account id (always consistent and specific to that individual user

 

$salt = md5($row['account_Id']);

 

$userPassword = md5($salt . $_POST['password']);

 

Is this reasonable?

[GingerRobot]

Certainly reasonable - though all numeric (and potentially short) salts wouldn't be the best choice.

 

Also, if a hacker had access to your files, you'd be in a whole big heap of trouble.

[discomatt]

This is crazy. Storing salt in the DB is fine practise. What the hell are you trying to protect if you DB is compromised?

 

The biggest worry about hashed passwords is someone snooping hashes and brute forcing them (commonly and quickly through rainbow tables) into a plain text password.

 

A static salt can be compromised easily if an attacker grabs more than one hash.

 

A dynamic salt has to be brute forced on a per-user basis. Having an algorithm that scrambles the password and a dynamic salt together makes retrieving plain-text passwords near-impossible, even if a single user has been compromised.

 

Read more:

http://phpsec.org/articles/2005/password-hashing.html

[GingerRobot]

Do you not think that if someone has ended up with the hashed password (which is stored in your database) it is entirely likely they may also find the salt (if it is stored in the same database)?

[discomatt]

Also, in his example he uses a 9-character salt. I'd suggest sticking to multiples of 4 or even better 8... to avoid giving away an appended salt. Most hashing methods go in 64bit (8 character) intervals. A 128 bit hash with a 64 bit appended salt could possibly be a 192 bit hash as well, while a 128 bit hash with a 72 bit salt leave you with a 200bit string... not a common hash size. This leaves the cracker to assume in most cases a salted hash.

 

Security through obscurity will only take you so far, but adding a bit of guesswork on top of a good system never hurts

 

Do you not think that if someone has ended up with the hashed password (which is stored in your database) it is entirely likely they may also find the salt (if it is stored in the same database)?

 

The hash can be retrieved in many ways... If a user has a cookie to remember their credentials, its usually includes a hashed version of their password. This information is sent on page requests, and can be intercepted. If your database is compromised, maybe securing your hashed passwords isn't the big worry. What's the point of trying to protect data with a username/pass when the data can be grabbed another way?

 

Also, in the example I posted, unless the algorithm for appending the salt is known, it's next to impossible to separate the salt from the salted hash. The salt can also be completely random.

 

This is in no way a failsafe method.. it just makes the job harder for the cracker. If it's hard enough, they will hopefully just give up and move to an easier target.

 

I would think storing the salt in the db once again defeats the purpose of the salt.

 

here is an example of a salt that is specific to a user (this is under the assumption the hacker doesn't have access to the source code files, preventing them from seeing the hash (or how it is generated for each user).

 

You could do something like this:

 

Lets say we have our accounts table

 

account_id, username, email

 

the salt could be an md5() of account id (always consistent and specific to that individual user

 

$salt = md5($row['account_Id']);

 

$userPassword = md5($salt . $_POST['password']);

 

Is this reasonable?

 

Your salt is still being stored in the DB, only it is stored in plain text vs a hashed form

[discomatt]

To sum this up, the main reason to salt a hash is to make it much more difficult for an attacker to brute it into a plain-text password.

 

This is assuming a worst-case scenario in which a hashed password is stolen.

 

If the worst-case scenario is your database being compromised, you are screwed. With enough hashes, even a well salted hash can be reverse engineered into it's most basic form and brute forced, assuming the cracker is determined enough. Even thne, chances are they're just going to skip the user table, and move right on the the table holding the data those user/passwords were protecting.

[Daniel0]

Do you not think that if someone has ended up with the hashed password (which is stored in your database) it is entirely likely they may also find the salt (if it is stored in the same database)?

 

The hash can be retrieved in many ways... If a user has a cookie to remember their credentials, its usually includes a hashed version of their password. This information is sent on page requests, and can be intercepted. If your database is compromised, maybe securing your hashed passwords isn't the big worry. What's the point of trying to protect data with a username/pass when the data can be grabbed another way?

 

You're not supposed to store the hashed password (nor the username) in a cookie on the client side. You kind of told yourself why you shouldn't. Just use one cookie with a session id.

 

If the only place where the salt is ever stored in the database then the salting is rendered completely useless if the database is compromised. It's like hanging the key to a locked vault on the outside or having a post-it with your password on your monitor. By storing the salt another place the attacker will have to gain access to both the hash (i.e. get access to the database) AND get access to wherever your salt or salting algorithm is stored (e.g. the filesystem).

[discomatt]

Session ID's are temporary. Say you want the user to 'remember their info' for the next year. Storing a more permanent ID will be just as insecure, as an attacker with that ID will have access regardless.

 

The entire point of hashing and salting a password is so it can be stored without being easily used at a later point.

 

Your metaphor is incorrect though... because it's like hanging a key on the INSIDE of the vault. If you've lost your DB what else do you have to protect? Is the file system really that far behind?

 

It's rarely the password the attacker wants, it's what the password allows them to have.

[Daniel0]

Session ID's are temporary. Say you want the user to 'remember their info' for the next year. Storing a more permanent ID will be just as insecure, as an attacker with that ID will have access regardless.

Set a longer lifetime and regenerate the ID often.

 

Your metaphor is incorrect though... because it's like hanging a key on the INSIDE of the vault. If you've lost your DB what else do you have to protect? Is the file system really that far behind?

Let me give you an example. Someone once found a security hole in The Pirate Bay resulting in allowing them to get a database dump of the users table. The passwords were however hashed and salted so the information was useless. Had the salt been stored alongside the password then the salting would have been useless. Source: http://thepiratebay.org/blog/68

 

It's rarely the password the attacker wants, it's what the password allows them to have.

Again, not entirely true. Many users use the same password for multiple purposes. Say for instance the the attacker gets the user's password to resource A, but the user happens to have used the same password for resource B which means that if the attacker has the password then he'll have access to both of those resources. I can again provide you with a real-world example. Somebody once found a security hole in one of the PHP Freaks administrators' private websites which allowed him to get the hashed version of the admin's password. He was able to crack that password and the admin happened to use the same password here which enabled the hacker to elevate his privileges here using the admin credentials.

[discomatt]

I'm not going to argue that storing the salt in the filesystem isn't more secure... but I do think it's unnecessary. Just because your salt is right beside your password, it doesn't mean the rest of the world knows this. Are you entirely sure the salt isn't right there? TPB obviously wouldn't tell anyone.

 

Now the second example is the fault of the site owners. Before giving someone elevated privileges, make sure they aren't silly enough to use a common password, or expect your data gone. A auth system can only be as secure as it's key holders.

 

Here. I'll give you a string using a common (unknown) hashing algorithm and an appended salt of unknown length. The salt is easily extracted and isolated. Find the salt please

 

a1165166720e332e45d379c1a6865e40c6e733619fa395f745d7e61a141e3cbc438e6271fae7a60f21b4fdacd0ba0439221d6772d67ae0c58e9e8e3e8661a062

 

Kinda hard without even knowing the salt length, eh? Reversing this is theoretically impossible. Social engineering is far more logical.

[discomatt]

Here's teh script used to generate that.

 

<?php

$salt = hash('sha384', uniqid());
$pass = 'i love you';

$newpass = hash('haval128,5', $salt.$pass);

$hashed = substr($salt, 0, strlen($salt)/2) . $newpass . substr($salt, -strlen($salt)/2 );

echo $hashed;
echo '<br>';
echo $salt;
echo '<br>';
echo strlen($hashed) . ' chars';

?>

 

As you can see, very simple. Split the hash into 2, and append to the front and back. You could append the back to the front and vice versa, reverse it.. any combination of manipulation that would make it impossible to even guess what was done to the finished hash. Yet this is still extremely easy to isolate without having to grab a specific user salt out of another potentially slow database (the flatfile, for example).

 

Your method just makes no sense, especially if you consider having 5000 users. The only way to do this somewhat efficiently would be to have a hash and a salt table with 2 sql users... one able to access one, one able to access the other, neither table accessible by any other user. Then you're still literally doubling the work having to be done.

 

The hash wouldn't be the issue here.

[discomatt]

Sorry, for the triple post.. I hate not being able to go back and modify...

 

The resulting string is in identical format to a 512-bit hash. Makes things even harder to figure out.

 

And the above is a proof of concept, please don't use that exact code in production. All salting and hashing algo should be saved outside of the document root and included... just in case php doesn't parse. Losing the algo should be considered just as dangerous as losing the hashes themselves.

[Daniel0]

Then you'll still have a problem if you're an open source developer.

[discomatt]

You can use bitwise functions to help randomize your algorithm per application.

 

Say you randomly pick a random int between 1 and 255 (00000001 to 11111111) when you initially configure the script. Based on bits, you can selectively run certain algorithms and mix it up enough to make decoding the algorithm still extremely hard. You have 255 different possible combinations of mixing.. and testing each one becomes even less feasible if the configuration is done with different hashing algorithms as well.

 

Even with a set algorithm, a variable salt/hash bit length and custom offsets make it EXTREMELY difficult to reverse engineer.

 

But I agree with this to a point... it has the potential to become a weakness in the chain when it becomes open source.