Re: New feature: Encrypted gnatsd passwords

[Yngve Svendsen]

> [I'm generally not going to add any new features before GNATS 4 is 
> released. However some missing features can be considered being bugs which 
> should be fixed.]
>
> I added support for MD5 encrypted passwords in gnatsd.access, based on a 
> patch by Tommi Virtanen. Now you can use passwords prefixed with `$1$' 
> there, see the documentation of `crypt' in the GNU libc manual for more 
> details about the form of such passwords. Passwords prefixed with $0$ are 
> exact match passwords. Other passwords remain the same as before, i.e. 
> case sensitive wild card match passwords.
>
> Milan Zamazal


As part of updating the GNATS documentation, I have been experimenting with 
this feature. I got it working on Linux, after figuring out the correct 
format for the MD5 password string (which I have documented thoroughly in 
the latest version of the manual).

However, on Solaris, which lacks glibc, MD5 crypt() is not supported. Now, 
the configuration checks indicate that crypt() is available on Solaris, 
resulting in the MD5-supporting code being compiled into gnatsd but without 
working. The password checking routine in gnatsd.c actually ends up 
comparing an MD5 hash with a DES hash.

By removing a couple of ifs in gnatsd.c, I got things working on Solaris 
with DES-encrypted passwords in gnatsd.access. This leads me to ask the 
following question: Should we implement support for DES-encrypted 
passwords? This should be very easy, except for one thing -- we need a way 
to distinguish DES hashes in gnatsd.access from plaintext passwords.

The ordinary way is of course to prefix MD5 hashes with '$1$' and treat 
everything without this prefix as a DES hash, but in the gnatsd.access 
file, we have a third possibility, namely a plaintext password. Is there a 
standard prefix for DES hashes, or could we simply invent our own?

If we decide not to sypport DES encrypted passwords, the configure checks 
should be tightened so that we can inform the user if he has a crypt() 
without MD5 support.

Yngve Svendsen