full-disclosure - Re: Salted passwords

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <C1FDFE027DA44ED185683F3432EF2EC1@VectraLyal>
Date: Tue, 11 Aug 2009 15:27:45 +1000
From: "Lyal Collins" <lyalc@....net.au>
To: "'T Biehn'" <tbiehn@...il.com>,
	<Valdis.Kletnieks@...edu>
Cc: 'full-disclosure' <Full-Disclosure@...ts.grok.org.uk>
Subject: Re: Salted passwords

I'm not a crypto guru, but it seems to me that this issue can be
crypto-anlayses somewhat like the speedups used to find hash collisions (if
I understand them at all).

The goal in both cases is to find a hash that 'collides' with a known hash
(password hash, or CC number of 6 BIN digits, 9,999,999,999 values and 1
checkdigit) from a known format.
i.e pre-compute some portion of the salt+_static_string_portion, then
brute-force the remainder of the string.

As long as the salt is private or long enough, then does it matter?
lyalc

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of T Biehn
Sent: Tuesday, 11 August 2009 6:51 AM
To: Valdis.Kletnieks@...edu
Cc: full-disclosure
Subject: Re: [Full-disclosure] Salted passwords

Valdis,
I don't have control over the set. Sorry I wasn't more explicit about this.
Although, it should have been obvious that the solution needed to satisfy
the conditions:
Data to one way hash.
The set has 9,999,999,999 members.

Thanks for your input sweetie!

-Travis

On Mon, Aug 10, 2009 at 4:26 PM, <Valdis.Kletnieks@...edu> wrote:
> On Sun, 09 Aug 2009 20:14:57 EDT, T Biehn said:
>> Soliciting random suggestions.
>> Lets say I have data to one-way-hash.
>> The set has 9,999,999,999 members.
>
> Actually, if you're using a 10-digit decimal field, you probably have 
> 10**10 possible members - all-zeros counts too (unless there's *other* 
> reasons zero isn't a legal ID).  It's those little off-by-one errors that
tend to get you.
> ;)
>
>> It's relatively easy to brute force this, or create precomp tables.
>
> That's because you only have 10M billion members to brute force against.
>
>> So you add a salt to each.
>
> A better idea cryptographically would be to fix the 10**10 member 
> limit, so that the set *could* have a much higher possible number of 
> members.  Even staying at 10 characters, but allowing [A-Za-z0-9] (62 
> possible chars) raises your space to 62**10 or about 8.3*10**17 (or almost
10M times the difficuly).
> That's why most symmetric crypto algorithms use at least 64-bit or 
> even larger keys, and even larger for RSA and similar public-key systems.
>
>

--
pgp http://pastebin.com/f6fd606da pgp

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

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