Re: So we're in agreement....

At 15:34 7/05/00 -0400, Tom Lane wrote:
>
>You're still not getting the point.  I refer you to Ben Adida's
>original, correct description of the way to do this:
>
>> - client requests login
>> - server sends stored salt c1, and random salt c2.
>> - client performs hash_c2(hash_c1(password)) and sends result to server.
>> - server performs hash_c2(stored_pg_shadow) and compares with client
>>   submission.
>> - if there's a match, there's successful login.
>

I may well have missed something here, but it seems to me that the above
scheme is also not particularly secure since someone who has managed to get
access to the pg_shadow file will be able to fake a login by using a custom
client. ie:
- client requests login- server sends stored salt c1, and random salt c2.- client ignores c1 and performs
hash_c2(some_hash_from_the_file)and
 
sends result to server.- server performs hash_c2(stored_pg_shadow) and compares with client  submission.

Have I missed somehting here? Obviously it depends on getting a copy of
pg_shadow.

It seems that there are at least two problems to solve in the whole
password & authentication problem:

1. How to store passwords so they can't be decrypted.

2. How to perform a secure handshake with a client.

You have already solved (1) by using MD5 (or even SHA, which is faster to
compute).

To solve (2) it seems to me that a slightly more complex interaction must
be undertaken using a public key algorithm:
- Client sends [username] to server- Server sends [public key] to client- Client sends [enc(public key, password)] to
server.- server uses dec(secret key,enc) and computes MD5 hash of password,
 
comparing it to pg_shadow.

This would require a decent large integer library (which certainly exist).
For speed, a key pair would need to be stored on the server, since key
generation is quite slow.

In order for a man-in-the-middle attack to work, the attacker would also
need the secret key off the server. The risk could be reduced, at the
expense of computation, by generating a new key pair for each client,
although that would be *very* expensive.

Additionally, it may be good to allow the entire client/server comms to be
done as an encrypted interaction, since a man-in-the-middle may not be able
to read the password, but they will be able to read the data...

FWIW, I'd be willing to write the password and handshaking code, if no-one
else were interested.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: +61-03-5367 7422            |                 _________  \
Fax: +61-03-5367 7430            |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/