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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
