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?


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?

  • Stored procedures still need CRUD privileges, at least under MySQL and MSSQL. Commented May 10, 2013 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
    Commented May 10, 2013 at 15:44
  • @SébastienRenauld it would seem that this answer security.stackexchange.com/a/6065/25821 describes exactly the scenario I mentioned...
    – John
    Commented May 10, 2013 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. Commented May 10, 2013 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
    Commented May 10, 2013 at 15:55

2 Answers 2


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.

  • Can you point out any tutorials for setting up a dedicated password server for asp.net?
    – John
    Commented May 10, 2013 at 19:21
  • what do you mean by "dedicated password verification server"?
    – John
    Commented May 15, 2013 at 15:58
  • A server which receives requests of the type "I got this password for this user name, is it OK ?", and sends answers "yes" or "no".
    – Tom Leek
    Commented May 17, 2013 at 17:38
  • That's what I thought you meant. Any examples / products that do this?
    – John
    Commented May 17, 2013 at 17:40

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .