2

I'm currently implementing as much security into a web app as possible, but I can't stop thinking about the database itself. For all the security I implement, such as salting and hashing passwords in the users table, if hackers manage to download the database entirely (by getting access to the server for example), they'll be able to see all the data in the entire database?

I've been reading about all the database breaches of well-known brands within the past couple of years, and that these databases are for sale on the dark web.

I understand hashing passwords will slow down / stop hackers having access to plain text login credentials that may be the same for other websites the user has signed up to, but my question is, what about the personal information stored in the database that isn't hashed. Like which products you've bought over the past couple of years, or your employment history, or your contacts, or something really embarrassing such as which adult websites you've visited and/or bookmarked.

Considering you can't hash a user's email address if it's being used as part of the login credentials, some hacker could query the database using the userID for example, get personal information from other tables, and then send a blackmail email to that user.

The two potential solutions I can think of are:

  1. Encrypt as much of the information in the database as possible - but can't encrypt it all otherwise we wouldn't be able to perform quick insight queries on our user base for example.

  2. Encrypt the actual database file itself on the server, so if it were downloaded, they wouldn't be able to have access without knowing the key.

So, 1 isn't much of a solution because I can't encrypt everything. And would 2 actually work i.e. would a web app using django for example be able to write to the database if its root file on the server was an encrypted file? I know MS SQL Server has an always-encrypted feature, but I'm using MySQL.

Sorry for the essay-length question - my head is spinning with all sorts of possibilities, and it's driving me nuts!

Thank you!

0

There are two concepts at play here:

  1. Data at rest
  2. Data in motion

Data at rest

As you correctly noted, if someone gets access to your database and the data itself is not encrypted, then hashing and salting passwords makes no difference.

  1. Encrypt the actual database file itself on the server, so if it were downloaded, they wouldn't be able to have access without knowing the key.

You should enable on-disk encryption in some way or form. SQL Server offers Transparent Data Encryption (TDE), where as soon as data leaves memory and is persisted to storage, it is encrypted. This is called "encryption at rest".

This feature may not be available in your RDBMS, so you might rely on the storage vendor's on-disk encryption. Otherwise, you can investigate file-system level encryption.

The important thing is to keep the database administrators away from the encryption keys, and to ensure that database backups are handled with the same security considerations as the database server.

Data in motion

As for your question around applications having access to encrypted data, this is handled differently. I'll return again to SQL Server because that's what I know.

  1. Encrypt as much of the information in the database as possible - but can't encrypt it all otherwise we wouldn't be able to perform quick insight queries on our user base for example.

The application uses a certificate to connect to the server, so that only it can see the data it has access to. It's called Always Encrypted, and unless someone has that certificate, the data remains inaccessible.


The database server you end up using should take these two concepts into account. Here's the documentation for SQL Server, but the other more established players should have similar features.

0

Simple passwords are crackable. Read about "dictionary password cracking". Hackers have them -- they take the passwords in your system, look them up, and voila, there's the plaintext. This is why everyone admonishes you to use upper and lowercase, digits, and punctuation. And >= 8 characters. A 'dictionary' to handle that many possibilities is impractical.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.