Thread: Re: Re: Proposal for encrypting pg_shadow passwords
> 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> 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?
No, but the old postmaster will reject it. See lines 1056ff in
postmaster.c.
regards, tom lane
Bruce Momjian writes: > 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 Why not take all 255 characters? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Bruce Momjian writes: > > > 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 > > Why not take all 255 characters? Salt is currently defined as char[2]. Should I encode the rand() as char[4] and send that, or skip null and still encode it as char[4]. -- 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
Can someone look at our use of port->salt in the code. The call to crypt() assumes port->salt is null-terminated, doesn't it. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Salt is currently defined as char[2]. Should I encode the rand() as
> char[4] and send that, or skip null and still encode it as char[4].
There's no need to avoid nulls here, AFAICS. Making the salt a
fixed-length binary string seems like the best bet.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can someone look at our use of port->salt in the code. The call to
> crypt() assumes port->salt is null-terminated, doesn't it.
I have not looked at the new patch, but the EncryptMD5 routine at the
bottom of the original patch's md5.c definitely does think that the
salt is null-terminated. It'd be a trivial change to pass the salt
as buffer pointer and length, however, avoiding any assumptions about
nullness.
BTW, it occurs to me that the day may come when a 4-byte salt space
looks too small too. Perhaps we should define the MD5 protocol as using
an 8-binary-byte salt. For the moment, you'd fill it with two calls to
random(), which'd not add any more security than using only one call;
but if we ever need a bigger salt space, we don't have to change the
protocol and clients to do it.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Salt is currently defined as char[2]. Should I encode the rand() as > > char[4] and send that, or skip null and still encode it as char[4]. > > There's no need to avoid nulls here, AFAICS. Making the salt a > fixed-length binary string seems like the best bet. OK, working on that now. The EncryptMD5 function accepts username string and 4-byte salt, so I have to pass the length of the salt to the function. Can't rely on strlen(). -- 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
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Salt is currently defined as char[2]. Should I encode the rand() as > > char[4] and send that, or skip null and still encode it as char[4]. > > There's no need to avoid nulls here, AFAICS. Making the salt a > fixed-length binary string seems like the best bet. We have to avoid NULL because we paste together the password and username with the salt to MD5 encrypt. Also, I now need two salts, one base62 for crypt and a new one for MD5. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, I now need two salts, one base62 for crypt and a new one for MD5.
They're carried in two different messages, so I don't see the problem.
regards, tom lane