Re: Encrypting pg_shadow passwords

Поиск
Список
Период
Сортировка
От Lincoln Yeoh
Тема Re: Encrypting pg_shadow passwords
Дата
Msg-id 3.0.5.32.20010616112030.0151dad0@192.228.128.13
обсуждение исходный текст
Ответ на Re: Encrypting pg_shadow passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: Encrypting pg_shadow passwords  (Alex Pilosov <alex@pilosoft.com>)
Re: Re: Encrypting pg_shadow passwords  (Jim Mercer <jim@reptiles.org>)
Список 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 по дате отправления:

Предыдущее
От: Alex Pilosov
Дата:
Сообщение: [PATCH] inet << indexability
Следующее
От: Alex Pilosov
Дата:
Сообщение: (Really) Re: [PATCH] inet << indexability