# Salts

## A Ciphers By Ritter Page

A "salt" is a value used to modify a hash of a password.

Originally, user passwords were verified by direct comparison to a file containing the correct passwords. Simply exposing that file thus exposed some or all of the passwords on the system.

To avoid that, passwords were verified by computing a hash value from the password and verifying that to the correct hash value stored in the password file. The actual passwords, never being stored on the system, were thus thought to be protected.

Unfortunately, obtaining the password file revealed hash values which then could be compared to hash values for popular passwords, thus revealing the password itself.

To avoid this, a salt value is hashed along with password, thus changing the hash value and making a known-hash attack difficult.

### Contents

• 2000-08-21 John Myre: "I'm wondering what (cryptographic) properties "salt" has to have."
• 2000-08-21 tomstd@my-deja.com: "Salts only need to be unique."
• 2000-08-21 John Myre: " . . . if the username could be taken as the salt, then we don't have to store a salt, we don't have to "generate" it, we don't have to communicate it."
• 2000-08-21 Bill Unruh: "Its only purpose is to make the same password (eg used by different users) store differently in the public password file."
• 2000-08-21 John Myre: "I can certainly imagine systems in which salts are other than random numbers are handy."
• 2000-08-21 Bill Unruh: "The salt is public knowledge. It cannot add any cryptographic strength to any one password."
• 2000-08-21 David A. Wagner: ". . . the salt makes dictionary attacks more costly . . . ." ". . . many passwords have very low entropy, so low that no amount of salting can save you."
• 2000-08-22 elleron@crosswinds.net: "The current practice is to move the hashed password to a non-public file, and throw the salt away after calculating the hash."
• 2000-08-22 John Myre: "It appeared to me that if the user could know the salt without asking the server, then you could get by with one less message."
• 2000-08-22 David A. Wagner: "The fundamental problem is that today's password systems were built under a threat model that is no longer relevant."
• 2000-08-23 John Myre: "Are user-memorized secrets usually hopeless, regardless of the cryptography?"
• 2000-08-23 David A. Wagner: "I only wanted to complain about the practice of using plain passwords without any appropriate accompanying crypto."
• 2000-08-22 John Savard: "Basically, it is meant to hinder precomputation."
• 2000-08-24 David Hopwood: "An attacker can start a dictionary attack at the time when he/she learns the salt. Therefore, the salt should be unpredictable, so that the attack can only be started when the password file is compromised."

Subject: What is required of "salt"?
Date: Mon, 21 Aug 2000 11:44:00 -0600
From: John Myre <jmyre@sandia.gov>
Message-ID: <39A16A60.2FB4F96C@sandia.gov>
Newsgroups: sci.crypt
Lines: 20

I'm wondering what (cryptographic) properties "salt" has to have.

Let me begin by restricting the question to salt as used in
password files.  This might be the original Unix-style file,
or it might be some verifier-based setup.

The main purpose of salt, as I understand it, is to ensure
that entries for the same password aren't the same (or rather,
that the adversary cannot tell that the entries are for the

Usually I see the assumption that the salt is "random".  I
don't see, however, why this is so.  For example, what would
be wrong with using a simple counter to generate salt values?
Or, what if the salt were the concatenation of the user name
and the server name (or address)?  Is there a reason to
change the salt when we change the password?

JM

Subject: Re: What is required of "salt"?
Date: Mon, 21 Aug 2000 18:53:20 GMT
From: tomstd@my-deja.com
Message-ID: <8nrtqn$1ne$1@nnrp1.deja.com>
References: <39A16A60.2FB4F96C@sandia.gov>
Newsgroups: sci.crypt
Lines: 44

In article <39A16A60.2FB4F96C@sandia.gov>,
John Myre <jmyre@sandia.gov> wrote:
>
> I'm wondering what (cryptographic) properties "salt" has to have.
>
> Let me begin by restricting the question to salt as used in
> password files.  This might be the original Unix-style file,
> or it might be some verifier-based setup.
>
> The main purpose of salt, as I understand it, is to ensure
> that entries for the same password aren't the same (or rather,
> that the adversary cannot tell that the entries are for the
> same password).  Is there more?
>
> Usually I see the assumption that the salt is "random".  I
> don't see, however, why this is so.  For example, what would
> be wrong with using a simple counter to generate salt values?
> Or, what if the salt were the concatenation of the user name
> and the server name (or address)?  Is there a reason to
> change the salt when we change the password?

Salts only need to be unique.  If you can afford that it's ok.
Otherwise just pick a salt at random.

The purpose as you may already know of a salt is to hinder hash-
as "aaa" can hash to many different valid outputs.  The larger the salt
the better.

It also means that people who use the same password will not have the
same passwd hash unless the salt was the same too.

Consider a system with no salts used, all users that pick the
password "aaa" will have the same hash, not only that but all users on
another system will have the same hash.  Now if you used a 12 bit salt
for example you have to test "aaa" 4096 times (different hashes).

So make the salts random that's all.

Tom

Sent via Deja.com http://www.deja.com/

Subject: Re: What is required of "salt"?
Date: Mon, 21 Aug 2000 13:58:37 -0600
From: John Myre <jmyre@sandia.gov>
Message-ID: <39A189ED.650C5A0F@sandia.gov>
References: <8nrtqn$1ne$1@nnrp1.deja.com>
Newsgroups: sci.crypt
Lines: 31

tomstd@my-deja.com wrote:
>
> In article <39A16A60.2FB4F96C@sandia.gov>,
>   John Myre <jmyre@sandia.gov> wrote:
> >
> > I'm wondering what (cryptographic) properties "salt" has to have.
> >
<snip>
>
> Salts only need to be unique.  If you can afford that it's ok.
> Otherwise just pick a salt at random.
<snip>
>
> It also means that people who use the same password will not have the
> same passwd hash unless the salt was the same too.
<snip>

I think you are agreeing with me on the actual requirements of
a salt: (mostly) different for each login, to hide collisions

> So make the salts random that's all.

That's one way.  What I'm trying to figure out is if that has
to be the only way.  Different situations would make other
alternatives attractive.  For instance, if the username could
be taken as the salt, then we don't have to store a salt, we
don't have to "generate" it, we don't have to communicate it.
So - is there a reason why that technique is insecure?

JM

Subject: Re: What is required of "salt"?
Date: 21 Aug 2000 19:21:57 GMT
From: unruh@physics.ubc.ca (Bill Unruh)
Message-ID: <8nrvgl$k18$1@nntp.itservices.ubc.ca>
References: <39A16A60.2FB4F96C@sandia.gov>
Newsgroups: sci.crypt
Lines: 46

In <39A16A60.2FB4F96C@sandia.gov> John Myre <jmyre@sandia.gov> writes:

]I'm wondering what (cryptographic) properties "salt" has to have.

None. Its only purpose is to make the same password (eg used by
different users) store differently in the public password file. This way
the attacker will not know when two users have the same password just by
looking at the hashed version. Probably a better scheme would have been
to use the username ( as they are almost guarenteed to be unique) rather
than a one of 4096 random numbers. However, the crypt authors were after
shortness, and since machines could typically have more than 4096 users,
they figured choosing them randomly was a good procedure. For the MD5
hash you could just as well use the user's name (except for the problem
that this would show that the same user on different systems uses the
same passwords on those different system.)

So, the requirements are : a) unique to each user. b) Unique to each
system. c) short. Of course all three cannot be done. Unix crypt opted
for short, (2 alphnumeric encoded characters) and thus figured random
number was best.

You could equally use
however having 3

]Let me begin by restricting the question to salt as used in
]password files.  This might be the original Unix-style file,
]or it might be some verifier-based setup.

]The main purpose of salt, as I understand it, is to ensure
]that entries for the same password aren't the same (or rather,
]that the adversary cannot tell that the entries are for the

]Usually I see the assumption that the salt is "random".  I
]don't see, however, why this is so.  For example, what would
]be wrong with using a simple counter to generate salt values?
]Or, what if the salt were the concatenation of the user name
]and the server name (or address)?  Is there a reason to
]change the salt when we change the password?

