Re: [Full-disclosure] Salted passwords

[T Biehn <tbiehn@xxxxxxxxx>]

Richard,
The approach I outline in my post is the correct one, that is, making
it computationally expensive to crack. I'm not trying to protect
passwords, think anonymizing account numbers and the like.. That is,
the possible combinations are a set that is unacceptably small.
Without an expensive compute step it's trivial to brute force given a
static salt location...

(excuse my use of shitty pseudocode, assume homogeneous length 10)

Typically the test is:

if storedHash = hashFcn(userPassword & storedSalt) //9,999,999,999 tests

if you randomly store the storedSalt ANYWHERE within userPassword, it becomes

for (int i=0; i<len(userPassword); i++) {
    String toTest = substring(userPassword,0,i) & storedSalt &
substring(userPassword,i)
    if storedHash = hashFcn(toTest) {
       return true;
    }
}
return false; //99,999,999,990 tests

and like hashFcn could be

for (int i=0;i<expensive;i++) {
x = pgp(x);
x = md5(x);
}
return x;

It'd be heavy if pgp were using 4096 bitsize keys. Tweak 'expensive'
to match average acceptable test time. (5 seconds to run 10 tests.)

The set size increases, and brute force attempts become more difficult
(as for each brute force test in the set you must test 'strlength'
times). That is, in a set of homogeneous length strings the hash set
is set size times string length.

I believe this is a rather typical approach. I'm interested to see if
someone else has any other ideas/accepted methods for effectively
increasing the hash set size without increasing the value set size.

It's more so that I'm trawling the net for like minded individuals
rather than soliciting actual advice. Other methods are fairly
obvious.
Using two salts with random locations, etc.

I'm afraid it follows, though, that I reach a point where it's too
expensive, and thus login to a service will suffer an unacceptable
delay, this limitation precludes me from preventing against cracking
by the "10 million dollar computer" and certainly such a scheme will
not be 'future proof.'

-Travis

On Sun, Aug 9, 2009 at 11:56 PM, Richard
Golodner<rgolodner@xxxxxxxxxxxxxxxx> wrote:
**REDACTED**
"explain please"
**REDACTED**

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/