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.
Or do you think that the current salt length should be sufficient and stay as is?
On St, 2015-08-12 at 17:44 +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.
Or do you think that the current salt length should be sufficient and stay as is?
Ping? Any opinion on this topic?
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.
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?
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.
On Mon, Jan 25, 2016 at 10:09:43AM +0100, Tomas Mraz wrote:
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.
You can stick to this 6-bit ascii charset and use all 8 bits at the same time. This is already implemented in crypt_blowfish, see e.g. http://cvsweb.openwall.com/cgi/cvsweb.cgi/~checkout~/Owl/packages/glibc/cryp...
On Po, 2016-01-25 at 12:31 +0300, Dmitry V. Levin wrote:
On Mon, Jan 25, 2016 at 10:09:43AM +0100, Tomas Mraz wrote:
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.
You can stick to this 6-bit ascii charset and use all 8 bits at the same time. This is already implemented in crypt_blowfish, see e.g. http://cvsweb.openwall.com/cgi/cvsweb.cgi/~checkout~/Owl/packages/gli bc/crypt_blowfish/crypt_blowfish.c
Perhaps there is some misunderstanding what we're talking here about - I do not see how the source above is any relevant.
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.
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?
Also there is no hashing of the randomness pulled from /dev/urandom. The hashing of fairly nonrandom input (i.e. time) is there only in case the read from /dev/urandom fails.
Here is the proposed trivial patch to raise the salt length to 16 characters. OK to commit?
On Mon, Jan 25, 2016 at 11:58:18AM +0100, Tomas Mraz wrote:
On Ne, 2016-01-24 at 23:21 +0300, Dmitry V. Levin wrote:
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.
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?
Also there is no hashing of the randomness pulled from /dev/urandom. The hashing of fairly nonrandom input (i.e. time) is there only in case the read from /dev/urandom fails.
Here is the proposed trivial patch to raise the salt length to 16 characters. OK to commit?
This should work, although I'd probably replaced 20 with (16 + 1 + (sp - salt)).
pam-developers@lists.fedorahosted.org