Can You Keep a Secret?

Three may keep a secret, if two of them are dead.

– Benjamin Franklin

Most applications handle several kinds of secrets:

• Passwords

• API keys

• Credit card numbers

• Social Security numbers

• The lat/long coordinates where you buried that treasure

Most of those are obvious, but less-obvious data also needs careful handling:

• Account numbers

• The existence of other application users

• Internal architectural details

• Personally identifiable information (PII) such as names, addresses, phone numbers, and even client IP addresses

• Sensitive business information such as special pricing, custom contracts, or internal project names

But just because information is "private" doesn't mean it's all equally private or should be treated the same way.

The type of sensitive data determines how carefully we handle it. For passwords, best practice is to never store plaintext passwords and to store cryptographic hashes instead. That way, stolen hashes still can't be used directly for login.

It would be ridiculous to apply the same technique to obscuring account numbers, or the fact that you have a database table called project_gondor, which references a new, secret feature you'll be releasing next month.

There's a balance to be struck:

• We want useful data to be as accessible as possible.

• We want private data to remain private.

These goals often conflict, so you need judgment about how to handle each type of information. Let's talk about how common security and privacy techniques apply to logging.