EPS support in future pam_unix replacement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ There's something seriously broken with pam-list.  I'm receiving
lots of duplicates of old posts.  However, it's the first time I've
received the one I'm replying to. ]

[ I've changed the subject as we've been discussing too many topics
under the old one ("2nd Qs: proposed description of new pam_unix"). ]

> > prefix=                 -- will use the traditional DES-based hashes
> > prefix=xy               -- the same (could use any valid salt)
> > prefix=$1$              -- FreeBSD-style MD5-based hashes (replaces "md5")
> > prefix=_ count=100001   -- BSDI/FreeSec extended/"new-style" DES-based hashes
> > prefix=$2a$ count=8     -- OpenBSD-style Blowfish-based hashes
> 
> The only suggestion I'd make would be to ensure that the SHA-1 based EPS
> hashes were also properly supported, as they are starting to see wide
> use.  I'd be willing to help with the integration.

Do you suggest that we support EPS hashes within the same PAM module?
If yes, do you also suggest that we support them within the libcrypt
interface I've proposed (and implemented as a glibc/libcrypt patch)?
The latter would imply that we implement an equivalent of t_makepwent()
within crypt(3) in libcrypt.

Let me also suggest something: stop using non-iterated SHA-1 hashes
before they're used any wider.  Use a modern iterated hash intended
for passwords instead.  It would be best to use crypt(3) available on
the system, and let the administrator choose the hashing method (with
a prefix/count pair).

With the SHA-1 hashes, I'd rather avoid using SRP/EPS on my systems.

Signed,
Solar Designer





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux