[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns
thoutbeckers at splendo.com
Tue May 27 21:20:24 UTC 2003
Dave Smith <dizzyd at jabber.org> wrote on 27-5-2003 23:10:24:
>-----BEGIN PGP SIGNED MESSAGE-----
>On Tuesday, May 27, 2003, at 14:05 America/Denver, Tijl Houtbeckers
>> Unix doesn't use the hash as authenitcation. It only uses a hash to
>> store the password. Once you use the hash to authenticate you lose
>> most of the advantages of not storing the password in plaintext.
>I see you're missing a critical part of this discussion. We're not
>talking about authenticating using ONLY the digest -- we're
>authenticating with a hash(StreamID + Auth Hash).
PSA proposal (and backed by you, it implies):
Right now the method uses the following algorithm:
value of == sha1(StreamID + password)
This results in storage of the plaintext password in the server's data
storage. Both dizzy and hildjj independently came up with the following
enhancement (let's call it "edigest" for enhanced digest):
value of == sha1(StreamID + sha1(password))
This would result in storage of sha1(password) in data storage, rather
than the plaintext password.
Sha1(password) is stored in the database, let's call this value "shap".
The BOFH on your server then takes your "shap", connects to a different
server where you have an account, he receives the streamid. Then he
sends sha1(streamID+sha1("shap")). If your password is the same on this
server, then (s)he'll be authenticated!
Now let's take a look at what Casey proposed, wich uses the same
principle I propese but with a little less local protection.
Sha1(password+hostname) is stored in the database, let's call call it
"shaph". That nasty BOFH is at it again, and takes your "shaph" out of
the DB. Then he connects to that different server again (with that
different hostname). He send sha1(StreamID + sha1("shaph")). However,
the shaph stored in the DB of *that* server is different, since it has
a different hostname. So the sha1(StreamID + sha1("local-shaph")) that
the server does is different. And poor BOFH get's back a "Not Allowed".
The only difference in What I proposed (twice ;) is using a random
number for each password, rather then using hostname with every
The only thing the streamID does is what it always did, protect you
>> *NIX would allow me to authenticate using the hash it actually
>> stores. That would mean that if I'm the BOFH at a *NIX server where
>> you have a shell acount I could log into every other shell accounts
>> you have where you use the same password. In other words, there's a
>> good reason *NIX does exactly *not* what you propose here.
>> The *least* you could do, is concat a random key to the password
>> before you hash it and store both the hash and the random key in the
>> database, and send this key to the client before it SHA1's the
>> password. Then you at least protect other accounts on the server
>> (unless the admin changes the password, wich you would notice),and
>> other servers/applications. Then we solve some actual issues,
>> without having to worry other people will think it's a good idea.
>Having a key which is available on the server doesn't solve anything.
>If I'm a malicious sys admin, I can still make guesses at people's
>passwords since I have access to both the hash and the "key". So what
>"actual" issue does this solve?
Sure, with my system, the admin can still try and guess my password. Or
try and decrypt my SHA1 hash for all I care. With your proposal, he
doesn't *has* to.
The issue that is solves? With your method I can log into every system
that uses your edigest and where you use the same password. With Caseys
proposal on every system on the same host. With my proposal, only the
one account that the password is for, even if you use the same password
for other other accounts, local or non local (local, if the BOFH is
root, is still vonurable in a lot of other ways ofcourse).
Your solution is only as good as it is obscure. When it's no longer
obscure and all systems support it, the same problem you tried to solve
is back. Unless the problem was that you don't want the admin to know
you use dirty words as a password ;)
So how does *NIX do this? Well, you always give *NIX your pass in
plaintext. That doesn't necisarly mean it is send over the line
plaintext, you could use SSH for that. I suppose that, if you're root
on a machine you're trying to hack you could recompile the login
procedure, and have it match the SHA1 you stole with the SHA1 that unix
stores. But what's the f*ing point in that if you're root already?
So, Casey/my version of edigist is in many ways even more secure as
*nix, since the only time the password is exposed to the server in any
useable form (for a different account) is during registration. (with
unix, everytime you log in). The disavantage is, if you loose the
random number that goes with the password the password is useless (my
proposal), if you change the hostname the password is useless and
you're tied to one hostname (Casey).
Software Engineer @ Splendo
More information about the Standards