From: Dave Aronson (spamtrap.secfocusdja.mailme.org)
Date: Tue Dec 16 2003 - 11:35:29 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Mon December 15 2003 14:32, Craig Minton wrote:

> Someone suggested recently of using the password as the salt.

Ask yourself how you would go about attacking the password file of a
site known to do this.

(minor bit of "spoiler space" here)

You'd simply prepare a dictionary to retrieve x from hash(x+x) (or
however the salt is applied), rather than directly from hash(x) as
usual. This really just means that the total hashing algorithm is
slightly changed, to be about twice as CPU intensive.

The salt should be as unrelated as possible to the thing being hashed,
so as to make the maximum possible combinations of password and salt
that need to be precomputed.

> What would be wrong with this, especially if it
> were altered in some way before being used, such as using a simple
> replacement table to change letters to special characters?

If you mean some standardized table, this won't help at all -- the
attackers would know it too, so it's just hash(x+mangle(x)). Again, no
real effect other than a tiny bit of added processing.

If your site uses its own S00per Sekr1t randomly generated substitution
table, that could help... so long as your table is indeed kept secret.
However, Security By Obscurity is generally a Bad Idea.

> Also, how much less secure would it be to use a user ID as the salt
> instead of a random salt that then has to be stored?

That would be reasonable. It is different for each user (except see
below), and therefore requires a different dictionary per user, which
is the main goal of a salt.

However, it has the drawback of being in a very predictable range on
most systems, and sometimes identical for several important users
(i.e., 0). Therefore, once again, the effort that goes into
precomputing the salted hashes, can be spread out over lots and lots of
systems.

Ideally, you want any dictionary the attacker has already computed, to
be utterly useless against your system. Therefore, you want something
unlikely to be duplicated elsewhere, let alone among multiple users of
your own system. Random (and large) really is best, by far....

--
Dave Aronson, Senior Software Engineer, Secure Software Inc.
(Opinions above NOT those of securesw.com unless so stated!)
Email me at: work (D0T) 2004 (T) dja (D0T) mailme (D0T) org
Web: http://destined.to/program http://listen.to/davearonson

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]