Re: So we're in agreement....
От | Philip Warner |
---|---|
Тема | Re: So we're in agreement.... |
Дата | |
Msg-id | 3.0.5.32.20000509013840.00b1c830@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: So we're in agreement.... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: So we're in agreement....
Re: So we're in agreement.... |
Список | pgsql-hackers |
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 |/
В списке pgsql-hackers по дате отправления: