Re: [HACKERS] A stab at implementing better password hashing, with mixed results

2012-12-28 Thread Alastair Turner
On Thu, Dec 27, 2012 at 5:39 PM, Peter Bex peter@xs4all.nl wrote:
 On Thu, Dec 27, 2012 at 12:31:08PM -0300, Claudio Freire wrote:
 On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex peter@xs4all.nl wrote:
 
  Implementing a more secure challenge-response based algorithm means
  a change in the client-server protocol.  Perhaps something like SCRAM
  (maybe through SASL) really is the way forward for this, but that
  seems like quite a project and it seems to dictate how the passwords are
  stored; it requires a hash of the PBKDF2 algorithm to be stored.

 It would be nonsense to do it in any other way... protecting the
 password store and not the exchange would just shift the weak spot.

 Yeah, that's why I was being rather pessimistic about the patch I posted.
 However, SCRAM will only protect the password; SSL is still required
 to protect against connection hijacking.

The thread that ended with
http://archives.postgresql.org/message-id/5086cb7a.5040...@gmx.net
also tended towards SASL and SCRAM as the best direction for
developing password and GSSAPI/Kerberos authentication.


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


[HACKERS] A stab at implementing better password hashing, with mixed results

2012-12-27 Thread Peter Bex
Hello all,

A while ago, on pgsql-general, I raised the issue that the password
storage employed by postgres is a little weak and promised I'd look
into this during the holidays, so here are my findings.

Implementing bcrypt instead of md5 is indeed rather straightforward;
just move the pgcrypto blowfish code into Postgres and tweak a few
things.  However, there seems to be no way to get the md5-based
authentication working with any different kind of storage than
plaintext or the existing md5 storage because it requires access
to the salted MD5 password hash.  Backwards compatibility can
only be guaranteed for passwords using this storage.  Adding bcrypt
means (oddly enough) that the authentication system will become *less*
secure, requiring plaintext password logins, making SSL mandatory.
However, since the existing authentication is not terribly secure
anyway that may not be considered a big loss (except maybe for
passwords popping up in accidental local network data dumps..).

Implementing a more secure challenge-response based algorithm means
a change in the client-server protocol.  Perhaps something like SCRAM
(maybe through SASL) really is the way forward for this, but that
seems like quite a project and it seems to dictate how the passwords are
stored; it requires a hash of the PBKDF2 algorithm to be stored.

One problem with a better algorithm is that for CGI-like web scripts,
connection speed is important.  The CGI model (which is also employed
by Perl and PHP, AFAIK) is in direct opposition to the security
requirement that password hashes should take long to create or verify;
if it takes long, this is a constant extra factor for all web requests
(unless advanced connection pooling is used, perhaps).  The
authentication method may also have an impact if it needs expensive
calculations.

I'm unsure how useful this bcrypt patch is, since it won't be acceptable
as-is, but I've attached it just in case.  If it is decided that this
should be integrated after all, it needs more work:

- There's no way to specify which hashing system to use for new
   passwords; I've ripped out the md5 hashing.  I think this requires
   a change in the user management statements.
- There's no way to specify (the log 2 of) the number of rounds to
   run the blowfish algorithm.  This is extremely important as it
   directly impacts the time it takes to set up a connection, like
   I said above, and some admins might like to increase the work
   factor for increased password protection.
   I think this might be a run-time server variable and/or possibly
   an option in the user management statement.
- Ideally, pgcrypto could re-use this, so that there is no duplicate
   copy of the bcrypt code.  The salt generation is less strong than
   pgcrypto's, which uses openssl AFAICT, so that might need some extra
   hooks.  The crypt code could also be exposed as an SQL function.
- Currently, if a client uses md5 auth to connect as a user who has
   a bcrypted password it simply means the correct password will be
   rejected.  There's no clean way to handle this, as far as I can see;
   giving more feedback will probably require a change in the protocol
   and will give away more information than we want: you'll know a user
   exists and even that the password isn't stored in plaintext or md5.

The conclusion is that switching to bcrypt requires a handful of extra
changes that I don't know how to make, and has the consequence of
*requiring* plaintext password authentication or a change in the
protocol.  If it's decided to go forward with this anyway, I'm willing
to help out, but implementing a completely new authentication system
goes a little over my head, I'm afraid.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music.
-- Donald Knuth
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index 569385c..c50268c 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -28,6 +28,7 @@
 #include commands/seclabel.h
 #include commands/user.h
 #include libpq/md5.h
+#include libpq/crypt-blowfish.h
 #include miscadmin.h
 #include storage/lmgr.h
 #include utils/acl.h
@@ -79,8 +80,10 @@ CreateRole(CreateRoleStmt *stmt)
ListCell   *item;
ListCell   *option;
char   *password = NULL;/* user password */
-   boolencrypt_password = Password_encryption; /* encrypt 
password? */
-   charencrypted_password[MD5_PASSWD_LEN + 1];
+   boolencrypt_password = Password_encryption; /* encrypt 
(hash) password? */
+   charsalt[16];
+   charbcrypt_setting[BCRYPT_SALT_LEN + 1];
+   char

Re: [HACKERS] A stab at implementing better password hashing, with mixed results

2012-12-27 Thread Claudio Freire
On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex peter@xs4all.nl wrote:

 Implementing a more secure challenge-response based algorithm means
 a change in the client-server protocol.  Perhaps something like SCRAM
 (maybe through SASL) really is the way forward for this, but that
 seems like quite a project and it seems to dictate how the passwords are
 stored; it requires a hash of the PBKDF2 algorithm to be stored.

It would be nonsense to do it in any other way... protecting the
password store and not the exchange would just shift the weak spot.


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


Re: [HACKERS] A stab at implementing better password hashing, with mixed results

2012-12-27 Thread Peter Bex
On Thu, Dec 27, 2012 at 12:31:08PM -0300, Claudio Freire wrote:
 On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex peter@xs4all.nl wrote:
 
  Implementing a more secure challenge-response based algorithm means
  a change in the client-server protocol.  Perhaps something like SCRAM
  (maybe through SASL) really is the way forward for this, but that
  seems like quite a project and it seems to dictate how the passwords are
  stored; it requires a hash of the PBKDF2 algorithm to be stored.
 
 It would be nonsense to do it in any other way... protecting the
 password store and not the exchange would just shift the weak spot.

Yeah, that's why I was being rather pessimistic about the patch I posted.
However, SCRAM will only protect the password; SSL is still required
to protect against connection hijacking.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music.
-- Donald Knuth


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