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
Re: Re: Encrypting pg_shadow passwords |
Список | 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 по дате отправления: