Best Practices for Protecting Sensitive Data
Learn about password and credit card data security, storing passwords securely, data in transit vs. data at rest, and the importance of using salts to protect password hashes from offline attacks. Discover how to securely store passwords using encryption, hashing, and more to minimize exposure of sensitive data to attackers.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
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, oh my) Credit card data security Who stores what and how (encryption, hashing, salts, and tokenization) 2
Recall: session login Network Attacker Auth Request POST uid,pw Check uid,pw Client Webserver Return auth. succ/fail DB Set sess. tok. CSRF,XSS, etc. Backend Attacker Web Attacker 3
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 Works so long as the DB system is perfectly configured and otherwise unbreakable In practice, terrible idea (see RockYou 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 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 6
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) 7
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: https://crackstation.net/hashing-security.htm 8
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 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 Auth req: PAN,CVV,amt Issuer/C ard Network Terminal or Browser PAN,CVV,exp Merchant Return auth. succ/fail Backend Attacker Web Attacker 11
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 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 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 {PAN} Kissuer IVPAN Exp. ZIP Name Limit Issuer F34D 8A98 12/17 74104 Joe 10000 9B32 142B 4/18 74114 Jane 8000 435E 924C 6/19 74011 Jim 5000 UID Order Auth. Date Name Merchant Abc 123 DFWE 2016- 03-25 Joe 1. {PAN,CVV, exp, amt} enc. w/ SSL Br.-Mer. Browser 15
Merchant PAN Encryption at Rest {PAN} Kissuer IVPAN Exp. ZIP Name Limit Issuer F34D 8A98 12/17 74104 Joe 10000 9B32 142B 4/18 74114 Jane 8000 435E 924C 6/19 74011 Jim 5000 UID Order Auth. Date Name {PAN}K IVPAN Merchant merchant Abc 123 DFWE 2016-03-25 Joe E07B B3B1 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 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 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-38G 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 {PAN} Kissuer IVPAN Exp. ZIP Name Limit Issuer F34D 8A98 12/17 74104 Joe 10000 9B32 142B 4/18 74114 Jane 8000 435E 924C 6/19 74011 Jim 5000 UID Order Auth. Date Name H(PAN) SaltPAN Merchant Abc 123 DFWE 2016-03-25 Joe A356 81C0 1. {PAN,CVV, exp, amt} enc. w/ SSL Br.-Mer. Browser 19
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 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 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 TPAN 2. Request Token TPAN , PAN, CVV, exp Token Vault {PAN}Kvault TPAN Merchant 3. Send Token TPAN 1. PAN,CVV, exp, amt PAN sent PAN not sent Browser 23
Tokenization: Returning Customer {PAN}Kissuer Issuer TPAN Token Vault {PAN}Kvault TPAN Merchant 1. CVV, exp, amt PAN sent PAN not sent Browser 24
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 Token Vault {PAN}Kvault TPAN Apple 3. Send Token TPAN 4. TPAN 1. PAN Secure Element PAN sent PAN not sent iPhone TPAN 26
Tokenization: Apple Pay Operation {PAN}Kissuer Issuer Token Vault {PAN}Kvault TPAN Merchant 1. TPAN, amt Secure Element PAN sent PAN not sent iPhone TPAN 27
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 28
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 data in transit: encrypt everywhere For data at rest: encrypt (if you must) or eliminate via hashing or tokenization (if you can) 30
