Re: Re: Encrypting pg_shadow passwords
От | Alex Pilosov |
---|---|
Тема | Re: Re: Encrypting pg_shadow passwords |
Дата | |
Msg-id | Pine.BSO.4.10.10106152333570.17529-100000@spider.pilosoft.com обсуждение исходный текст |
Ответ на | Re: Encrypting pg_shadow passwords (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Список | pgsql-hackers |
On Sat, 16 Jun 2001, Lincoln Yeoh wrote: > 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. Actually, there's more or less bsdish convention at this (implementation of multiple ways of hashing a password). It may be a good idea to do postgres' implementation to conform to this convention. (Net/Free/OpenBSD all store password in passwd file according to this convention). Convention is, crypted password looks like $algorithm_id$salt$hash Where algorithm_id is a small system-dependent number, convention is that algorithm_id 1 is MD5 and is supported everywhere. Benefit of adhering to this is that, assuming postgresql doesn't invent its own algorithms for hashing, you can exchange password data between system files and postgresql shadow table, and also, you don't need to massage data coming from conformant bsd-ish crypt implementations. -alex
В списке pgsql-hackers по дате отправления: