The False Sense of Database Security

In many web sites, passwords are usually stored in a database. I think this is well known to anybody who ever created any web page with user accounts.

Storing passwords in plain text is considered harmful. The only reason that I find is that when someone gets the access to the database, or has the database backup, the passwords are just plain text, so everyone can read them.

Quite nice solution to this problem is hashing the passwords. The database stores no the plain text passwords, but the result of some hash function.

hashed_value = HASH_FUNCTION(password);

The hash function is a one way function, so you can use it for encrypting the password. Decryption is impossible, what’s more, you could probably find many different passwords that have the same hash value. The mostly used hash function is, unfortunately still, md5(). It returns 128 bit hash value. It means that there are only 2^128 possible values… what is a quite huge number: 340,282,366,920,938,463,463,374,607,431,768,211,456. The md5 algorithm contains some flaws and currently is not so secure.

Hash functions can be “decrypted” using the rainbow tables. This is not normal decryption, so we get the original plain text password. This kind of decryption allows to find a password that gives the same hash value that we have. This can be some other text, not the one that user entered, but it will be enough for logging into a system.

This problem was partly solved using a ‘salt’, this is some random text that is added to the password before calculating the hash value. So the function now looks like:

hashed_value = HASH_FUNCTION(password + salt);

There is no decryption of the password in databases. Instead the password that user provides for logging in, is hashed using the same algorithm and the same salt, and the hash value is compared to the values stored in the database. There are some collissions, so two different strings generate the same hash value, so there is a possibility that you can login to a system using other password than user provided.

I’d like to see hash functions and salts in all the databases. Unfortunetaly the most common way of storing passwords is just plain text. Last time I forgot a password to some two huge internet shops, I asked to remind me the password, and I got that with plain text.

That’s All

That’s all, if talking about security of passwords in web applications. I’ve hardly ever found something more, usually there just the short list: use hash function, or use hash function with salt.

There is much more, usually ignored.

Database dumps.

Database dumps are not a problem as there should be the crypted passwords.

Database Logs.

Logs are something nobody secures. Assume we have hashing in a database function. Application just performs a query like:

INSERT INTO users (login, password) VALUES ('me', 'pass');

and there is a trigger that hashed the password, so in database the password is not stored with plain text. Another solution could be running a procedure that adds a user and hashes the password:

EXECUTE add_user('me', 'pass');

Then we could check the password entered by a user for logging in, with simple:

EXECUTE check_password('me', 'my_pass_for_login');

Nice, but what will be there in the database logs? If we want to log all queries, what is very usefull sometimes, then all those passwords will be stored there with plain text.

Application logs.

Applications have there own logs. The logs are stored somewhere else than the database logs, and should be secured as well. If the application stores in the logs the whole http request, then there is stored the password.

Quite nice solution to this problem exists in the Ruby on Rails framework. Having the application controller like this:

class ApplicationController < ActionController::Base
  # filter out password parameters from log files
  filter_parameter_logging :password
end

protects storing in the logs any HTTP parameter named “password”;

All the passwords can exist in the logs, even if you hash and salt your password in the database. I think that in the application that you write, everything is logged, passwords too.

One more question.

What is the sense of storing passwords in any secure way, with secure connection and so on, if after registering to a web site, I get an email with my login and password sent with plain text?

Bookmark It

Related posts:

1. PostgreSQL Wishlist PostgreSQL is a great database, in my opinion much better...
2. How to Store Application Settings Some ideas on how to store application settings in a...
3. Unit Test Your Database. I observe the endless war about TDD. On one side...
4. Django Admin Panel Weirdness Django Has ORM I’ve started clicking a small Django application....
5. Testing Database – Small Reply On Ovid’s blog I found lately this entry. First of...
6. How to Store Applications Settings part 2 Last time I’ve written about some idea on storing application...