Re: sefety of passwords for web-service applications

On Sat, Nov 24, 2012 at 1:15 AM, Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)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