3

I am designing a web application at the moment, and one of the requirements is to secure the user credentials as well as their roles.

Now of course, besides the usual password hashing + salt +.... I was thinking of putting those specific tables in an encrypted H2 database, and the rest of the data in a MySQL db. The advantages of H2 in my case are:

  • in-memory storage (so means faster access)
  • encrypted db (so an additional layer of security in case the server gets compromised)

is this a common practice when an additional security layer is demanded? meaning is it a good idea to separate the login info (in my case, it is the sensitive data) from the other data?

3
  • Just a comment about password hash + salt. It is better to put the salt in front when you hash, i.e. H(salt + pw) instead of H(pw + salt). Oh, and you need to take care of synchronization of these two DBs in your design too.
    – Nam Nguyen
    Sep 12, 2011 at 12:43
  • 1
    @Elio: you should as well double check that the data once in the in memory database can be audited in case needed, this is especially since the data once in memory can't really be controlled
    – smiley
    Sep 12, 2011 at 17:56
  • I think you have the salt and password order backwards. If you put the hash first an attacker can precompute a rainbow table that effectively eliminates the hash. That doesn't happen if you put it at the end. In either case with modern cracking hardware you should be hashing (with salt) multiple rounds. I wouldn't do it 1000 times for the typical webapp but a dozen times wouldn't be unreasonable.
    – bgiles
    Jul 13, 2015 at 16:06

1 Answer 1

4

Encryption of the database prevents low level file based access to the database evading the database permission system. This is especial useful, if it is likely that an attacker gets physical access to the computer (think of stolen notebooks).

On servers it has the issue on what do to with the key/password. If you store it outside the encryption, you make it easy for the attacker to access it. But not storing it requires manual interaction on a server restart which is often not desirable for availability reasons.

Encryption of the database does not help against an attacker who can leverage an web-application that has permission to access the database via SQL-injection.

Having a second database, especially a second database software increases the attack surface: You are vulnerable to the union set of bugs of MySQL and H2. And you need people who understand both systems to operate it securely.

There is one advantage through: There is only very little code that accesses the authentication information. SQL-injection vulnerabilities in the huge majority of the code will not be able to access to the isolated authentication information.

At my workplace we did this for our web application instead: We use different database connections depending on the role of the user doing the requests. So an anonymous users for example gets a database connection which has very little database permissions.

4
  • 1
    I like your solution, plus its less of a hassle then maintaining 2 db engines.
    – Elio
    Sep 12, 2011 at 10:18
  • 1
    How did you then deal with data replication between the two databases? I Think that can be a show stopper in case not solved from the design phase!
    – smiley
    Sep 12, 2011 at 11:32
  • @smiley We don't use two databases (well we can access legacy databases, but that is another topic) Sep 12, 2011 at 11:46
  • 1
    @Smiley I must admit I didn't research too much about the data replication methods, as I already worked on SymmetricDS previously and it wasnt bad.
    – Elio
    Sep 12, 2011 at 11:51

You must log in to answer this question.

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