[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns

Tijl Houtbeckers 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:
>Hash: SHA1
>Hi Tijl,
>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. 
>> Imagine 
>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 
against sniffing. 

>> *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). 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list