On Ne, 2016-01-24 at 23:21 +0300, Dmitry V. Levin wrote:
Hi,
On Wed, Aug 12, 2015 at 05:44:09PM +0200, Tomas Mraz wrote:
> Hello,
>
> currently pam_unix hardcodes the new salt length when password is
> changed to be 8 characters - this makes it due to the limitation to
> 64
> only possible characters to be 48 bits long. This is slightly lower
> than
> can be considered as long enough for any paranoid. I propose to
> make it
> 12 characters which should satisfy any paranoid person as rainbow
> tables
> of 2^72 hashes for each tested password can hardly be created in
> the
> foreseeable future.
2^(6*8) looks noticeably less compared to 2^(8*16) implemented
in crypt_gensalt_r function from crypt_blowfish.
In current pam_unix implementation, crypt_make_salt loses 2 bits for
each
8 bits of hashed randomness, this certainly needs to be fixed.
Huh, how could it be fixed if we need to stick to ascii characters with
some further limitations? For compatibility reasons I would not agree
with widening the character set used. It is not worth it at all.
I see no point in hashing random input with md5. Why not just read
16
bytes of randomness and make 2^(8*16) bits of encoded salt out of it?
How could you make 2^(8*16) bits of randomness in the encoded salt when
the character set of the salt has to be limited. So the only option is
to raise the salt length up to 16 characters which would make it
2^(6*16) bits of randomness - that is enough to cover any paranoid need
for salt bit length.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)