Re: [HACKERS] PQencryptPassword() and encoding

2006-12-19 Thread Tom Lane
Jeroen T. Vermeulen [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] PQencryptPassword() and encoding

2006-12-19 Thread Jeroen T. Vermeulen
On Wed, December 20, 2006 11:08, Tom Lane wrote:
 Jeroen T. Vermeulen [EMAIL PROTECTED] 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



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq