Re: Shadow Passwords
> Actually I think the new shadow password suite with more suitable copyright
> is released. Getting an ELF version of the system running is our first
Good, because ELF makes supporting shadow passwords easier, too: no need
to link with libshadow.a - getspnam() is in libc5.
> priority, but shadow passwords are still on the queue. Actually, I would like
> to have the option to use MD5 to hash them, too. Note that MD5 hashing can't
> be the out-of-the-box-default because it is not compatible with sharing
> password files with other Unix hosts.
There is a MD5-based crypt() in recent releases of FreeBSD. It is possible
to be compatible with both versions of crypt() at the same time - strings
returned by the new one begin with the magic "$1$". Just modify crypt() in
libc as follows:
crypt(const char *clear, const char *salt)
if (strncmp(salt, "$1$", 3) == 0)
return new_crypt(clear, salt);
/* ... the standard old-style crypt() ... */
This change can be done even now - new_crypt() is called only if the magic
string matches. This shouldn't break anything, existing old-style passwords
continue to work, but we can now copy encrypted passwords from the second
most popular free OS.
To generate new-style encrypted passwords, it is necessary to modify passwd
to generate salt strings starting with the magic (they can also be longer -
the FreeBSD crypt() supports up to 8 characters of salt). This should be
an option (not the out-of-the-box default) - other systems (except FreeBSD)
will not understand our new encrypted passwords.
The passwd program in the new (not yet released) version of the shadow suite
supports that (as an option in /etc/login.defs).
I think it would be nice to have a separate small shared library containing
only crypt() - this way it will be easier to change in the future without
need to rebuild the whole libc which is quite big already. Unfortunately,
this requires that all programs using crypt() are linked against the new