postgresql/src/backend/libpq/crypt.c

354 lines
9.1 KiB
C
Raw Normal View History

/*-------------------------------------------------------------------------
*
* crypt.c
* Functions for dealing with encrypted passwords stored in
* pg_authid.rolpassword.
*
2017-01-03 19:48:53 +01:00
* Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
2001-11-01 19:10:48 +01:00
* Portions Copyright (c) 1994, Regents of the University of California
*
2010-09-20 22:08:53 +02:00
* src/backend/libpq/crypt.c
*
*-------------------------------------------------------------------------
*/
2001-11-01 19:10:48 +01:00
#include "postgres.h"
#include <unistd.h>
#ifdef HAVE_CRYPT_H
#include <crypt.h>
#endif
#include "catalog/pg_authid.h"
#include "common/md5.h"
1999-07-16 07:00:38 +02:00
#include "libpq/crypt.h"
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
#include "libpq/scram.h"
#include "miscadmin.h"
#include "utils/builtins.h"
#include "utils/syscache.h"
#include "utils/timestamp.h"
/*
* Fetch stored password for a user, for authentication.
*
* Returns STATUS_OK on success. On error, returns STATUS_ERROR, and stores
* a palloc'd string describing the reason, for the postmaster log, in
* *logdetail. The error reason should *not* be sent to the client, to avoid
* giving away user information!
*
* If the password is expired, it is still returned in *shadow_pass, but the
* return code is STATUS_ERROR. On other errors, *shadow_pass is set to
* NULL.
*/
int
get_role_password(const char *role, char **shadow_pass, char **logdetail)
{
1999-05-25 18:15:34 +02:00
int retval = STATUS_ERROR;
TimestampTz vuntil = 0;
HeapTuple roleTup;
Datum datum;
bool isnull;
*shadow_pass = NULL;
/* Get role info from pg_authid */
roleTup = SearchSysCache1(AUTHNAME, PointerGetDatum(role));
if (!HeapTupleIsValid(roleTup))
{
*logdetail = psprintf(_("Role \"%s\" does not exist."),
role);
2010-02-26 03:01:40 +01:00
return STATUS_ERROR; /* no such user */
}
datum = SysCacheGetAttr(AUTHNAME, roleTup,
Anum_pg_authid_rolpassword, &isnull);
if (isnull)
{
ReleaseSysCache(roleTup);
*logdetail = psprintf(_("User \"%s\" has no password assigned."),
role);
2010-02-26 03:01:40 +01:00
return STATUS_ERROR; /* user has no password */
}
*shadow_pass = TextDatumGetCString(datum);
datum = SysCacheGetAttr(AUTHNAME, roleTup,
Anum_pg_authid_rolvaliduntil, &isnull);
if (!isnull)
vuntil = DatumGetTimestampTz(datum);
2002-09-04 22:31:48 +02:00
ReleaseSysCache(roleTup);
if (**shadow_pass == '\0')
{
*logdetail = psprintf(_("User \"%s\" has an empty password."),
role);
pfree(*shadow_pass);
*shadow_pass = NULL;
2010-02-26 03:01:40 +01:00
return STATUS_ERROR; /* empty password */
}
/*
* Password OK, now check to be sure we are not past rolvaliduntil
*/
if (isnull)
retval = STATUS_OK;
else if (vuntil < GetCurrentTimestamp())
2001-08-17 04:59:20 +02:00
{
*logdetail = psprintf(_("User \"%s\" has an expired password."),
role);
retval = STATUS_ERROR;
}
else
retval = STATUS_OK;
return retval;
}
/*
* What kind of a password verifier is 'shadow_pass'?
*/
PasswordType
get_password_type(const char *shadow_pass)
{
if (strncmp(shadow_pass, "md5", 3) == 0 && strlen(shadow_pass) == MD5_PASSWD_LEN)
return PASSWORD_TYPE_MD5;
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
if (strncmp(shadow_pass, "scram-sha-256:", strlen("scram-sha-256:")) == 0)
return PASSWORD_TYPE_SCRAM;
return PASSWORD_TYPE_PLAINTEXT;
}
/*
* Given a user-supplied password, convert it into a verifier of
* 'target_type' kind.
*
* If the password looks like a valid MD5 hash, it is stored as it is.
* We cannot reverse the hash, so even if the caller requested a plaintext
* plaintext password, the MD5 hash is returned.
*/
char *
encrypt_password(PasswordType target_type, const char *role,
const char *password)
{
PasswordType guessed_type = get_password_type(password);
char *encrypted_password;
switch (target_type)
{
case PASSWORD_TYPE_PLAINTEXT:
/*
* We cannot convert a hashed password back to plaintext, so just
* store the password as it was, whether it was hashed or not.
*/
return pstrdup(password);
case PASSWORD_TYPE_MD5:
switch (guessed_type)
{
case PASSWORD_TYPE_PLAINTEXT:
encrypted_password = palloc(MD5_PASSWD_LEN + 1);
if (!pg_md5_encrypt(password, role, strlen(role),
encrypted_password))
elog(ERROR, "password encryption failed");
return encrypted_password;
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
case PASSWORD_TYPE_SCRAM:
/*
* cannot convert a SCRAM verifier to an MD5 hash, so fall
* through to save the SCRAM verifier instead.
*/
case PASSWORD_TYPE_MD5:
return pstrdup(password);
}
break;
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
case PASSWORD_TYPE_SCRAM:
switch (guessed_type)
{
case PASSWORD_TYPE_PLAINTEXT:
return scram_build_verifier(role, password, 0);
case PASSWORD_TYPE_MD5:
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
/*
* cannot convert an MD5 hash to a SCRAM verifier, so fall
* through to save the MD5 hash instead.
*/
case PASSWORD_TYPE_SCRAM:
return pstrdup(password);
}
break;
}
/*
* This shouldn't happen, because the above switch statements should
* handle every combination of source and target password types.
*/
elog(ERROR, "cannot encrypt password to requested type");
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
return NULL; /* keep compiler quiet */
}
/*
* Check MD5 authentication response, and return STATUS_OK or STATUS_ERROR.
*
* 'shadow_pass' is the user's correct password or password hash, as stored
* in pg_authid.rolpassword.
* 'client_pass' is the response given by the remote user to the MD5 challenge.
* 'md5_salt' is the salt used in the MD5 authentication challenge.
*
* In the error case, optionally store a palloc'd string at *logdetail
* that will be sent to the postmaster log (but not the client).
*/
int
md5_crypt_verify(const char *role, const char *shadow_pass,
const char *client_pass,
const char *md5_salt, int md5_salt_len,
char **logdetail)
{
int retval;
char crypt_pwd[MD5_PASSWD_LEN + 1];
char crypt_pwd2[MD5_PASSWD_LEN + 1];
Assert(md5_salt_len > 0);
/*
* Compute the correct answer for the MD5 challenge.
*
* We do not bother setting logdetail for any pg_md5_encrypt failure
* below: the only possible error is out-of-memory, which is unlikely, and
* if it did happen adding a psprintf call would only make things worse.
*/
switch (get_password_type(shadow_pass))
{
case PASSWORD_TYPE_MD5:
/* stored password already encrypted, only do salt */
if (!pg_md5_encrypt(shadow_pass + strlen("md5"),
md5_salt, md5_salt_len,
crypt_pwd))
{
return STATUS_ERROR;
}
break;
case PASSWORD_TYPE_PLAINTEXT:
/* stored password is plain, double-encrypt */
if (!pg_md5_encrypt(shadow_pass,
role,
strlen(role),
crypt_pwd2))
{
return STATUS_ERROR;
}
if (!pg_md5_encrypt(crypt_pwd2 + strlen("md5"),
md5_salt, md5_salt_len,
crypt_pwd))
{
return STATUS_ERROR;
}
break;
default:
/* unknown password hash format. */
*logdetail = psprintf(_("User \"%s\" has a password that cannot be used with MD5 authentication."),
role);
return STATUS_ERROR;
}
if (strcmp(client_pass, crypt_pwd) == 0)
retval = STATUS_OK;
else
{
*logdetail = psprintf(_("Password does not match for user \"%s\"."),
role);
retval = STATUS_ERROR;
}
return retval;
}
/*
* Check given password for given user, and return STATUS_OK or STATUS_ERROR.
*
* 'shadow_pass' is the user's correct password or password hash, as stored
* in pg_authid.rolpassword.
* 'client_pass' is the password given by the remote user.
*
* In the error case, optionally store a palloc'd string at *logdetail
* that will be sent to the postmaster log (but not the client).
*/
int
plain_crypt_verify(const char *role, const char *shadow_pass,
const char *client_pass,
char **logdetail)
{
char crypt_client_pass[MD5_PASSWD_LEN + 1];
/*
* Client sent password in plaintext. If we have an MD5 hash stored, hash
* the password the client sent, and compare the hashes. Otherwise
* compare the plaintext passwords directly.
*/
switch (get_password_type(shadow_pass))
{
case PASSWORD_TYPE_SCRAM:
if (scram_verify_plain_password(role,
client_pass,
shadow_pass))
{
return STATUS_OK;
}
else
{
*logdetail = psprintf(_("Password does not match for user \"%s\"."),
role);
return STATUS_ERROR;
}
break;
case PASSWORD_TYPE_MD5:
if (!pg_md5_encrypt(client_pass,
role,
strlen(role),
crypt_client_pass))
{
/*
* We do not bother setting logdetail for pg_md5_encrypt
* failure: the only possible error is out-of-memory, which is
* unlikely, and if it did happen adding a psprintf call would
* only make things worse.
*/
return STATUS_ERROR;
}
if (strcmp(crypt_client_pass, shadow_pass) == 0)
return STATUS_OK;
else
{
*logdetail = psprintf(_("Password does not match for user \"%s\"."),
role);
return STATUS_ERROR;
}
break;
case PASSWORD_TYPE_PLAINTEXT:
if (strcmp(client_pass, shadow_pass) == 0)
return STATUS_OK;
else
{
*logdetail = psprintf(_("Password does not match for user \"%s\"."),
role);
return STATUS_ERROR;
}
break;
}
/*
* This shouldn't happen. Plain "password" authentication is possible
* with any kind of stored password hash.
*/
*logdetail = psprintf(_("Password of user \"%s\" is in unrecognized format."),
role);
return STATUS_ERROR;
}