Live data from Hacker News

Building Searchable Encrypted Databases with PHP and SQL

paragonie.com

21–30 of 33 posts

Re: Building Searchable Encrypted Databases with PHP and SQL

#21

Earlier quoted context omitted.

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.

Re: Building Searchable Encrypted Databases with PHP and SQL

#22

Earlier quoted context omitted.

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!

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.

Re: Building Searchable Encrypted Databases with PHP and SQL

#23
post #12

Can someone explain why it's not simple to brute force the hash in the blind index? Since SSNs only have 9 digits, that's a billion possibilities. Is this just a hash that's too slow to iterate over the billion? Is each row salted differently? Edit: I'm asking because I don't know, not because I'm saying it's possible. Edit2: Also, it appears there was a pattern to SSN issuance prior to 2011, so the problem space may…

HMAC is a keyed hash which renders simple brute force attacks ineffective unless the attacker is also able to compromise the key.

Even without the key the system is still vulnerable to frequency analysis. For example if it were used to store passwords an simple sort and count would reveal accounts that have common passwords which could then be brute forced using lists of the most common passwords found on the internet. The suggestion of using blind indexes for searching on partial values (i.e. the first letter of a name) would increase the vulnerability.

Even if the attacker doesn't have access to the key if the application is fast enough he may be able to brute force it by passing every possible value and seeing how it encrypts if the search space is small enough (i.e. common passwords).

Secure key storage is always a challenge and the suggestion that the key is stored on the application server instead of the database has some practical problems. The key in many cases will end up being duplicated in code repositories or build scripts which increases your vulnerability to internal attackers. A better system stored half the key on the database server and the other half on the application server which are then XOR'd to get the encryption keys which can reduce the number of potential internal attackers that could recover the plaintext.

Also when recovering from an attack in many cases it may be difficult or impossible to know how many systems were compromised. Without the ability to prove that both the data and the key weren't compromised in an attack an auditor may require that you operate on the assumption that the data was compromised with associated requirements for notification and penalties.

Banks long ago solved the problem of secure key storage with the use of hardware security modules (HSMs) where the key is stored and used on a secure, tamper proof device. This turned the problem of secure key storage into a problem of physical security which the banks were already good at rather than digital security. Where is my key? My key is right here.

These modules are now becoming more commonly used in the ecommerce space (AWS now provides them, for example) but they are still fairly difficult to work with. Some shops will used hardened/audited servers that run encryption/decryption micro-services instead.

Re: Building Searchable Encrypted Databases with PHP and SQL

#24
post #22

Earlier quoted context omitted.

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!

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...

Re: Building Searchable Encrypted Databases with PHP and SQL

#27
post #23
post #12

Can someone explain why it's not simple to brute force the hash in the blind index? Since SSNs only have 9 digits, that's a billion possibilities. Is this just a hash that's too slow to iterate over the billion? Is each row salted differently? Edit: I'm asking because I don't know, not because I'm saying it's possible. Edit2: Also, it appears there was a pattern to SSN issuance prior to 2011, so the problem space may…

HMAC is a keyed hash which renders simple brute force attacks ineffective unless the attacker is also able to compromise the key. Even without the key the system is still vulnerable to frequency analysis. For example if it were used to store passwords an simple sort and count would reveal accounts that have common passwords which could then be brute forced using lists of the most common passwords found on the interne…

> Even without the key the system is still vulnerable to frequency analysis. For example if it were used to store passwords an simple sort and count would reveal accounts that have common passwords which could then be brute forced using lists of the most common passwords found on the internet.

I would hope, very strongly, that nobody would encrypt passwords, but instead, hash them: https://paragonie.com/blog/2016/02/how-safely-store-password...

Re: Building Searchable Encrypted Databases with PHP and SQL

#28
post #26

I agree that the HMAC approach is better but a proper deterministic encryption would work just fine, wouldn't it? You're comparing your method with ECB mode which is a bit unfair.

What are some constructions you'd consider "fair"?

Re: Building Searchable Encrypted Databases with PHP and SQL

#29

Earlier quoted context omitted.

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 wi…

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?

Re: Building Searchable Encrypted Databases with PHP and SQL

#30
post #26

I agree that the HMAC approach is better but a proper deterministic encryption would work just fine, wouldn't it? You're comparing your method with ECB mode which is a bit unfair.

What are some constructions you'd consider "fair"?

AEAD cipher with nonce generated from plaintext? That would have equivalent security properties except for being needlessly complicated?
Post reply on HN