At 12:02 8/05/00 -0400, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>
>Hmm. The main problem with this is that once we get into having actual
>encryption/decryption code in Postgres, we are going to run afoul of US
>export regulations and other headaches.
I thought that they had been relaxed recently, but I take the point: it's
probably not been relaxed enough. Then again, maybe 48 bit (or 56 or 112 or
whatever) is sufficient.
>One possibility that comes to mind is that we store MD5(MD5(password))
>in pg_shadow, and expect the client to transmit MD5(password).
>Of course that needs a cloaking scheme if you want to protect against
>password sniffing, but offhand it seems that the same scheme Ben Adida
>proposed should still work...
Yes. This seems like a much simpler solution - getting the pg_shadow file
is almost useless, as long as the effectiveness of dictionary attacks is
reduced by a sufficiently large salt.
It still does not protect against a man-in-the-middle attack, since the new
'password' is just a 160 bit value, rather than clear text. Unless SSL is
used, of course.
>
>We have SSL capability already. I don't feel an urge to reinvent SSL.
>
Sounds pretty reasonable to me. But if SSL is already there, don't you have
import/export problems?
----------------------------------------------------------------
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 |/