The only problem with using the system name is that when you change the
and even root cannot log on.

Subject: Re: What is required of "salt"?
Date: Mon, 21 Aug 2000 14:37:50 -0600
From: John Myre <jmyre@sandia.gov>
Message-ID: <39A1931E.7691048B@sandia.gov>
References: <8nrvgl$k18$1@nntp.itservices.ubc.ca>
Newsgroups: sci.crypt
Lines: 80

Bill Unruh wrote:
>
> In <39A16A60.2FB4F96C@sandia.gov> John Myre <jmyre@sandia.gov> writes:
>
> ]I'm wondering what (cryptographic) properties "salt" has to have.
>
> None.

Ah, then I'll just use zero. :)

> Its only purpose is to make the same password (eg used by
> different users) store differently in the public password file.

That's the only requirement I've ever seen, as well.

> Probably a better scheme would have been
> to use the username ( as they are almost guarenteed to be unique) rather
> than a one of 4096 random numbers. However, the crypt authors were after
> shortness, and since machines could typically have more than 4096 users,
> they figured choosing them randomly was a good procedure.

Shortness where?  If you could take the username as the salt, then
salting would cost zero in storage, since the username has to be
there anyway.  As far as historical design choices go, I'd bet that
the variable length of the username was their (perceived) problem.

> For the MD5
> hash you could just as well use the user's name (except for the problem
> that this would show that the same user on different systems uses the
> same passwords on those different system.)

In the Unix systems I've seen, the problem is usually there anyway.
The password file (with salts) is often copied to the next system,
rather than creating new logins.  Ok, so that's not good - but I'm
not sure salt is where to stop that.  That is, if you actually do
use the same password on multiple systems, then you are as vulnerable
as the least secure system, even without the attacker knowing it.

In a practical sense, it can be *better* to use the same password
everywhere, because you can pick a good one (and remember it).
Or it can be worse, because now you think passwords aren't important.

It does seem intuitively obvious that we want the attacker to know
as little as possible.  It would presumably be better not to reveal
whether or not passwords were the same on different systems for the
same person.  However, I'm not really convinced of this, because
I'm not sure what *advantage* the attacker gains.

> So, the requirements are : a) unique to each user.

Ok.

> b) Unique to each system.

Arguably.

> c) short.

Why?  That is, does that requirement have any cryptographic
purpose, or are you referring to practical constraints?

<snip>
> The only problem with using the system name is that when you change the
> and even root cannot log on.

Hm. Good point.  I've seen systems in which breaking logins when
you change the ip address would be a good thing, but not usually.
"Hardly ever," in fact.

In a practical system, we could probably finesse this somehow; if
it were given that using systemname:username for salt is a good
idea otherwise.

I can certainly imagine systems in which salts are other than
random numbers are handy.  Different systems, different techniques.
At this point I'm still seeing if anybody can come up with any
*cryptographic* requirements, other than uniqueness.

JM

Subject: Re: What is required of "salt"?
Date: 21 Aug 2000 21:29:01 GMT
From: unruh@physics.ubc.ca (Bill Unruh)
Message-ID: <8ns6ut$org$1@nntp.itservices.ubc.ca>
References: <39A1931E.7691048B@sandia.gov>
Newsgroups: sci.crypt
Lines: 49

In <39A1931E.7691048B@sandia.gov> John Myre <jmyre@sandia.gov> writes:

]Bill Unruh wrote:
]>
]> In <39A16A60.2FB4F96C@sandia.gov> John Myre <jmyre@sandia.gov> writes:
]>
]> ]I'm wondering what (cryptographic) properties "salt" has to have.
]>
]> None.

]Ah, then I'll just use zero. :)

Sure. Cryptographically this is as good as anything else.
The salt is public knowledge. It cannot add any cryptographic strength

]> Its only purpose is to make the same password (eg used by
]> different users) store differently in the public password file.

]> Probably a better scheme would have been
]> to use the username ( as they are almost guarenteed to be unique) rather
]> than a one of 4096 random numbers. However, the crypt authors were after
]> shortness, and since machines could typically have more than 4096 users,
]> they figured choosing them randomly was a good procedure.

]Shortness where?  If you could take the username as the salt, then
In the storage. REmember unix crypt was developed 30 years ago. Your
pocket calculator that you bought for $10 has far more power and storage than those machines had. They wanted to also hide the fact that the same user uses the same password on different systems (especially on ones administered by entirely different people) ]dsalting would cost zero in storage, since the username has to be But expensive in the algorithm as you would have to figure out how to use the 8 characters in teh username to perturb the crypt procedure. ]there anyway. As far as historical design choices go, I'd bet that ]the variable length of the username was their (perceived) problem. ]In a practical system, we could probably finesse this somehow; if ]it were given that using systemname:username for salt is a good ]idea otherwise. You could also use some system wide salt to do the same thing. Ie, the file /etc/salt contains a "unique" system identifier. Subject: Re: What is required of "salt"? Date: 21 Aug 2000 16:01:34 -0700 From: daw@blowfish.isaac.cs.berkeley.edu (David A. Wagner) Message-ID: <8nsccf$l80$1@blowfish.isaac.cs.berkeley.edu> References: <39A16A60.2FB4F96C@sandia.gov> Newsgroups: sci.crypt Lines: 35 In article <39A16A60.2FB4F96C@sandia.gov>, John Myre <jmyre@sandia.gov> wrote: > I'm wondering what (cryptographic) properties "salt" has to have. If I recall correctly, there is an excellent discussion in R. Morris, K. Thompson, Password security: a case history,'' {\em Communications of the ACM}, vol. 22, no. 11, Nov. 1979. A simplified answer is that the salt makes dictionary attacks more costly: it prevents you from re-using off-the-shelf DES hardware, and it forces you to try each dictionary word separately for each user, rather than amortizing the cost of a dictionary attacks across all users. > Usually I see the assumption that the salt is "random". I > don't see, however, why this is so. For example, what would > be wrong with using a simple counter to generate salt values? > Or, what if the salt were the concatenation of the user name > and the server name (or address)? Is there a reason to > change the salt when we change the password? Using just the username would be bad (someone could build a password -> encrypted-password codebook for specially targeted users, e.g., "root"), but username + fully-qualified server name seems ok as far as I can see. Counter is probably ok as long as you avoid correlations between servers (e.g., if all servers started at counter zero, that'd be bad). However, in general I think the Unix model of storing a hashed password in a publicly-readable location is a really bad idea these days. Experience is that many passwords have very low entropy, so low that no amount of salting can save you. Passwords are basically an obsolete technology, unsafe at any speed. I'd recommend that you consider the alternatives to passwords, and the risks of passwords, very carefully before deploying any new systems that use passwords for authentication. Subject: Re: What is required of "salt"? Date: Tue, 22 Aug 2000 00:13:37 GMT From: elleron@crosswinds.net Message-ID: <RAjo5.38953$_s1.486215@typhoon.ne.mediaone.net>
References: <8nsccf$l80$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 48

David A. Wagner <daw@blowfish.isaac.cs.berkeley.edu> wrote:
>> Usually I see the assumption that the salt is "random".  I
>> don't see, however, why this is so.  For example, what would
>> be wrong with using a simple counter to generate salt values?
>> Or, what if the salt were the concatenation of the user name
>> and the server name (or address)?  Is there a reason to
>> change the salt when we change the password?

