5

I was thinking about the recent (seemingly weekly) security breaches we've seen where millions of password hashes have been leaked and I was wondering how one might secure their site against a password dump, even if a hacker found a SQL injection vulnerability.

What if the user the website was using to log into the database had more limited permissions. Let's say on all non-critical data the user had full permissions like normal (CRUD). But what if the user was denied all CRUD operations to the table that stored the login hashes, security questions, etc, and could only run stored procedures on that table. And let's say those stored procedures never returned the password hashes to the application layer, but rather you would pass the hash to the procedure and the procedure would return a boolean value indicating whether there was a match.

It seems to me that this setup would eliminate the possibility of a password hash dump through SQL injection entirely. Does this setup provide additional security, is it advisable?

Update

Please see this question for more details:

Worthwhile from security standpoint to limit database server user for ASP.NET website to only EXECUTE on stored procedures?

Wadih M.
  • 1,102
  • 6
  • 20
John
  • 2,242
  • 2
  • 28
  • 45
  • Stored procedures still need CRUD privileges, at least under MySQL and MSSQL. – Sébastien Renauld May 10 '13 at 15:41
  • @SébastienRenauld really? Cause that would kind of blow my idea out of the water... There's gotta be another way to lock it down, no? – John May 10 '13 at 15:44
  • @SébastienRenauld it would seem that this answer http://security.stackexchange.com/a/6065/25821 describes exactly the scenario I mentioned... – John May 10 '13 at 15:51
  • Depends how you set up the SP. I just had a bit of a play locally - if you define it with a DEFINER, you can do it. See Tom's answer. – Sébastien Renauld May 10 '13 at 15:52
  • 1
    That is not correct for MS SQL Server. You can give a role execute rights on stored procedures without granting the user rights to the underlying objects. – Xander May 10 '13 at 15:55

2 Answers2

3

The scheme you describe is similar in concept to making a dedicated password verification server (local server, not open to the world at large) with its own, completely distinct database for the storage of hashed passwords. This can work. Actually you already have that under the guise of "system integration" when the user accounts are mapped, for instance, to an Active Directory server, or local Unix accounts.

Using a stored procedure in the database for that, relies on the database enforcing appropriate isolation -- a somewhat risky bet, since you are envisioning a situation where the attacker gets to include his own SQL statements.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
1

A different way of looking at the problem is assuming that the database will be compromised. If the database is compromised and the password table is obtained, how can reduce the value of the attack by making the data meaningless?

First, of course you want to use a strong cryptographic hashing algorithm (bcrypt, scrypt, etc.). You want to use a random salt to reduce the ability to use rainbow table effectively. You can also use a peppering mechanism and use separation through another server or hardware security module (HSM), without the pepper, getting anything meaningful from the hash listing will be far less likely. You can accomplish this to a lesser extent using a locked down server with only the password table present, ensuring there is proper encryption and authentication between the requesting server and your password verification server.

Community
  • 1
Eric G
  • 9,691
  • 4
  • 31
  • 58