Re: Password checking theorical question
From: Jean-Luc Cooke (jlcooke_at_engsoc.org)
Date: 12/10/04
- Next message: Jean-Luc Cooke: "Re: k-way hash collisions"
- Previous message: David Wagner: "Re: Getting Entropy From The Internet"
- In reply to: Arnaud Carré: "Password checking theorical question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 10 Dec 2004 16:46:38 GMT
Arnaud ,
This is IMHO the best way to store password tokens for future
verification and requires no secret keys.
P = password (any length)
B = Number of bits of salt to use
N = Number of hash iterations to perform
S = salt (B random bytes)
H = token to store for future verification
U = username
H = Hash^N( U || S || P )
H = Hash( Hash( ... Hash( U || S || P ) ... ) )
Store:
{U, S, H}
When asked to verify that P' belongs to user U:
T = Hash^N( U || S || P' )
if (T == H)
then assume P' == P for user U
This is good for two reasons:
- the Salt makes the space-complexity of a dictionary attack 2^B
times harder.
+ The amount if disk-space you need to pre-compute a dictionary
- the hash iterations makes the time-complexity of a dictioanry attack
2^N times harder.
+ The amount of CPU time needed to pre-compute a dictionary
+ this alsomakes on-the-fly password searching attacks take 2^N times
longer.
- the username is optional, but help ensure that a bad random number
generator for S isn't critical to security.
- Usign CRC32 as your Hash() function is not advised. Why? Because no
matter what your B and N parameters are, the difficulty of guessing a
user's password to work is 1 in 65536. Completly unacceptable
JLC
ps. give up on CRC32.
"Arnaud Carr?" <arnaud.carreNOSPAM@freesurf.fr> wrote:
> Sorry for posting an old question with a new form. Some time ago I wanted
> your opinions about a "cheap" way of testing if a passphrase is correct or
> not without de-cyphering the complete data. I made a "cheap" method using
> CRC32. I know it sounds "horrible" to you, and it "sounds" horrible to me
> too, but I really don't see the weak. To be more precise, here is the
> description of my algo before my question:
> P = asscii passphrase, with a supposed "128 bits" entropy in our sample
> K = binary key of 256bits, obtained from P using a strong "key derivation"
> func ( PKCS-5 for exemple )
> Message is encoded with a "strong" block cypher , let's say AES-256 in CBC
> mode. (of course we suppose there is no weak in implementation, that is,
> random IV, password salt and all these boring stuff)
> When crypting, I ouput these values:
> - CRC32(P) ( 4bytes)
> - encrypted datas.
> so now my question: using poor CRC32 to store the crc of the passphrase in
> plaintext sounds horrible (even to me), but how did that CRC help an
> attacker in my case ? I mean, I don't see anything else than brute force on
> 2^128 passphrase ( I suppose 128bits of entropy) ?
> The CRC could maybe optimize a bit the brute force search by fastly removing
> passphrase with wrong CRC, but an attacker still have to do brute force on
> 2^128 passphrase ( let's say 2^127 with birhday paradox :-))
> Is there another way than brute force an attacker could use in my case ?
> thanks in advance
> Arnaud
--
- Next message: Jean-Luc Cooke: "Re: k-way hash collisions"
- Previous message: David Wagner: "Re: Getting Entropy From The Internet"
- In reply to: Arnaud Carré: "Password checking theorical question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
