[Pkg-shadow-devel] Linking Shadow to OpenSSL

[Robert Connolly]

On Saturday August 23 2008 07:26:48 am you wrote:
> First, I never heared about sha256 or sha512 passwd
> hash. Previously, we got request for including blowfish
> passwd hash support (IIRC it's used in openbsd).
>
> If you can provide more info on using sha256/sha512
> hash in Unices, that would definitely help us.

Sha256/512 was added to Glibc-2.7, and Shadow added support for it soon after. 
As far as I know, almost no one else uses sha256/512 passwords; the only one 
I found was OpenSolaris, and they did it for Glibc compatibility. NetBSD has 
hmac-sha1. Pam-Linux has sha1, and bcrypt, but I don't know about 256/512.

> > There are great advantages to using OpenSSL instead
> > of Libc. We would have a more robust choice in
> > algorithms,
>
> Well, given that reference implementations exist for
> all of DES/MD5/SHA/AES and blowfish, I doubt that
> this is _great_ advantage,

The advantage is that OpenSSL's libcrypto has everything Shadow could possibly 
want from a crypto library, and almost everyone already has it installed. 
OpenSSL already exists and is usable with Shadow without modifying OpenSSL.

> > random sources for salt,
>
> Remember the Debian's openssl bug with disabled
> seeding off the stack?

I would imagine that this is fixed now, and this is no reason to not use 
OpenSSL's rand_bytes() in the future.

> > I don't have the knowledge to finish the SHA patch,
> > but I would like to use RAND_pseudo_bytes() for
> > password salt so we can finally start using
> > unpredictable (not gettimeofday+getpid)
> > non-alphanumeric salt.
>
> Currently I cannot say anything about random salt in
> shadow, I need more time to analyse sources.

Shadow uses gettimeofday() and getpid() as a seed to random(), and then 
random() returns integers for password salt. These provide unique results, 
but they're not random and they are predictable. This is suitable for 
generating two different hashes for the same password, but not suitable for 
evading an attack on the hashed password.

> I'm just 
> not sure that
> 1. truly random salt can be used at all (sorry if I'm
>    pronouncing a complete heresy :))

Random binary data would need to be converted to base64 characters to be used 
in the /etc/shadow file.

> 2. there are big advantages in using truly random salt
>    (I'm not an expert in rainbow tables etc)

When generating a table the attacker can eliminate all the time before the 
user was added (home directory creation date), all future time, and can start 
by concentrating on the day the user was added because this is the most 
likely day that the password was created. Both gettimeofday() and getpid() 
are integers, without characters. So now the possible salts can be greatly 
narrowed down, and perhaps the attack becomes more realistic.

> > Opinions, help, comments?
>
> Currently, there is one problem regarding linking
>
> --with-openssl:
> > xrgtn at xrgtn-q40:~$ ldd /usr/bin/openssl
> >         linux-gate.so.1 =>  (0x531ab000)
> >         libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8
> > (0x5315c000)
>
> You see, libssl.so.0.9.8 lies under /usr while
> /bin/login shouldn't depend on anything from there.
>
> I didn't check your patch, maybe it already forces
> shadow to be linked statically aganst openssl :), and
> this would seem a satisfactory solution... I have
> serious doubts about portability of static linking - I
> had problems on x86-64 RedHat systems previously
> (surprisingly, HP-UX and Solaris were OK).
>
> This undermined my fath in openssl's portability a lot.

The other option is moving libcrypto.so to /lib. Shared and static linking to 
OpenSSL could be ./configure options.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20080823/10e5e4d8/attachment.pgp