Date: Mon, 17 Feb 1997 22:20:03 +0200 From: Mark Murray <mark@grondar.za> To: Mikael Karpberg <karpen@ocean.campus.luth.se> Cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Message-ID: <199702172020.WAA03755@grackle.grondar.za>
next in thread | raw e-mail | index | archive | help
Mikael Karpberg wrote: > At least some of that seems like a great idea. > I mean... Why not have the fields use $name$salt$passwd$ ? > Where name is the name of the encryption used? $1$ really says nothing. > And then you would never have the problem with different OSes having > different numbering. the name stays the same, right? bfish, des, md5, etc... > Sure, to be backward compatible after changing, you could just make > "1" alias for "md5" and "2" alias for "bfish", but that's no biggie. > And it could be solved with symlinks for this idea. I like this, In fact Brandon is coding it up. > How about having dynamically linked crypt routines, that follow some API, > and are loaded by name? Like.... Umm... have /etc/crypt/ contain maybe a > settings file, and then also some .so files, that are loaded when needed > and then kept in memory. This will take some repair. IIRC, JDP has offered to do this. > Normally you could have /etc/crypt/md5.so and maybe /etc/crypt/des.so, if you > add the des package. Also you would have symlink 1.so -> md5.so, and it > would be quite easy if you, for example, had a file with blowfish passwords > from OpenBSD that you wanted to use. Just do: > "cd /etc/crypt/ ; cp ..../blowfish.so blowfish.so ; ln -s blowfish.so 2.so" > Then copy the passwd file, and make the .db files, and it Just Works. This come perilously close to breaking the "static only" link that some fols want exclusively in /bin/sbin. > If loading the .so file set in $name$ field failed, crypt could just return > a string like "****************", which is not likely to match anything, or > simply return NULL. _*MAJOR*_ security hole. Do you want an algorithm that you can break in with straight away? This is it. The essence of crypt is that you are _*NOT*_ allowed to deduce the password from the output. > Maybe not a completely thought through idea, but... would something like it > work? You'll have to go back to the man pages for crypt, and see what errors it is allowed to return: NONE. The best I can think of in the case of an error (and I do not like the idea) is UUENCODEd rubbish from /dev/random. I think this is making it too complicated, and opening up avenues of attack. Out of my thumb, here is an attack - a user supplied foocrypt.so, supplying whatever password it found for root, and ignoring its input. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702172020.WAA03755>