Bad error message on valuntil

"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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane-2 wrote

"Joshua D. Drake" &lt;

jd@

&gt; 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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joshua D. Drake wrote

On 06/07/2013 12:31 PM, Tom Lane wrote:

"Joshua D. Drake" &lt;

jd@

&gt; 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

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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 the
role's password is no longer valid. If this clause is omitted
the password 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers