

0 / 2 embers
0 / 3000 xp
click for more info
Complete a lesson to start your streak
click for more info
Still calibrating
click for more info
Not enough gems
Cost: 6 gems
1: Encrypting Data at Rest
incomplete
2: Key Management and Rotation
incomplete
3: Password KDFs
incomplete
4: Salts
incomplete
5: Argon2 Parameters
incomplete
6: Encrypted Files
incomplete
7: Secure Database Practices
incomplete
8: Personally Identifiable Information
incomplete
9: Financial Data
incomplete
Back
ctrl+,
Next
ctrl+.
This lesson's interactive features are locked, please to keep using them
Personally identifiable information (PII) identifies or can be linked to a real person. Names, email addresses, street addresses, and uploaded document names can all qualify.
The thing about PII is that it's useful to attackers even outside your application. It can fuel phishing, identity theft, stalking, account recovery attacks, and social engineering. Unlike a password or API key, a person can't exactly rotate their home address or SSN after a breach.
Identifiers like userId, orderId, and uploadedFileId usually provide enough context to investigate an event without copying the customer's email, shipping address, or filename into your logs.
For example, this event keeps its diagnostic value:
{
"event": "checkout_completed",
"userId": 42,
"orderId": 108,
"totalCents": 2499,
"shippingAddress": "[REDACTED]"
}
An authorized employee can use the IDs to retrieve the relevant record through a controlled system, but an attacker who steals just the log doesn't get the customer's identity or address.
These IDs are pseudonymous, not truly anonymous. Anyone with access to the application database can probably still connect them back to a person.
Bearly Secure already routes shipping details through an intentionally insecure storage transform and writes unnecessary PII to its logs. Encrypt those shipping details and extend the centralized redaction policy.
With Bearly Secure still running, run and submit the CLI tests from the project root.