sefety of passwords for web-service applications - Mailing list pgsql-general

From Rafal Pietrak
Subject sefety of passwords for web-service applications
Date
Msg-id 1353748540.10003.117.camel@localhost.localdomain
Whole thread Raw
Responses Re: sefety of passwords for web-service applications  (Chris Travers <chris.travers@gmail.com>)
List pgsql-general
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



pgsql-general by date:

Previous
From: Gavan Schneider
Date:
Subject: Re: ERROR: query has no destination for result data
Next
From: Chris Travers
Date:
Subject: Re: sefety of passwords for web-service applications