> Using just the username would be bad (someone could build a
> users, e.g., "root"), but username + fully-qualified server name
> seems ok as far as I can see.  Counter is probably ok as long
> as you avoid correlations between servers (e.g., if all servers
> started at counter zero, that'd be bad).

To be pedantic, the salt is not truly random either, whch noone has
pointed out. It's normally obtained from the time of day, so there's
some bias towards whatever time the administrator normally creates
accounts at.

> However, in general I think the Unix model of storing a hashed
> these days.  Experience is that many passwords have very low
> entropy, so low that no amount of salting can save you.

The current practice is to move the hashed password to a non-public
file, and throw the salt away after calculating the hash. If you
absolutely need to have them, that's probably they way to go.

As to discarding the salt, remember you can still verify the has by
trying every possible salt value. (For a worse case of 4096 tries for
crypt(3), for example).

> Passwords are basically an obsolete technology, unsafe at any
> speed.  I'd recommend that you consider the alternatives to
> deploying any new systems that use passwords for authentication.

Unfortunatly, they're a neccessary evil at this point in time. Even
systems that use a stronger form of authentication often protect that

I would, however, avoid crypt(3) like the bubonic plague. One of the
MD5 style hashes (perhaps even modified to use SHA) is even better,
and doesn't limit you to eight character words.

--
Matt Gauthier <elleron@crosswinds.net>

Subject: Re: What is required of "salt"?
Date: Tue, 22 Aug 2000 10:06:27 -0600
From: John Myre <jmyre@sandia.gov>
Message-ID: <39A2A503.2BCBABE5@sandia.gov>
References: <8nsccf$l80$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 61

"David A. Wagner" wrote:
>
> In article <39A16A60.2FB4F96C@sandia.gov>, John Myre  <jmyre@sandia.gov> wrote:
> > I'm wondering what (cryptographic) properties "salt" has to have.
>
> If I recall correctly, there is an excellent discussion in
>   R. Morris, K. Thompson, Password security: a case history,''
>   {\em Communications of the ACM}, vol. 22, no. 11, Nov. 1979.

Thank you!

> A simplified answer is that the salt makes dictionary attacks
> more costly: it prevents you from re-using off-the-shelf DES
> hardware, and it forces you to try each dictionary word separately
> for each user, rather than amortizing the cost of a dictionary
> attacks across all users.

Certainly that's the only constraint I've ever seen.

<snip>
> Using just the username would be bad (someone could build a
> users, e.g., "root"),

Good point.

> but username + fully-qualified server name
> seems ok as far as I can see.

A practical caveat was pointed out by Bill Unruh: watch out for
changes.  You wouldn't want to accidentally lock out everybody
when you changed your network around.

<snip>
> Passwords are basically an obsolete technology, unsafe at any
> speed.  I'd recommend that you consider the alternatives to
> deploying any new systems that use passwords for authentication.

authentication protocols being worked these days?  I mean EKE,
SPEKE, SRP, SNAPI, etc.?

It just depends on the situation, doesn't it?  Ideally, we want
two-factor or better authentication: something you know, something
you have, and something you are.  Whether that kind of stuff is
practical depends on how much money you have to spend on security,
and how much you are protecting.

JM

P.S.

In fact the original reason I wondered about salt, was its
use in SRP.  It appeared to me that if the user could know
the salt without asking the server, then you could get by with
one less message.  The question, then, was what to make the
salt that the user would actually know, while not losing the
properties salt has to have to maintain the security properties
that those values need to be entered (known) anyway.

Subject: Re: What is required of "salt"?
Date: 22 Aug 2000 16:47:13 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David A. Wagner)
Message-ID: <8nv3e1$ms1$1@blowfish.isaac.cs.berkeley.edu>
References: <39A2A503.2BCBABE5@sandia.gov>
Newsgroups: sci.crypt
Lines: 20

In article <39A2A503.2BCBABE5@sandia.gov>, John Myre  <jmyre@sandia.gov> wrote:
> It just depends on the situation, doesn't it?  Ideally, we want
> two-factor or better authentication: something you know, something
> you have, and something you are.  Whether that kind of stuff is
> practical depends on how much money you have to spend on security,
> and how much you are protecting.

The fundamental problem is that today's password systems were built
under a threat model that is no longer relevant.

