Thread: sefety of passwords for web-service applications
Hello, I'm analysing a way to avoid one of the password attack vectors for web services, which goes like this: 1. acquire passwords database (assuming passwords are hashed) 2. run cracking software on the hashes as long as you like. Obviously the attack is more difficult if the step-1 is made as difficult as possible. But current implementations of majority of web-services don't rely on user/password infrastructure provided by the database (which require database superuser privileges to retrieve the whole list), instead they keep passwords in a per-application table, which entire content is available to the web-serwer (or web-application) using its own priveleges. Some improvement in passwords safety could be gained, if the database table access methods (e.g. SELECT...) provided means to limit that access to just one entry at a time, and return results only when (password) column hash was equal for a single entry. e.g. information is not leaking when password dont' match. But, apart from writing a 'SECURITY DEFINER' function to access passwords table like that, I cannot find out any other way to implement such access limitations. And I don't really like to do a FUNCTION, since I regard outputs of functions as being poor for table joins. Also, I'm really looking for a way to setup such passwords safety without changeing an application - the goal is to just just change the database, for it to protect itself. The solution should be such, that database table/functions structure exposed to the application would not change. Consequently I started laying out "feature requirement": What a "good" implementation of such feature within the database engine would be? I came to the conclusion, that a database needs a new kind of an index for "like passwords" columns; one which would be different from other indices in that: 1. planner wouldn't be allowed to seq-scan if that index is preset 2. the index would return a miss, unless it hits a single entry, and with equality. 3. pg_dump (so, probably the database superuser) should be able to select all entries. But may be there is already a way to put such passwords safety into the database, but I just don't know better. I'd be glad to hear other ideas. thenx, -R
On Sat, Nov 24, 2012 at 1:15 AM, Rafal Pietrak <rafal@zorro.isa-geek.com> wrote:
Hello,
I'm analysing a way to avoid one of the password attack vectors for web
services, which goes like this:
1. acquire passwords database (assuming passwords are hashed)
2. run cracking software on the hashes as long as you like.
Obviously the attack is more difficult if the step-1 is made as
difficult as possible.
But current implementations of majority of web-services don't rely on
user/password infrastructure provided by the database (which require
database superuser privileges to retrieve the whole list), instead they
keep passwords in a per-application table, which entire content is
available to the web-serwer (or web-application) using its own
priveleges.
There are two things going to the db-managed infrastructure instead of the per-app infrasturcture gets you:
1) As you note, the list of passwords is harder to obtain, but much more importantly,
2) PostgreSQL allows you to move this authentication to a secondary service like Kerberos, LDAP, or anything PAM supported. This means that if you want to you can use a dedicated password store for the passwords which is not accessible inside your database at all.
Some improvement in passwords safety could be gained, if the database
table access methods (e.g. SELECT...) provided means to limit that
access to just one entry at a time, and return results only when
(password) column hash was equal for a single entry. e.g. information is
not leaking when password dont' match.
But, apart from writing a 'SECURITY DEFINER' function to access
passwords table like that, I cannot find out any other way to implement
such access limitations. And I don't really like to do a FUNCTION, since
I regard outputs of functions as being poor for table joins.
If it is always going to return one row, you shouldn't have the join performance issues you describe here since you can return the row type and the planner should know it is always exactly one record. It is still an optimization fence, but not as much of one. You can also specify row estimates in terms of results for the planner to use. There is another way too, which is to think about things in terms of table methods. This would borrow a line from the etc/shadow file. If all you are doing is authenticating a user, then you only need to return a single row and probably rarely if ever need to join it, and so a function is sufficient.
Also, I'm really looking for a way to setup such passwords safety
without changeing an application - the goal is to just just change the
database, for it to protect itself. The solution should be such, that
database table/functions structure exposed to the application would not
change.
I think the closest you can come are the new security barriers in views.
Best Wishes,
Chris Travers
On 11/24/2012 10:15 AM, Rafal Pietrak wrote: > Some improvement in passwords safety could be gained, if the database > table access methods (e.g. SELECT...) provided means to limit that > access to just one entry at a time, and return results only when > (password) column hash was equal for a single entry. e.g. information is > not leaking when password dont' match. But what about situations where the attackers gained access to the database itself or faulty discs that got replaced? Isn't just having a strong hash a better solution? And by strong I mean a bcrypt based or similar approach that requires significant time to calculate a single hash. -- .oO V Oo. Work Hard, Increase Production, Prevent Accidents, and Be Happy! ;)
On Sat, 24 Nov 2012 11:05:38 +0100 "Vlad K." <vlad@haronmedia.com> wrote: > > On 11/24/2012 10:15 AM, Rafal Pietrak wrote: > > Some improvement in passwords safety could be gained, if the database > > table access methods (e.g. SELECT...) provided means to limit that > > access to just one entry at a time, and return results only when > > (password) column hash was equal for a single entry. e.g. information is > > not leaking when password dont' match. > > But what about situations where the attackers gained access to the > database itself or faulty discs that got replaced? Isn't just having a > strong hash a better solution? And by strong I mean a bcrypt based or > similar approach that requires significant time to calculate a single hash. The best defense from this kind of attack is PKI. The client generates a key pair and installs the public key in the application database, keeping the private key to use for auth. Of course, this requires a level of technical knowledge beyond what most users posses, which is a damn shame. -- Bill Moran <wmoran@potentialtech.com>
On Sat, 2012-11-24 at 01:41 -0800, Chris Travers wrote: [-----------------] > I think the closest you can come are the new security barriers in > views. Yes. This is actually what I'm currently thinking to use. A security definer function, invoked within a WITH clausure of a VIEW. -R