Dear List,

I'm not sure if this is the proper list for asking such a basic question,
but I'll give it a try. If it's not appropriate, please point me to a
community where this is appropriate.

My question is: What is the state of the art for storing user
authentication information, especially passwords for enterprise software
that uses standard relational databases for storing its data.

I clearly don't want to store this information in a table with columns
USERNAME and PASSWORD in plaintext, because everybody with access to the
table could get at this information.

Storing encrypted passwords in the table also doesn't solve the problem,
because simple knowledge of the master password (which has to be stored
either in the program or in a configuration file) would compromise all
accounts.

Storing naively hashed passwords makes them vulnurable to precomputed
dictionary attacks.

Adding salt to the password, hashing the salted password, and storing the
salt with the hashed password to my knowledge was the state of the art till
a few months ago, when a weekness in hash(salt+pw) was detected. Fixing
this by using something along the lines hash((hash(salt1+password)+salt2)
brings us to the state of the art.

This leaves us with the (desired?!) vulnurability that the database
administrator could temporarily copy the password hash for a known password
from account one to another account two, work under account two, and
restore it afterwards. This could be ruled out by mixing the account name
in hash((hash(salt1+account + password)+salt2). This might fix it, but in
real life, it might be necessary to leave this whole (imagine for example,
the application administrator dies and nobody knows his password, so this
might be the only way to get access to the data).

Any comments?

Carsten Kuckuk

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]