For all the hassle it brings, why isn't password management handled by the database?

Question

Right now, we might do something like password varchar(72), when defining a password column, with for example BCrypt. But there's a lot of folks that don't do this very effectively. Maybe they just put the plaintext, or a single unsalted md5 hash, or some other terrible strategy.

But virtually all these offenders still use databases. So why isn't this kind of functionality baked into databases? Something like mypass password('BCrypt:10'), and accessed like INSERT INTO people(name, mypass, other_data) VALUES(?, ?, ?) which would take the plaintext password from the user and pass it to the table. But the table would store the appropriate BCrypt hash value. Then, we could do something like SELECT other_data FROM people WHERE name = ? AND mypass = ? - this again would take the plaintext from the user logging in, but load the salt and perform the analysis to determine of the the password was a success or not.

When it comes to storing data, we go with databases instead of flat files or what have you because they're reliable, tested, and simple (in comparison to rolling our own). Since it's clear that in the wild there are innumerable where password storage is unreliable and untested, why is this sort of data storage not undertaken by the database itself?

Answer 1

It would be possible but:

• It's not standard SQL (it would have to become a feature, part of the product)
• All processing power will be centralized on the database
• Not all webapplications use SQL databases

You're just shifting the problem, 10 years ago it would have been acceptable to use MD5+salt. So your database would implement MD5+salt right? Alright 10 years later, you as a developer need to use password again hashing on database level, now the database supports bcrypt, but you still will use MD5+salt because it's what you know right?

Why does it still need to support MD5+salt you might ask? Simply because you are probably still using the same application. The migration to the new scheme will still require developer intevervention, it won't happen auto-magically.

Making it a feature to just use an automatic password hashing algorithm isn't possible because you will have implemented an older scheme for older applications. This would then require the database product to suddenly implement an auto-migration feature. This is complex to implement.

So you can see, the problem shifts from it being a developer issue to a database developer issue.

Answer 2

There's several reasons:

• You'd need to modify the query planner to understand the column types, as you'd have to select the username, read the salt, and then handle the password hash.
• You're adding additional load to the database, which is often the hot spot in applications, for work that can just as easily be done in the application.
• You'd need a way to upgrade hash types -- so is that a database schema modification?

If someone doesn't know how to write an application, giving them a "magic" database column isn't going to fix the problem.

Answer 3

Nice question! Very honestly my take is "because nobody did it". There probably isn't much of a market for it in the eyes of database developers since the website developers who are not stupid already have their own code.

This being said, it's a very good idea to place security code (sanitisation, secret storage, declassification...) in ready-made libraries rather than on the client side because it means there is now one place where it needs to be done properly instead of tens of thousands; so long of course as your database library is transparent about how passwords are being salted and hashed and offers reasonable defaults and customisation options to developers.

Editing after seeing others' answers: doing so within the DB server itself could cause more performance issues than on the front-end side because DB's are less scalable than front-ends; it also means that you keep the "boiling potato" longer since your clear-text password travels around from your front-end server to your database.

However, I still don't see how a client library to a database couldn't receive a password as a data type and convert it into something hashed and salted itself. It would still need some form of cleartext password cache to automatically handle hash function updates though (but that'd have been the case anyway in the same front-end process that would run the library's code).

Answer 4

People do all kinds of stupid things. That doesn't mean we should take everything that might go wrong in the application and delegate it to the database system.

The job of a database system is to manage data. Of course modern systems have all kinds of additional features which blur the line between application and database. But expecting them to handle the user authentication of your website seems a bit over the top. That's the job of the application.

Passing the plaintext password to the database system also has implications for security: You now have to make sure that the password doesn't turn up in the query log or get intercepted on the way from the webserver to the database system (unless they're on the same machine).