Thread: PQencryptPassword() and encoding

PQencryptPassword() and encoding

From
"Jeroen T. Vermeulen"
Date:
Probably a silly question, but better safe than sorry:

AFAICS there's no way for PQencryptPassword() to see what encoding
applies.  Are we quite sure that that is not a problem?  Or are passwords
ASCII-only?


Jeroen




Re: PQencryptPassword() and encoding

From
Tom Lane
Date:
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
> Probably a silly question, but better safe than sorry:
> AFAICS there's no way for PQencryptPassword() to see what encoding
> applies.  Are we quite sure that that is not a problem?

Right offhand it seems that the worst possible consequence is
authentication failure: you originally entered your password
as foobar in encoding X, and then when you enter foobar in
encoding Y, you get the raspberry.  Do you see something else?
        regards, tom lane


Re: PQencryptPassword() and encoding

From
"Jeroen T. Vermeulen"
Date:
On Wed, December 20, 2006 11:08, Tom Lane wrote:
> "Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
>> Probably a silly question, but better safe than sorry:
>> AFAICS there's no way for PQencryptPassword() to see what encoding
>> applies.  Are we quite sure that that is not a problem?
>
> Right offhand it seems that the worst possible consequence is
> authentication failure: you originally entered your password
> as foobar in encoding X, and then when you enter foobar in
> encoding Y, you get the raspberry.  Do you see something else?

That's definitely the first thing that springs to mind.  I don't suppose
the problems we had with escaping could happen here, and there probably
aren't any security implications.

Getting different password hashes depending on your client encoding would
probably not hit a lot of people, but it would be annoying and hard to
debug where it did happen.  If it can happen in the first place, that is,
which is what I'm asking.


Jeroen