Where does salts "come from"?
Peter Lind
As I understand it - salting is, among other things, about enabling two
users who happen to have the same password - to have different hashes
stored on the server.
For instance:
Bob's password HELLO + salt might be: 8%EFWDW"#&/gt/6e
while
Joe's password HELLO + salt might be: 6#Jfd#34HGjy%e34
(The salt being different for each user.)
So far so good, but where is that salt stored? I assume the login
procedure goes like this:
BOB enters login details -> System hashes the input password + salt, and
compares it to the stored hash for Bob.
But where does the system retrieve the specific salt for Bob's account
from? And where and how does it create it in the first place?
Hope someone can shed some light on this =)
Peter
Bruce Stephens
[...]
> Bob's password HELLO + salt might be: 8%EFWDW"#&/gt/6e
>
> while
>
> Joe's password HELLO + salt might be: 6#Jfd#34HGjy%e34
>
> (The salt being different for each user.)
>
> So far so good, but where is that salt stored? I assume the login
> procedure goes like this:
<http://en.wikipedia.org/wiki/Salt_(cryptography)> seems a reasonable
description.
[...]
Peter Lind
being random bits. How are the random bits that are used to create the
salt, kept track of - so that the same bits gets hashed together with
the password at the user's next login attempt?
Tom Anderson
> Bruce Stephens wrote:
>> Peter Lind <da...@vader.org> writes:
>>
>> [...]
>>
>>> Bob's password HELLO + salt might be: 8%EFWDW"#&/gt/6e
>>>
>>> while
>>>
>>> Joe's password HELLO + salt might be: 6#Jfd#34HGjy%e34
>>>
>>> (The salt being different for each user.)
>>>
>>> So far so good, but where is that salt stored? I assume the login
>>> procedure goes like this:
>>
>> <http://en.wikipedia.org/wiki/Salt_(cryptography)> seems a reasonable
>> description.
>
> But it doesn't really explain on what basis they are created, other than
> being random bits. How are the random bits that are used to create the
> salt, kept track of - so that the same bits gets hashed together with
> the password at the user's next login attempt?
They're stored along with the password hash.
tom
--
Heinlein has done more to harm SF than has any other writer, I think. --
PKD
Kristian Gj�steen
>But it doesn't really explain on what basis they are created, other than
>being random bits. How are the random bits that are used to create the
>salt, kept track of - so that the same bits gets hashed together with
>the password at the user's next login attempt?
Stored with the password hash.
--
Kristian Gj�steen
Peter Lind
So Bob's stored data might be: $3"&6Qi?Rt/&"!5T3&RRg#)FK#{=E
...............................<-SALT-><--HASH OF SALT+PW-->
Thats ingenious! =)
Bruce Stephens
Or it's stored separately (as wikipedia suggests) in the hope that an
attacker will just get the password hashes and will miss the salt.
Peter Lind
Ah yeah, of course that would be more secure.
Bruce Stephens
> Bruce Stephens wrote:
[...]
>> Or it's stored separately (as wikipedia suggests) in the hope that an
>> attacker will just get the password hashes and will miss the salt.
>
> Ah yeah, of course that would be more secure.
Presuming no screwups it's clearly no less secure (it's a little more
complex, so the opportunity for screwing something up is a little
more). By the usual conventions (that an attacker knows how the
system works) it's no more secure.
Phil Carmody
But for *even more* security, store the first halves of the password
hash separately from the second halves, in the hope that the attacker
will only get half of the password hashes, and miss the other half.
However, I patented that, so you'll need to pay me a few cents, but
it's worth it for the extra security you hope it provides.
Phil
--
Marijuana is indeed a dangerous drug.
It causes governments to wage war against their own people.
-- Dave Seaman (sci.math, 19 Mar 2009)
Kristian Gj�steen
>Or it's stored separately (as wikipedia suggests) in the hope that an
>attacker will just get the password hashes and will miss the salt.
Ah yes, the security-by-stupid-attacker-assumption.
The Wikipedia page isn't very good, the example is nonsense.
--
Kristian Gj�steen
Mateusz Stankiewicz
> But for *even more* security, store the first halves of the password
> hash separately from the second halves, in the hope that the attacker
> will only get half of the password hashes, and miss the other half.
In my opinion salt doesn't makes your password more secure. It only
makes the hash different from users with the same password. So when
attacker gets your password file he has to crack all the passwords, even
when they're the same. The conclusion is that salt doesn't need to be
secret or in someplace else than the pass.
Skybuck Flying
Maybe that counts ?!
I also wonder if "salty balls" could function as a biometric login
procedure.
Do people have different kind of salts ? ;)
Bye,
Skybuck =D
"Peter Lind" <da...@vader.org> wrote in message
news:HuCdnS7DJN7As9jX...@giganews.com...
Paulo Marques
[...]
>>> Or it's stored separately (as wikipedia suggests) in the hope that an
>>> attacker will just get the password hashes and will miss the salt.
>> Ah yeah, of course that would be more secure.
>
> But for *even more* security, store the first halves of the password
> hash separately from the second halves, in the hope that the attacker
> will only get half of the password hashes, and miss the other half.
>
> However, I patented that, so you'll need to pay me a few cents, but
> it's worth it for the extra security you hope it provides.
That patent is very closely related to my patent of storing each forth
of the password's hash in each one of four different servers. At least
my method is twice as secure.
Of course, for unbreakable security you will need to split the hash
between at least 8 servers in 8 different continents.
--
Paulo Marques - www.grupopie.com
"To know recursion, you must first know recursion."