re: Would you send a plain text password from your website to the server over a secure connection? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Didn't you read the comment? The encryption isn't to stop attacks, it's so that the sensitive information gets logged by accident on the client sid...

Still, that does not protect a dedicated attacker to do both, first extract the encryption key from the client and attacking your server. The most difficult part is the big if here as you mentioned.

And my guess is that the encryption keys aren't stored in the client, but instead sent over an HTTPS connection after the client is loaded.

That proves that the HTTPS connection is trusted and it is equally safe to send passwords.

I know that, that's why I don't encrypt passwords on the client side. But my point is that the guy you're responding to doesn't do it for security against hackers. He does it for security against himself/his team in the event that they make a mistake which starts logging data received from the client. It doesn't have to be "securely" encrypted, it just needs to be encrypted at least a little to avoid violating PCI compliance.

As in all things in InfoSec, it's all about considering what kinds of attacks you're trying to defend against. In this case, I'm not trying to protect the data as it goes across the wire - I've already got TLS for that. If my TLS is busted, then I'm pwned. It also doesn't prevent code running in the browser from knowing the public half of the ephemeral, session-bound asymmetric keypair I'm using for the extra encryption, but if the attacker already has control of the user's browser, that user (and all of their data) is pwned. I'm also not really adding anything in the event of a complete compromise of my application server - if the attacker gains control over those, then I'm completely compromised, as they can query the DB and get my encryption keys to decrypt the data stored in the DB (no need to sit and monitor my logs when they can grab the whole batch of data proactively!).

All three of those things, though, are either hard (compromising TLS, complete control over the well-protected application server) or have a very small scope (control over the individual user's browser). What I'm trying to do by layering the encryption is getting rid of some of the low-hanging fruit and side-channel attacks that an attacker might use to gain some easy data.

One example of such a side-channel: I'm hoping that all of the servers in your request-handling chain (reverse proxies, app servers, database servers) are regularly patched and subjected to vulnerability scans and penetration tests. However, when's the last time anybody pentested their log aggregation servers? The real request data isn't passing through there, so often, they're forgotten in our hardening efforts. However, if we're logging request bodies that include sensitive information, suddenly that log server becomes a valuable target for an attacker. Adding an extra layer of encryption to that one piece of data helps prevent such a compromise. And even if we're also erroneously logging out all response bodies, we're still protected, since we use asymmetric encryption and the private key never leaves the app server's memory.

Another thing that is often neglected is security against an internal attacker. We spend most of our time and effort focused on external hackers, and very little - if any - on internal attackers. I've literally heard organizations state that their internal security policy is "We trust our people." If you want to see the fallacy in this, just look at what Twitter is in the news for today (an employee on their last day deleted Trump's Twitter account). Odds are, if your handling certain types of sensitive data (like credit cards), you already have to have procedures in place to prevent an internal attacker from getting to the main datastore (separating access to the database from access to the data-at-rest encryption keys, ensuring dual-control on both, etc.). However, have you locked down your log aggregation server with the same kinds of controls? Or, if you don't have one, are there people who have access to the server to view logs that don't have access to the database and the data-at-rest encryption keys?

To put it simply: there's no such thing as perfect security. There's just throwing up enough walls that the attacker moves on to easier prey.

I will say that I do not recommend that most people add extra encryption beyond TLS to most of their data. The false sense of security it could provide if you tried to use it everywhere might just be more damaging than not doing it at all. However, for high-value pieces of data, it could enhance security. I don't even think anyone should encrypt their entire request body, just the one extra-sensitive field.

Cool. Doesn't the PCI compliance require regular Pen tests and no storage of credit card information though?

It doesn't require "no storage" (at least, not of the PAN), just that we protect the storage (requirement 3.4 of PCI-DSS 3.2), which includes within log files. This strategy helps us achieve that. I was, however, trying to talk about a broader scope than just PCI, even if that's the specific case that I'm dealing with, hence the hoping that people are actually doing pen tests. Even within PCI, though, I wonder how many auditors have checked the pen test records for the log servers, as opposed to just checking them for the app servers and DBs. I don't trust my auditors to make my system secure any more than they trust me :).

When we had a pa dss audit every server had it's hard drive cloned and checked for anything matching the luhn algorithm. Lots of false positives but your solution seems like an excellent precaution.

code of conduct - report abuse