Hrm. Ok. This is assuming I've compromised the database client side, right? Doesn't the client have to know 'k' to do the query? k is $indexKey, right?

Edit: Thanks, got it now. A database dump on it's own gives nothing useful. The client side is vulnerable, but has to be since it's ultimately serving up plaintext SSNs anyway.

This is assuming that:

  - The webserver and database server are on separate bare-metal
  - The database gets compromised, not the webserver

Very big assumptions, vector of attacks tend to begin at the webserver more so than the DB. Sometimes, these DB dumps we hear off occurred over HTTP!

Right, but if you can compromise the webserver, you can get the key and defeat any application-layer encryption a PHP developer would have access to, thereby rendering any other threat models uninterestingly broken.

If you can keep the webserver secure, and on separate hardware from the database, you can protect against some attacks rather than no attacks. And if your database server is used by multiple verticals within a single company, this is an even more defensible design decision to make.

Ah, the multiple verticals angle is where this starts to make sense to me. This app might be well-secured, but the dept next door might have something worse, but this way if the DB's compromised via theirs, the data's safe, I guess?

Right, so if you are rolling your own, even better is to have an API that sits between the web server and the DB and handles the decrypting and encryption. In that middleware you can now add things such as rate limiting of data requests, logging, authorization, etc.

Seems fair enough to me, though the article could do with a lead-in that explains what's being protected, the premise that the database server is a separate machine, etc.

Protecting the client side would be a completely different approach. Outboard/upstream tokenization or something. If it's directly serving up the sensitive data, there's no real way to leverage encryption for protection there.

> Seems fair enough to me, though the article could do with a lead-in that explains what's being protected, the premise that the database server is a separate machine, etc.

Okay, I've added a section that spells this out explicitly and unambiguously. https://paragonie.com/blog/2017/05/building-searchable-encry...