Mailing List Archive

Re: feature request [Archie Cobbs <archie@tribe.com>] (fwd)
---------- Forwarded message ----------
From: Archie Cobbs <archie@tribe.com>
Subject: Re: feature request (fwd)
To: brian@organic.com (Brian Behlendorf)
Date: Wed, 9 Aug 1995 13:18:17 -0700 (PDT)
Cc: new-httpd@hyperreal.com, archie@tribe.tribe.com


> On Wed, 9 Aug 1995, Florent Guillaume wrote:
> > > Since both Apache/htpasswd and login(1) use the same function to
> > > encrypt passwords, you'd think that you could just say:
> > >
> > > AuthUserFile /etc/passwd
> >
> > It is evil to use the system passwords for the WWW, because
> > these passwords are sent in clear to whoever asks them.

I agree with that general sentiment, but the encoding of the password across
the net is really an orthogonal issue. For example, suppose SSL was
implemented between client & server... I'd still have the same complaint.

> I'd use the term "unwise", but yeah, I agree that it shouldn't be
> suggested or necessarily enabled in our setup. MD5 authentication is
> going to require storing something other than the crypted password
> anyways.

That's true (and too bad for me). By the way, any projections as to
when this MD5 password encoding gets implemented?

-Archie
Re: feature request [Archie Cobbs <archie@tribe.com>] (fwd) [ In reply to ]
In reply to Brian Behlendorf who said
>
> > I'd use the term "unwise", but yeah, I agree that it shouldn't be
> > suggested or necessarily enabled in our setup. MD5 authentication is
> > going to require storing something other than the crypted password
> > anyways.
>
> That's true (and too bad for me). By the way, any projections as to
> when this MD5 password encoding gets implemented?
>

Why would you need to store something other than the password for
MD5?

FreeBSD uses MD5 by default as shipped, you have to go and get a DES
crypt library separately. It's done like this so we can export a libcrypt.

There's no changes been required to anything at all to use MD5 other than
linking to a different libcrypt.

--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
Re: feature request [Archie Cobbs <archie@tribe.com>] (fwd) [ In reply to ]
On Thu, 10 Aug 1995, Paul Richards wrote:
> In reply to Brian Behlendorf who said
> >
> > > I'd use the term "unwise", but yeah, I agree that it shouldn't be
> > > suggested or necessarily enabled in our setup. MD5 authentication is
> > > going to require storing something other than the crypted password
> > > anyways.
> >
> > That's true (and too bad for me). By the way, any projections as to
> > when this MD5 password encoding gets implemented?
> >
>
> Why would you need to store something other than the password for
> MD5?

You actually need to store the password in plaintext, believe it or not. MD5
was designed to prevent network spoofing - what essentially happens is the
server issues a challenge, the client hashes the challenge + the password and
sends that key back to the server, the server does its own hash of the
challenge + password, and if they match it accepts. This way someone listing
to the traffic can't determine a password they can use to break in. It was
reasoned that security on a single machine is easier to accomplish than
security over the network. It's not just using another form of crypt().

There has been talk about modifying the proposal somehow to get rid of
the requirement for plaintext passwords on the server side, but I don't
know the details. This is just seen as a stopgap measure to plug the
holes in the Basic scheme until more solid methods are available.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: feature request [Archie Cobbs <archie@tribe.com>] (fwd) [ In reply to ]
Last time, Brian Behlendorf uttered the following other thing:
>
> You actually need to store the password in plaintext, believe it or not. MD5
> was designed to prevent network spoofing - what essentially happens is the
> server issues a challenge, the client hashes the challenge + the password and
> sends that key back to the server, the server does its own hash of the
> challenge + password, and if they match it accepts. This way someone listing
> to the traffic can't determine a password they can use to break in. It was
> reasoned that security on a single machine is easier to accomplish than
> security over the network. It's not just using another form of crypt().
>
> There has been talk about modifying the proposal somehow to get rid of
> the requirement for plaintext passwords on the server side, but I don't
> know the details. This is just seen as a stopgap measure to plug the
> holes in the Basic scheme until more solid methods are available.

It doesn't actually store it in plain text. It hashes the password
with other information known to both sides (such as the AuthRealm)
and stores that in the .htpasswd file. That way, its at least a step
more difficult to do (you'd have to modify the client to accept
your hash instead of taking the password and making the hash itself).

So, in Brian's terminalogy, it hashes a default part of the challenge with
the password and stores this. Then, when it issues the challenge,
the client takes the entered password and hashes it with parts of the
challenge, then hashes that with the full challenge. That is compared
against the same thing on the server side.

Brandon

--
Brandon Long (N9WUC) "I think, therefore, I am confused." -- RAW
Computer Engineering Run Linux '95. It's that Easy.
University of Illinois blong@uiuc.edu http://www.uiuc.edu/ph/www/blong
Don't worry, these aren't even my views.
Re: feature request [Archie Cobbs <archie@tribe.com>] (fwd) [ In reply to ]
On Thu, 10 Aug 1995, Robert S. Thau wrote, quoting me:
> You actually need to store the password in plaintext
...
>
> Not *quite* --- you can get away with storing something which is the
> MD5 digest of the password itself, the realm, and maybe some other
> stuff.

Yup, you're right. I should learn to stop talking when the brain cells
turn off. :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: feature request [Archie Cobbs <archie@tribe.com>] (fwd) [ In reply to ]
Date: Thu, 10 Aug 1995 08:27:25 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

You actually need to store the password in plaintext, believe it or
not. MD5 was designed to prevent network spoofing - what
essentially happens is the server issues a challenge, the client
hashes the challenge + the password and sends that key back to the
server, the server does its own hash of the challenge + password,
and if they match it accepts. This way someone listing to the
traffic can't determine a password they can use to break in. It
was reasoned that security on a single machine is easier to
accomplish than security over the network. It's not just using
another form of crypt().

Not *quite* --- you can get away with storing something which is the
MD5 digest of the password itself, the realm, and maybe some other
stuff. This digest doesn't give you the actual password --- but
someone who has a user-agent which has been hacked to make "proper"
use of the digest *can* fool the server into believing that the
cracker is authorized, even without knowing the password itself.

So, the implications for security are *almost* the same as if the
passwords were stored in plaintext, except the information that
actually is stored requires some small degree of technical
sophistication to exploit...

rst
Re: feature request [Archie Cobbs <archie@tribe.com>] (fwd) [ In reply to ]
>
> You actually need to store the password in plaintext, believe it or not. MD5

You do not need to store the password in plaintext. You do however
need to store the hash of the password, which if someone gets ahold
of, they can just send it to the server to masquerade as that user.

Stanford S. Guillory
NCSA-University of Illinois
guillory@ncsa.uiuc.edu