Presentation is loading. Please wait.

Presentation is loading. Please wait.

Protecting Sensitive Data: From Passwords to PANs

Similar presentations


Presentation on theme: "Protecting Sensitive Data: From Passwords to PANs"— Presentation transcript:

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)


Download ppt "Protecting Sensitive Data: From Passwords to PANs"

Similar presentations


Ads by Google