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

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   |/