Protecting Sensitive Data From Passwords to PANs Tyler

  • Slides: 30
Download presentation
Protecting Sensitive Data: From Passwords to PANs Tyler Moore CS 7403 University of Tulsa

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

Agenda • Password security – What data to store and how (encryption, hashing, salts,

Agenda • Password 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) 2

Recall: session login Network Attacker Client Auth Request POST uid, pw Set sess. tok.

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

Data in transit vs. data at rest • Data in transit – Passwords sent

Data in transit vs. data at rest • Data in transit – 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 4

How to store a password 1. In cleartext on a backend database – –

How to store a password 1. In cleartext on a backend database – – Works so long as the DB system is perfectly configured and otherwise unbreakable In practice, terrible idea (see Rock. You data breach) 2. 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? 5

How to store a password 3. Store a one-way hash of the password –

How to store a password 3. 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 recomputing 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 6

But there is a problem • Password hashes remains vulnerable to an offline dictionary

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, Linked. In) 7

4. Store a Salted Hash of Password • Instead of hashing the password directly,

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 SHA 256) – 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: https: //crackstation. net/hashing-security. htm 8

Password Security • Additional risks to passwords – User selected so often guessable –

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

From Passwords to PANs • Passwords are far from the only sensitive information that

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 10

Payments Threat Models Network Attacker Terminal or Browser Auth req: PAN, CVV, amt PAN,

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

From Passwords to PANs • Recall that we could identify no good reason for

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? 12

PCI DSS • Recall that PCI DSS sets rules for anyone handling payment card

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 13

One key difference between PANs and passwords • Passwords are always secret – Used

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? 14

Issuer Encryption c. n }e t Issuer m a s. , xp. -Is e

Issuer Encryption c. n }e t Issuer m a s. , xp. -Is e V, Mer V , C SL N on S i A t / {P w iza r 2. ho t Au. 3 Merchant {PAN} Kissuer IVPAN Exp. ZIP Name Limit F 34 D 8 A 98 12/17 74104 Joe 10000 9 B 32 142 B 4/18 74114 Jane 8000 435 E 924 C 6/19 74011 Jim 5000 UID Order Auth. Date Name Abc 123 DFWE 201603 -25 Joe 1. {PAN, CVV, exp, amt} enc. w/ SSL Br. -Mer. Browser 15

Merchant PAN Encryption at Rest c. n }e t Issuer m a s. ,

Merchant PAN Encryption at Rest c. n }e t Issuer m a s. , xp. -Is e V, Mer V , C SL N on S i A t / {P w iza r 2. ho t Au. 3 Merchant UID Order Auth. {PAN} Kissuer IVPAN Exp. ZIP Name Limit F 34 D 8 A 98 12/17 74104 Joe 10000 9 B 32 142 B 4/18 74114 Jane 8000 435 E 924 C 6/19 74011 Jim 5000 Date Name {PAN}K IVPAN merchant Abc 123 DFWE 2016 -03 -25 Joe E 07 B B 3 B 1 1. {PAN, CVV, exp, amt} enc. w/ SSL Br. -Mer. Browser 16

Symmetric Encryption for PANs • PAN entries in database can be encrypted using symmetric

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 17

Encryption and Legacy Systems • Many merchants who store plaintext PANs cannot easily alter

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 800 -38 G Draft Standard One python implementation: https: //github. com/kpdyer/libffx • Note: merchants using FPE still “in scope” for PCI 18

Merchant Hashing PAN at Rest c. n }e t Issuer m a s. ,

Merchant Hashing PAN at Rest c. n }e t Issuer m a s. , xp. -Is e V, Mer V , C SL N on S i A t / {P w iza r 2. ho t Au. 3 Merchant {PAN} Kissuer IVPAN Exp. ZIP Name Limit F 34 D 8 A 98 12/17 74104 Joe 10000 9 B 32 142 B 4/18 74114 Jane 8000 435 E 924 C 6/19 74011 Jim 5000 UID Order Auth. Date Name H(PAN) Salt. PAN Abc 123 DFWE 2016 -03 -25 Joe A 356 81 C 0 1. {PAN, CVV, exp, amt} enc. w/ SSL Br. -Mer. Browser 19

To hash or encrypt PANs? • Encrypting PANs – Enables merchant to store card

To hash or encrypt PANs? • Encrypting 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 20

Tokenization • PAN data is valuable to merchants – Reduces friction in future purchases

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 21

Tokenization • Basic idea: replace PAN with a random number only linked to the

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 22

Tokenization: New Customer {PAN}Kissuer Issuer nt u o TPAN 4 N A. TP m

Tokenization: New Customer {PAN}Kissuer Issuer nt u o TPAN 4 N A. TP m , a 7 u. A o th t ir za ion 5. 6. Se nd Re qu e st T PA N 2. Request Token TPAN , PAN, CVV, exp Merchant 3. Send Token TPAN ok en T PA N Token Vault {PAN}Kvault TPAN 1. PAN, CVV, exp, amt Browser PAN sent PAN not sent 23

Tokenization: Returning Customer {PAN}Kissuer Issuer nt u o TPAN 2 N A. TP Merchant

Tokenization: Returning Customer {PAN}Kissuer Issuer nt u o TPAN 2 N A. TP Merchant m , a 5 u. A th iz or at ion 3. 4. Se nd Re qu es t. T PA N ok en TP AN Token Vault {PAN}Kvault TPAN 1. CVV, exp, amt Browser PAN sent PAN not sent 24

Options for Generating Tokens 1. Randomly Generated Numbers – Can preserve PAN format (even

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

Tokenization: Apple Pay Registration 2. Request Token TPAN , PAN, CVV, exp 4. TPAN

Tokenization: Apple Pay Registration 2. Request Token TPAN , PAN, CVV, exp 4. TPAN 1. PAN Apple i. Phone 3. Send Token TPAN Secure Element TPAN Token Vault {PAN}Kvault TPAN sent PAN not sent 26

Tokenization: Apple Pay Operation {PAN}Kissuer Issuer nt u o 2 N A. TP m

Tokenization: Apple Pay Operation {PAN}Kissuer Issuer nt u o 2 N A. TP m , a 5 u. A at iz or th ion 4. Se nd Re qu es t. T PA N ok en TP AN Token Vault Merchant 1. TPAN, amt Secure Element i. Phone 3. TPAN {PAN}Kvault TPAN sent PAN not sent 27

Tokenization as a Service • Small merchants can outsource payment processing entirely • Processor

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 lockin 28

Tokenizing SSNs • Replace SSNs with 9 -digit token (retain last 4) • Minimize

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 29

Conclusion • Passwords and PANs must be handled carefully in e-commerce applications – For

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) 30