1. Protecting Sensitive Data: From Passwords to PANs
Tyler Moore
CS 7403
University of Tulsa

2. Agenda Password security Credit card data security
What data to store and how (encryption, hashing, salts, oh my)
Credit card data security
Who stores what and how (encryption, hashing, salts, and tokenization)

3. Recall: session login NetworkAttacker Auth Request Check uid,pw Client
Webserver DB
POST uid,pw
Return auth. succ/fail
Set sess. tok.
CSRF,XSS, etc.
Web Attacker
BackendAttacker

4. Data in transit vs. data at rest
Passwords sent from client to server, server to authentication DB
SSL/TLS is effective encryption for data in transit
Data “at rest”
How does the authentication DB know your password?
It has to store some sensitive data, possibly even the password itself
Technologies can minimize exposure of this data to attackers

5. How to store a password In cleartext on a backend database
Works so long as the DB system is perfectly configured and otherwise unbreakable
In practice, terrible idea (see RockYou data breach)
Encrypted using a secret key known only to the server admin
Better than option 1: leaking the database doesn’t automatically leak the passwords
Still terrible because key compromise can reverse encryption and identify the plaintext passwords
Question: is there any valid reason a website should know the plaintext of your password?

6. How to store a password Store a one-way hash of the password
Cryptographic hash functions such as SHA can turn a password into a jumble of text that cannot be reversed back into the password
But hashes can verify a password is valid by re-computing the hash and comparing to the stored value
Key insight: websites don’t actually need to know what your password is; they only need to know it is valid

7. But there is a problem
Password hashes remains vulnerable to an offline dictionary attack
Suppose a backend attacker gets a copy of the database containing usernames and password hashes
She can then compute hashes of common passwords to look for a match
Fortunately, there is an easy solution: salts!
Unfortunately, many websites don’t use salts and then get hacked (e.g., Gawker, Sony, LinkedIn)

8. 4. Store a Salted Hash of Password
Instead of hashing the password directly, prepend the password with a random sequence
Store the plaintext salt in the DB alongside hash
What is a good salt?
Long enough to prevent attacker from building lookup table
As long as the hash value (e.g., 32 bytes for SHA256)
Generated by a cryptographically random source
Used only once per password
Unconnected to the user (i.e., don’t make the salt the user’s first name)
See:

9. Password Security Additional risks to passwords
User selected so often guessable
Susceptible to phishing, keylogging
Online guessing attacks

10. From Passwords to PANs
Passwords are far from the only sensitive information that attackers steal
Social Security #s
PANs (i.e., credit card #s)
Personally-Identifiable Information
The solutions are similar to those suggested for passwords, but they sometimes face different constraints

11. Payments Threat Models
NetworkAttacker
Auth req: PAN,CVV,amt
Terminal or
Browser
Merchant
Issuer/Card Network
PAN,CVV,exp
Return auth. succ/fail
Web Attacker
BackendAttacker

12. From Passwords to PANs
Recall that we could identify no good reason for a website to store plaintext passwords
Question: can you name any reasons why anyone would need access to plaintext PANs?
1) Issuer needs to be able to check validity of presented PAN, 2) Merchant needs to reissue a refund to the card that was used for purchase, 3) merchant would like to link multiple transactions by the same customer

13. PCI DSS
Recall that PCI DSS sets rules for anyone handling payment card data
PCI decides which bits of the IT infrastructure are “in scope” for compliance requirements
Any system transmitting payment card data is in scope and must be encrypted
Any system storing plaintext PANs at rest is in scope
Encrypted PANs at rest still in PCI scope because they can be decrypted by anyone with a key
Hashed PANs not in scope since irreversible

14. One key difference between PANs and passwords
Passwords are always secret
Used to authenticate user
Associated with separate, non-secret user ID that identifies the user
PANs operate as both a unique identifier and authenticator
If you only store the hash, how do you link back when next presented?

15. Issuer Encryption Issuer 2. {PAN,CVV, exp, amt} enc. w/ SSL Mer.-Iss.
{PAN}Kissuer
IVPAN
Exp.
ZIP
Name
Limit
F34D
8A98
12/17
74104
Joe
10000
9B32
142B
4/18
74114
Jane
8000
435E
924C
6/19
74011
Jim
5000
2. {PAN,CVV, exp, amt} enc. w/ SSL Mer.-Iss.
3. Authorization
Merchant
UID
Order
Auth.
Date
Name
Abc
123
DFWE
Joe
1. {PAN,CVV, exp, amt} enc. w/ SSL Br.-Mer.
Browser

16. Merchant PAN Encryption at Rest
Issuer
{PAN}Kissuer
IVPAN
Exp.
ZIP
Name
Limit
F34D
8A98
12/17
74104
Joe
10000
9B32
142B
4/18
74114
Jane
8000
435E
924C
6/19
74011
Jim
5000
2. {PAN,CVV, exp, amt} enc. w/ SSL Mer.-Iss.
3. Authorization
Merchant
UID
Order
Auth.
Date
Name
{PAN}Kmerchant
IVPAN
Abc
123
DFWE
Joe
E07B
B3B1
1. {PAN,CVV, exp, amt} enc. w/ SSL Br.-Mer.
Browser

17. Symmetric Encryption for PANs
PAN entries in database can be encrypted using symmetric key encryption
AES preferred
Cipher Feedback (CFB) mode requires no padding
Must select Initialization Vector (IV)
Analogous to salts used in hashing
Same rules apply: use random data (16 bytes), store in plaintext, don’t reuse

18. Encryption and Legacy Systems
Many merchants who store plaintext PANs cannot easily alter the structure of DBs
Encrypted PANs are bigger, in different formats, plus IVs need stored
Old systems may be cost-prohibitive to alter
Solution: format-preserving encryption (FPE)
Idea: ciphertext in same format as plaintext
So 16-digit PANs become 16-digit ciphertext
NIST G Draft Standard
One python implementation:
Note: merchants using FPE still “in scope” for PCI

19. Merchant Hashing PAN at Rest
Issuer
{PAN}Kissuer
IVPAN
Exp.
ZIP
Name
Limit
F34D
8A98
12/17
74104
Joe
10000
9B32
142B
4/18
74114
Jane
8000
435E
924C
6/19
74011
Jim
5000
2. {PAN,CVV, exp, amt} enc. w/ SSL Mer.-Iss.
3. Authorization
Merchant
UID
Order
Auth.
Date
Name
H(PAN)
SaltPAN
Abc
123
DFWE
Joe
A356
81C0
1. {PAN,CVV, exp, amt} enc. w/ SSL Br.-Mer.
Browser

20. To hash or encrypt PANs? Encrypting PANs Hashing PANs
Enables merchant to store card data for repeat customers
Supports chargebacks, linking transactions
Systems storing encrypted PANs remain in scope of PCI
Hashing PANs
Systems storing hashes not in scope for PCI
Can be used to support chargebacks (verify same card used if customer re-enters PAN)
Supports linking transactions
Repeat customers must re-enter card details

21. Tokenization PAN data is valuable to merchants
Reduces friction in future purchases
Links prior transactions
PAN data is dangerous to hold
Valuable to attackers
Cost of PCI compliance and fines for breaches
Tokenization attempts to retain value of PANs while minimizing risk

22. Tokenization
Basic idea: replace PAN with a random number only linked to the PAN in an offsite, secure database
Eliminates need to handle PAN after transaction
Makes PAN security the tokenizer’s problem
Tokenization is not encryption

23. Tokenization: New Customer
Issuer
{PAN}Kissuer
4. TPAN , amount
7. Authorization
TPAN
5. Request Token TPAN
6. Send PAN
2. Request Token TPAN , PAN, CVV, exp
Merchant
Token Vault
{PAN}Kvault
TPAN
3. Send Token TPAN
1. PAN,CVV, exp, amt
PAN sent
Browser
PAN not sent

24. Tokenization: Returning Customer
Issuer
{PAN}Kissuer
2. TPAN , amount
5. Authorization
TPAN
3. Request Token TPAN
4. Send PAN
Merchant
Token Vault
{PAN}Kvault
TPAN
1. CVV, exp, amt
PAN sent
Browser
PAN not sent

25. Options for Generating Tokens
Randomly Generated Numbers
Can preserve PAN format (even keeping last 4 digits for example)
Tokens can even be made to pass LUHN check
Format Preserving Encryption
Encrypt using token vault’s key
Hash Function
No real advantage over randomly generated #s

26. Tokenization: Apple Pay Registration
2. Request Token TPAN , PAN, CVV, exp
Apple
Token Vault
{PAN}Kvault
TPAN
Note that apple calls the token
3. Send Token TPAN
1. PAN
4. TPAN
Secure Element
PAN sent
iPhone
TPAN
PAN not sent

27. Tokenization: Apple Pay Operation
Issuer
{PAN}Kissuer
2. TPAN , amount
5. Authorization
3. Request Token TPAN
4. Send PAN
Merchant
Token Vault
{PAN}Kvault
TPAN
Note: 1. Apple doesn’t see the interaction with the merchant, or the token, 2. the token is not newly generated per transaction, it is persistent, though a dynamic authentication code is created. 3. The merchant never sees the PAN, even in transit.
1. TPAN, amt
Secure Element
PAN sent
iPhone
TPAN
PAN not sent

28. Tokenization as a Service
Small merchants can outsource payment processing entirely
Processor runs token vault, passes token back to merchant
Reduces compliance costs at expense of lock-in

29. Tokenizing SSNs Replace SSNs with 9-digit token (retain last 4)
Minimize internal use of SSNs, breach potential
Unlike PANs, many real uses for SSNs

30. Conclusion
Passwords and PANs must be handled carefully in e-commerce applications
For data in transit: encrypt everywhere
For data at rest: encrypt (if you must) or eliminate via hashing or tokenization (if you can)