From owner-freebsd-security  Mon Feb 17 12:21:21 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA11990
          for security-outgoing; Mon, 17 Feb 1997 12:21:21 -0800 (PST)
Received: from grackle.grondar.za (+RQIeqik5IghWYtvGTckemwg0mamF/Fn@grackle.grondar.za [196.7.18.131])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11982
          for <security@freebsd.org>; Mon, 17 Feb 1997 12:21:11 -0800 (PST)
Received: from grackle.grondar.za (yvAWFqaqcJHm9XVsPeMWNGYbXOdMsku9@localhost [127.0.0.1])
          by grackle.grondar.za (8.8.5/8.8.4) with ESMTP
	  id WAA03755; Mon, 17 Feb 1997 22:20:07 +0200 (SAT)
Message-Id: <199702172020.WAA03755@grackle.grondar.za>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Mikael Karpberg <karpen@ocean.campus.luth.se>
cc: security@freebsd.org
Subject: Re: blowfish passwords in FreeBSD 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 17 Feb 1997 22:20:03 +0200
From: Mark Murray <mark@grondar.za>
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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