Thread: Bad error message on valuntil
Hello, I had a customer pulling their hair out today because they couldn't login to their system. The error was consistently: 2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password authentication failed for user "user However the problem had nothing to do with password authentication. It was because the valuntil on the user had been set till a date in the past. Now technically if we just removed the word "password" from the error it would be accurate but it seems it would be better to say, "FATAL: the user "user" has expired". Sincerely, Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats
"Joshua D. Drake" <jd@commandprompt.com> writes:
> I had a customer pulling their hair out today because they couldn't
> login to their system. The error was consistently:
> 2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
> authentication failed for user "user
> However the problem had nothing to do with password authentication. It
> was because the valuntil on the user had been set till a date in the
> past. Now technically if we just removed the word "password" from the
> error it would be accurate but it seems it would be better to say,
> "FATAL: the user "user" has expired".
I think it's intentional that we don't tell the *client* that level of
detail. I could see emitting a log message about it, but it's not clear
whether that will help an unsophisticated user.
regards, tom lane
On 06/07/2013 11:57 AM, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> I had a customer pulling their hair out today because they couldn't >> login to their system. The error was consistently: > >> 2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password >> authentication failed for user "user > >> However the problem had nothing to do with password authentication. It >> was because the valuntil on the user had been set till a date in the >> past. Now technically if we just removed the word "password" from the >> error it would be accurate but it seems it would be better to say, >> "FATAL: the user "user" has expired". > > I think it's intentional that we don't tell the *client* that level of > detail. Why? That seems rather silly. > I could see emitting a log message about it, but it's not clear > whether that will help an unsophisticated user. This is not an unsophisticated user. They tried resetting the password, even changing the username to lowercase in case it was some weird folding issue. Granted they didn't check pg_user but then again, I didn't at first either because, well the error was rather obvious until it wasn't. Sincerely, JD > > regards, tom lane > > -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats
Tom Lane-2 wrote > "Joshua D. Drake" < > jd@ > > writes: >> I had a customer pulling their hair out today because they couldn't >> login to their system. The error was consistently: > >> 2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password >> authentication failed for user "user > >> However the problem had nothing to do with password authentication. It >> was because the valuntil on the user had been set till a date in the >> past. Now technically if we just removed the word "password" from the >> error it would be accurate but it seems it would be better to say, >> "FATAL: the user "user" has expired". > > I think it's intentional that we don't tell the *client* that level of > detail. I could see emitting a log message about it, but it's not clear > whether that will help an unsophisticated user. > > regards, tom lane I presume that "password" in this context refers to the method by which identity is checked; some alternatives being "trust" and "ident"? Using the same logic of why you would not expose the fact that the user is expired versus the user has provided invalid credentials exposing "password" is a security leak as well. And then, to top it off, provides a red herring to the user trying to figure out why their username/password combination isn't working. Something like: 'Authentication for user "user" failed. Update and try again or contact the administrator to confirm "user" is authorized to log onto the system.' David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Bad-error-message-on-valuntil-tp5758369p5758383.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
"Joshua D. Drake" <jd@commandprompt.com> 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.
regards, tom lane
David Johnston <polobo@yahoo.com> writes:
> I presume that "password" in this context refers to the method by which
> identity is checked; some alternatives being "trust" and "ident"?
Right.
> Using the same logic of why you would not expose the fact that the user is
> expired versus the user has provided invalid credentials exposing "password"
> is a security leak as well.
No; the client side already knows that password auth is in use, because
it received a password challenge message. I suppose you could construct
some argument about how the textual report might be exposed to higher
code levels that didn't know that, but we haven't chosen to theorize
about what happens on the client side to that extent.
> And then, to top it off, provides a red herring
> to the user trying to figure out why their username/password combination
> isn't working.
It's not really a red herring, because in fact the password was what
failed. (Joshua's wording proposal has a conceptual flaw, because
it supposes that rolvaliduntil represents an expiration date for the
user, but really it's only an expiration date for the password.)
regards, tom lane
On 06/07/2013 12:31 PM, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> 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 > -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats
On Fri, 07 Jun 2013 13:07:21 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: > > On 06/07/2013 12:31 PM, Tom Lane wrote: > > "Joshua D. Drake" <jd@commandprompt.com> 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? +1
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.
On 06/07/2013 01:41 PM, David Johnston wrote: >> >>> > > "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 don't agree. The user doesn't need access to the logs. If they get that error they report it to their support staff. We don't need to tell them any more than that.
On 06/07/2013 12:31 PM, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> 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
I was looking at the code and I saw this catchall:
default: errstr = gettext_noop("authentication failed
for user \"%s\": invalid authentication method"); break;
I think we could make the argument that if valuntil is expired that the
authentication method is invalid. Thoughts?
Else I am trying to come up with some decent wording... something like:
Authentication failed: not all authentication tokens were met
?
On 06/08/2013 04:07 AM, Joshua D. Drake wrote: > > FATAL: Authentication failed: Check server log for specifics > > And then we make sure we log proper info? "FATAL: Authentication using method 'password' failed, possible reasons are no/wrong password sent, account expired; see server log for details" ? We can tell them what they would already know (they tried the 'password' method) and a little about what might be wrong, as well as where to go for more info. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
* Tom Lane wrote: > it supposes that rolvaliduntil represents an expiration date for the > user, but really it's only an expiration date for the password.) Does anyone think the docs for CREATE ROLE/VALID UNTIL should mention this more clearly? Currently, it is described as The VALID UNTIL clause sets a date and time after which therole's password is no longer valid. If this clause is omittedthepassword will be valid for all time. This is entirely correct, but I think it could be made clearer by adding a sentence like "This clause does not apply to authentication methods that do not involve a password, such as trust, ident, and GSSAPI." And at the top of section 19.3 (Authentication Methods): "Time restrictions for the logon of users controlled by an external authentication service, such as GSSAPI or PAM, can be imposed by that service only, not by PostgreSQL itself." -- Christian
On 6/7/13 2:57 PM, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> I had a customer pulling their hair out today because they couldn't >> login to their system. The error was consistently: > >> 2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password >> authentication failed for user "user > >> However the problem had nothing to do with password authentication. It >> was because the valuntil on the user had been set till a date in the >> past. Now technically if we just removed the word "password" from the >> error it would be accurate but it seems it would be better to say, >> "FATAL: the user "user" has expired". > > I think it's intentional that we don't tell the *client* that level of > detail. I could see emitting a log message about it, but it's not clear > whether that will help an unsophisticated user. Usually, when I log in somewhere and the password is expired, it tells me that the password is expired. I don't think we gain anything by hiding that from the user.
On 06/19/2013 08:24 AM, Peter Eisentraut wrote: >> I think it's intentional that we don't tell the *client* that level of >> detail. I could see emitting a log message about it, but it's not clear >> whether that will help an unsophisticated user. > > Usually, when I log in somewhere and the password is expired, it tells > me that the password is expired. I don't think we gain anything by > hiding that from the user. > FTR: there is an actual patch for this sitting over at the, "Change authentication error message" thread. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats