Date: Mon, 17 Feb 1997 23:09:41 +0100 (MET) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: mark@grondar.za (Mark Murray) Cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Message-ID: <199702172209.XAA21730@ocean.campus.luth.se> In-Reply-To: <199702172020.WAA03755@grackle.grondar.za> from Mark Murray at "Feb 17, 97 10:20:03 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
According to Mark Murray: > 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? [...] > > "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. Umm... could you elaborate on this? I don't think I got it :-) > > 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. Just a suggestion. Returning NULl may NOT be the brightest of ideas, I guess. That would just clear the way for some nice random segfaults. :-) However, I don't see how returning something like "************" could in any way result in a security hole. Crypt can not normally return such a string, or can it? I may be wrong, but I've always been taught to put an asterisk fisrt in people's passwords to keep them from logging in. Well, I just put one asterisk there, not a whole bunch. So it can't match that. And it you import a passwd entry with an unknown encryption name, then crypt will just return "**************", which will not match the hashed password for that entry, and therefor the person simply can not log in. At least not until you install that encryption. Then people change their password with "passwd", you could just use the crypt protocol chosen in /etc/crypt/conf (or whatever it would be called). Did I miss something? > > 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. I'm not saying crypt should return an error, but rather a string which it could never return, and one which is never found in the password field, and therefor you don't get a match, and can't log in. Returning something random COULD potentially get the user in on luck. Bad idea, no? Also, if the admin uses a random .so for crypt from John D. Hacker, then... Well... He's basically in trouble anyway, I'd say. /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702172209.XAA21730>