Full Disclosure mailing list archives
Re: Salted passwords
From: T Biehn <tbiehn () gmail com>
Date: Mon, 10 Aug 2009 10:35:55 -0400
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 () infratection com> 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/
Current thread:
- Salted passwords T Biehn (Aug 09)
- Message not available
- Re: Salted passwords T Biehn (Aug 10)
- Message not available
- Re: Salted passwords Valdis . Kletnieks (Aug 10)
- Re: Salted passwords T Biehn (Aug 10)
- Re: Salted passwords Lyal Collins (Aug 12)
- Re: Salted passwords T Biehn (Aug 10)
- <Possible follow-ups>
- Re: Salted passwords antisec (Aug 10)
- Re: Salted passwords T Biehn (Aug 10)
- Re: Salted passwords raid (Aug 10)
- Re: Salted passwords T Biehn (Aug 10)