Today, if you send a password over the network in the clear, it *will*
be captured by eavesdroppers; if you force users to pick passwords, they
*will* pick low-entropy secrets.  Neither of these realities matches well

Once you figure out your threat model, you can talk about what is the
right technology.  But my claim is that the threat model that passwords
were designed for is just so rarely seen today in computing that passwords
are typically the wrong tool for the job.

Subject: Re: What is required of "salt"?
Date: Wed, 23 Aug 2000 09:16:19 -0600
From: John Myre <jmyre@sandia.gov>
Message-ID: <39A3EAC3.5D283777@sandia.gov>
References: <8nv3e1$ms1$1@blowfish.isaac.cs.berkeley.edu>
Newsgroups: sci.crypt
Lines: 38

"David A. Wagner" wrote:
<snip>
> The fundamental problem is that today's password systems were built
> under a threat model that is no longer relevant.

Granted.

> Today, if you send a password over the network in the clear, it *will*
> be captured by eavesdroppers; if you force users to pick passwords, they
> *will* pick low-entropy secrets.

Yes, and yes.

> Neither of these realities matches well

Indeed not!

> or in requiring

only the technique you described above: storing password
hashes in a world-readable file.  I certainly agree that such
a system is rarely appropriate.

> Once you figure out your threat model, you can talk about what is the
> right technology. But my claim is that the threat model that passwords
> were designed for is just so rarely seen today in computing that passwords
> are typically the wrong tool for the job.

I think I'll repeat from an earlier post: what are your
thoughts on the so-called "strong password methods" like
SRP?  Do you include them when you say "passwords are
typically the wrong tool for the job"?  Are user-memorized
secrets usually hopeless, regardless of the cryptography?

JM

Subject: Re: What is required of "salt"?
Date: 23 Aug 2000 12:17:19 -0700
From: daw@blowfish.isaac.cs.berkeley.edu (David A. Wagner)
Message-ID: <8o17vv$phv$1@blowfish.isaac.cs.berkeley.edu>
References: <39A3EAC3.5D283777@sandia.gov>
Newsgroups: sci.crypt
Lines: 27

In article <39A3EAC3.5D283777@sandia.gov>, John Myre  <jmyre@sandia.gov> wrote:
> "David A. Wagner" wrote:
> > or in requiring
>
> Hm.  This reads as though when you say "passwords" you mean
> only the technique you described above: storing password
> hashes in a world-readable file.  I certainly agree that such
> a system is rarely appropriate.

Oops, here I meant to refer specifically to sending passwords in the
clear over a network.  Somehow the "in the clear" phrase didn't survive
my self-editing.  Sorry.

> I think I'll repeat from an earlier post: what are your
> thoughts on the so-called "strong password methods" like
> SRP?

Excellent stuff, when the threat model is right.

Sorry, I didn't mean to include them in my complaint about passwords.
There are plenty of good uses for passwords (e.g., encrypting private
keys; enable codes for smartcards; ATM PIN's); I only wanted to complain
accompanying crypto.  I realize that my original post did a very poor
job of communicating that intention.  Ok, I think I'll go back to writing
school now. :-/

Subject: Re: What is required of "salt"?
Date: Tue, 22 Aug 2000 00:00:38 GMT
From: jsavard@fNrOeSePnAeMt.edmonton.ab.ca (John Savard)
Message-ID: <39a1c26e.140086@news.ecn.ab.ca>
References: <39A16A60.2FB4F96C@sandia.gov>
Newsgroups: sci.crypt
Lines: 15

On Mon, 21 Aug 2000 11:44:00 -0600, John Myre <jmyre@sandia.gov>
wrote, in part:

>The main purpose of salt, as I understand it, is to ensure
>that entries for the same password aren't the same (or rather,
>that the adversary cannot tell that the entries are for the

Basically, it is meant to hinder precomputation. So if a hacker has a
of each one, he must go through the whole dictionary for every
password file entry he wishes to compromise.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

Subject: Re: What is required of "salt"?
Date: Thu, 24 Aug 2000 00:45:46 +0100
From: David Hopwood <hopwood@zetnet.co.uk>
Message-ID: <39A4622A.8B8C9997@zetnet.co.uk>
References: <39A16A60.2FB4F96C@sandia.gov>
Newsgroups: sci.crypt
Lines: 107

-----BEGIN PGP SIGNED MESSAGE-----

John Myre wrote:
> =

> I'm wondering what (cryptographic) properties "salt" has to have.
> =

> Let me begin by restricting the question to salt as used in
> password files.  This might be the original Unix-style file,
> or it might be some verifier-based setup.
> =

> The main purpose of salt, as I understand it, is to ensure
> that entries for the same password aren't the same (or rather,
> that the adversary cannot tell that the entries are for the
> same password).  Is there more?

An attacker can start a dictionary attack at the time when he/she
learns the salt. Therefore, the salt should be unpredictable, so
that the attack can only be started when the password file is
compromised. This point appears to have been missed in the other
replies that stated that salts only have to be unique.

It's also worth pointing out that passwords are often shared between
different systems (there seems to be no practical way to dissuade
users from doing this; I even do it myself despite knowing the risks).
So even if we don't consider the time at which a dictionary attack
can be started to be significant, salts should preferably be globally
unique, not just unique on a single system.

> Usually I see the assumption that the salt is "random".  I
> don't see, however, why this is so.

The desired property is a high "guessing entropy" [1], i.e. it should
not be possible for an attacker to order the possible salts in
such a way that searching them in that order has a non-negligable
probability of success, with a feasible amount of work. This is
the same property that is needed for security of cryptographic keys
against (slightly generalised) brute force attacks.

Salts don't *necessarily* need to be strongly random in the sense
required for the output of a pseudo-random function, or the keystream
of an additive stream cipher (i.e. that each bit cannot be feasibly
predicted with probability significantly greater than 1/2, given all
the other bits). OTOH, if they are random in this strong sense, the
length of salt needed will be shorter.

> For example, what would be wrong with using a simple counter to
> generate salt values?

It is predictable; see above.

> Or, what if the salt were the concatenation of the user name
> and the server name (or address)?

Also predictable.

> Is there a reason to change the salt when we change the password?

Yes, if changing the password is intended to contribute to recovering

Another desirable property of passphrase hashes, rather than salts, is
that they be computationally expensive (variably so, so that increases
in processor speed do not obsolete the hash), and no more cost-efficient
to calculate in a dictionary attack using special-purpose hardware, than
they are on a typical machine in normal use. (One way of attempting to
achieve the latter is to make the hash memory-intensive.)

A good overview of this is [2], which suggests two concrete passphrase
hashes based on these criteria.

[1] David Wagner,
http://www.cs.berkeley.edu/~daw/my-posts/entropy-measures

[2] Niels Provos and David Mazi=E8res, The OpenBSD Project
Presented at USENIX '99.
http://www.usenix.org/events/usenix99/provos.html

- -- =

David Hopwood <hopwood@zetnet.co.uk>

RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBOaRhuTkCAxeYt5gVAQEHxQgAuKXYLSiWjq79d1S1seQouQ3pyuFBOFM7
ZPbpBEOTpWXbfsHtTb4WCtyce3zzFVzoey/JVCuRttTWphihoSul9Apz4bCiaacm
YIUHS3eOZANpbnX8wb9StuMk3w8tH0nX+IHptKweScbxX8HZqHKvdOI+7IpTLhco
1laB6jSFiftWfn/81zUHbYEh9vAtrNWNxObc9Dd+IfaBY3HIvFC6BZJNVABMZOCE
fqzTQ1rBG6EKlkLbo+5wy6lh2OqmUF+atIBPWev87oT47sGKVQpwZI1BuNGAlJXY
0/KtO2A/gckXrfRznsifS1ZOC3gmkn9V3h0Qdj6MGsK/aap7G0nhjg=3D=3D
=3DgQtK
-----END PGP SIGNATURE-----



Terry Ritter, his current address, and his top page.

Last updated: 2001-06-27