Re: Re: Proposal for encrypting pg_shadow passwords
От | Bruce Momjian |
---|---|
Тема | Re: Re: Proposal for encrypting pg_shadow passwords |
Дата | |
Msg-id | 200108161433.f7GEXgn19165@candle.pha.pa.us обсуждение исходный текст |
Ответы |
Re: Re: Proposal for encrypting pg_shadow passwords
Re: Re: Proposal for encrypting pg_shadow passwords |
Список | pgsql-patches |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > We aren't. I can do that, but have not discussed it yet. If we do it > > is clearly a protocol change. How will old clients handle longer salt, > > and how do I know if they are older if I don't bump up the protocol > > version number? > > All of this is under the aegis of a new auth method code, so it doesn't > matter. Either clients handle the new auth method, or they don't. OK, I see how I can do that. I thought the salt was part of the startup packet but I see now that it is send during the authentication request. I can make it longer, probably 6 characters: > 62^6 56800235584 I can get that out of an int4. I will take a single rand() and break it into bsd62 pieces. > The problem with bumping the protocol version number is that it breaks > client-to-server compatibility *whether or not a particular connection > needs the new auth method*. Eg, a new client will be unable to talk to > an old server. This is not good. Why is this the case? There is nothing in the new client code that will conflict with an old server, right? Is it something hardwired in the client code? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-patches по дате отправления: