Re: Encrypting pg_shadow passwords - Mailing list pgsql-hackers

From Lincoln Yeoh
Subject Re: Encrypting pg_shadow passwords
Date
Msg-id 3.0.5.32.20010616112030.0151dad0@192.228.128.13
Whole thread Raw
In response to Re: Encrypting pg_shadow passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Encrypting pg_shadow passwords  (Alex Pilosov <alex@pilosoft.com>)
Re: Re: Encrypting pg_shadow passwords  (Jim Mercer <jim@reptiles.org>)
List pgsql-hackers
At 02:02 PM 6/15/01 -0400, Tom Lane wrote:
>Vince Vielhaber <vev@michvhf.com> writes:
>>> More to the point, how does the postmaster know that it's now dealing
>>> with encrypted passwords and must use the double-salt auth method?
>
>> The first three characters are md5 in the code I sent Bruce.
>
>Uh ... so if I use a password that starts with "md5", it breaks?
>
>Seems like adding an additional column to pg_shadow would be a better
>technique.

I agree. It helps with migration and other things.

For my apps I have: hashed_password, hashtype, salt. I even had MSG at one
point ;) - MSG=Multiple Salt Grinds (the number of times you do the
hashing), but my fellow developers didn't want that.

So if the hash type is NONE and the salt is '', the hashed password is
actually in plaintext. This is very useful when migrating users or creating
users manually, then when the users next change their password (like NEVER
;) ) it will be using the default hash method. So say you start with
MD5BASE64 you can switch to MD5HEX or SHA1HEX later.

BTW, the passing of one time passwords, and subsequently communicating in
plaintext is a bit too '80s for me. Sure the performance is better, but I
think it should be deprecated. If you need to use encryption then having
_everything_ encrypted is a better idea - SSL etc. Those >1GHz CPUs are
handy ;).

Cheerio,
Link.



pgsql-hackers by date:

Previous
From: Alex Pilosov
Date:
Subject: [PATCH] inet << indexability
Next
From: Alex Pilosov
Date:
Subject: (Really) Re: [PATCH] inet << indexability