[RFC] More secure hashing

[callumacrae]

...A random salt for every user is the generally accepted way, and the way recommended by every security expert. Why don't you think it is a good idea?...

Hello Callum,
you know every security expert's opinion? Great!

For me the salty thing is an alternative for increasing the hash algorhythm. I think it's easier to get backward compatibility with a higher hash algorhythm.

Based on my job's experience I always prefer simplyfied server side solutions.

Bye Martin

Do you know what salting is?

Code: Select all

$salt = random_string();
$password = hash($salt . $password);

insert_into_database(array(
    'username'    => $username,
    // ...
    'salt'        => $salt,
    'password'    => $password,
    // ...
);

Then when checking the password again, we grab the salt from the database and hash the password with it.


It doesn't prevent rainbow tabling entirely, but it does slow it down a lot.

[MartinTruckenbrodt]

Hello Callum,
yes.
It's fixing or securing the rainbow table thing.
But a board wide salt would do it with the same result.

Code: Select all

$salt = random_string();

would not been needed every time.
Also you would be much more flexible in using different hash algorhythms.

Another point is stolen data. What's the matter if only the content of the USERS_TABLE has been stolen?

Bye Martin

[callumacrae]

Hello Callum,
yes.
It's fixing or securing the rainbow table thing.
But a board wide salt would do it with the same result.

Code: Select all

$salt = random_string();

would not been needed every time.
Also you would be much more flexible in using different hash algorhythms.

Another point is stolen data. What's the matter if only the content of the USERS_TABLE has been stolen?

Bye Martin

A board wide salt would mean that it is possible to rainbow table every single user at the same time. A salt per user would mean that every users has to be rainbow tabled individually - which will take far longer, and is thus far more secure.

[MartinTruckenbrodt]

Hello Callum,
if rainbow tables would offer hashes for random strings then we would have really very large security problems!

Bye Martin

[callumacrae]

Hello Callum,
if rainbow tables would offer hashes for random strings then we would have really very large security problems!

Bye Martin

?

[MartinTruckenbrodt]

Hello Callum,
http://en.wikipedia.org/wiki/Rainbow_table

I think that you will not find a lot of hashes for random strings there.

Bye Martin

[bantu]

Salted passwords area a nice idea on the first look. But IMO it's not possible in real life to make the password salty enough. Users and/or administratos will be annoyed by it!

Salting does not affect users at all, it just changes the ways passwords are stored and verified.

So IMO this feature is not really a good security feature. I think a time limit te renew the password after a configured time period with password history would be a better and much more usefull security feature.

It's easier to forget a salted password.

I am sorry, but you just seem to have no idea how and why salting is used.

As I understand what you mean I think this salting thing has not the effiency which you want to get. This salting thing really would need to have random mechanism. At least a random passphrase for the board is needed created by the initial setup. A random passphrase for every user IMO is not a good way.

If you want to stay in this discussion and provide useful comments, please read up on Password Hashing and Salting.

BTW: What is state of the art for Olympus?

This question is already answered in this topic.

Anyway, I'm against this entire RFC, as there have been no problems so far and it would create backwards compatibility issues.

There are certainly ways to upgrade/change the password hashing scheme while keeping backwards compatibility. viewtopic.php?f=108&t=33231 discusses this partially.

...A random salt for every user is the generally accepted way, and the way recommended by every security expert. Why don't you think it is a good idea?...

Hello Callum,
you know every security expert's opinion? Great!

For me the salty thing is an alternative for increasing the hash algorhythm. I think it's easier to get backward compatibility with a higher hash algorhythm.

Based on my job's experience I always prefer simplyfied server side solutions.

Bye Martin

1. It is totally unclear what "increasing the hash algorithm" is and what a "higher hash algorithm" is.
2. Salting is required in order to make dictionary attacks and brute-force attacks slower.
3. Because of 2. it does not make any sense to use a per-board salt when you can also use a per-password salt.

Another point is stolen data. What's the matter if only the content of the USERS_TABLE has been stolen?

That is a major reason for why we hash and salt passwords before we store them. Again, please read up on password hashing.

A board wide salt would mean that it is possible to rainbow table every single user at the same time. A salt per user would mean that every users has to be rainbow tabled individually - which will take far longer, and is thus far more secure.

Exactly.

if rainbow tables would offer hashes for random strings then we would have really very large security problems!

I think that you will not find a lot of hashes for random strings there.

Such rainbow tables exist for some hash functions.

[MartinTruckenbrodt]

Hello bantu,
some things you have answered have been discussed and answered finally before.

For me still there is only one open question:
Why to salt every single user password insteat of using one salt for all user passwords?

Bye Martin

[bantu]

Why to salt every single user password insteat of using one salt for all user passwords?

A board wide salt would mean that it is possible to rainbow table every single user at the same time. A salt per user would mean that every users has to be rainbow tabled individually - which will take far longer, and is thus far more secure.

Exactly.

[MartinTruckenbrodt]

Hello bantu,
no, this doesn't increase security.
I think it's more secure to have one salt in CONFIG_TABLE and all passwords in USERS_TABLE insteat of saving all salts and all passwords together in one table USERS_TABLE.

Still I don't believe that there are rainbow tables with hashes for random strings. Please show me a source for this statement.

Bye Martin