Joshua D. Drake wrote
> On 06/07/2013 12:31 PM, Tom Lane wrote:
>> "Joshua D. Drake" <
> jd@
> > writes:
>>> On 06/07/2013 11:57 AM, Tom Lane wrote:
>>>> I think it's intentional that we don't tell the *client* that level of
>>>> detail.
>>
>>> Why? That seems rather silly.
>>
>> The general policy on authentication failure reports is that we don't
>> tell the client anything it doesn't know already about what the auth
>> method is. We can log additional info into the postmaster log if it
>> seems useful to do so, but the more you tell a client, the more you
>> risk undesirable info leakage to a bad guy. As an example here,
>> reporting the valuntil condition would be acking to an attacker that
>> he had the right password.
>
> So security by obscurity? Alright, without getting into that argument
> how about we change the error message to:
>
> FATAL: Authentication failed: Check server log for specifics
>
> And then we make sure we log proper info?
>
> Sincerely,
>
> Joshua D. Drake
>
>>
>> regards, tom lane
>>
In a password login situation you should not indicate to the client why the
login attempt failed. If you say that the password expired they know the
username supplied has to be correct (otherwise how would you know the
password is expired).
However, echoing back the supplied user identifier (without otherwise
implying that it exists or does not exist on the server) provides a quick
verification spot for the user to see whether the expected user name was
being sent - especially since the location of the error message is probably
significantly removed from the location of the user name string on the
client.
"Please check server log for specifics" is not a good message for something
sent to a client that in many normal situation would have no access to said
logs.
I'd suggest:
"Authentication Failed: the user (role_name) & password combination was not
found or is expired."
How a particular user is to go about resolving the issue is an
organizational (and individual) policy best ignored in the error message.
For a stressed-out, administrator-capable, user who sees this message they
at least are reminded that even if the combination exists it is possible
that it is has somehow been disabled. Hopefully they will then remember that
password expiration is possible and will check that along with the presence
of the role/user.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Bad-error-message-on-valuntil-tp5758369p5758398.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
