Dev Training

# Dev Training
### Sensitive Data Exposure

## Sensitive data

### What is it?

* Any data that is meant to be protected against unauthorized access
* In the EU certain types are covered by GDPR
    * Personally identifiable data (PII)
* GDPR: Strict limits on how personal data
    * Is stored
    * Is gathered
    * Is transmitted

Notes:
* What is sensitive data?
* Broad definition.
    * Depends on who you ask.
* Personally Identifiable Info (PII)
    * Protected by regulations.
* All kinds of user or system secrets.

### Examples

* Personal data
* Intellectual property
* Credentials, passwords, API keys, etc

Notes:
* Other examples include IP, for example.

### How is it exposed

* Exploits of other vulnerabilities
    * SQL/path/command injection
    * Security misconfiguration
    * Known vulnerabilities
* Cryptographic failures

Notes:
* Can be exposed in many ways.
* All kinds of exploits.
* Cryptographic failures.
    * Usually misconfiguration.

## Information Disclosure

### Accidental exposure

* Credentials in version control
* Credentials in public container in Docker registry
* Web framework debugging enabled

Notes:
* Human error can be the direct cause.
* These examples.
    * Sometimes also social media posts, for example.

### Serving excessive amounts of data

* User profile endpoint shows address, gender, shoe size and blood type
    * UI only shows the user's name
* User profile picture has metadata showing location

Notes:
* Sometimes web apps provide TMI.
* UI should not be used as filter.
    * We can peek behind the curtain.
* Image metadata.
    * Used to dox people in the past.

## Protecting data

### Sensitive data

Needs to be protected **in transit** and **at rest**

Notes:
* These are both important and very different concerns.

## In transit

### Secure protocols

* At the network layer, data needs to be protected by using encrypted protocols
* HTTPS
    * TLS 1.3 or higher
    * Test your servers with [Qualys SSL Labs](https://www.ssllabs.com/)

Notes:
* Securing data in transit.
    * Good protocols.
    * Encrypted.
* Great resources available to test.

## At rest

### Encryption

* Extensive and complicated topic
* Crypto is **hard**
* Not all crypto is created equal
    * A lot of insecure/broken algorithms exist out there
    * Small implementation mistakes can result in broken crypto

Notes:
* Encryption is hard, do not try.
    * Use ready-made solutions.
    * Do some research.
* General security practices apply.

### Recommended algorithms

* Use built-in pre-configured algorithms in frameworks or languages if they meet your requirements
    * Less room for error
* Symmetric crypto
    * AES
    * Elliptical curve
* Asymmetric
    * RSA
    * Elliptical curve
* RTFM!

Notes:
* Consult the documentation, always!
* Use popular, built-in stuff.
* Get familiar with crypto basics.
* Consult the documentation!
    * Hope I sound like broken record.

### AES

* Don't use ECB mode
* Most modes use *Initialization vectors* (IVs)
    * IVs should never be reused
    * IVs should not be predictable
    * IVs should be generated using **cryptographically secure** random number generators

Notes:
* AES is backbone of the internet.
    * Block cipher
    * Multiple modes of operation.
* ECB is bad!
* Follow specs for config/setup.

### Seriously, Don't use ECB

![ECB](./tux.png)

Notes:
* This is how bad ECB is!

### Asymmetric

* RSA
    * Use at least 2048 bits
* Elliptical curve
    * Use known curves like *Curve25519*

Notes:
* RSA/elliptic curve algorithms are asymmetric.
    * Public/private keys.
* More bits of key material = better.
    * Today, RSA with less than 2048 is bad.
* Use tried and tested elliptic curves.
    * E.g. 25519.
    * Math is beyond me.

### Key management

* Encryption is not a silver bullet
    * It does not secure data on its own
* Encryption/secret keys need to be kept safe
    * E.g., storing encryption key in database render encryption pointless if DB is dumped

Notes:
* Encrypted does not automatically mean secure
* Data only as safe as keys.
* Store keys separately from data.

### Whatever you do

# **Don't do your own crypto**

Notes:
* If implementing access control from scratch is bad.
    * Implementing your own cipher is worse.
* You will fail. Not trying to be mean.

### Secrets in Version control systems

### A common shortcut

* Very common to see production secrets in VCS
* VCS is not a secret storage!
    * Leaked source code should not entail a breach or compromise

Notes:
* Extremely common issue.
* Assume your source code is common knowledge.
    * Do not store any secrets there, ever!
    * Assume prior breach.

### What should I do instead?

* Inject secrets at build time
    * CI/CD (Although this makes the CI/CD systems a very juicy target)
* Inject secrets at runtime
    * Store secrets in production environment (bare metal)
    * Store secrets in secret store

Notes:
* Use runtime injection
* Most frameworks have good tools for this
* Can be done in CI/CD.
    * May introduce other risks.
    * It depends.

## Passwords

### Protecting passwords

* Should be considered very sensitive user data
    * Although GDPR does not agree
* Complete database compromise should not entail a leak of passwords
* Passwords should always be stored using a one-way cryptographic hash function
* Never store passwords encrypted!
    * Developers should not be able to access them

Notes:
* Very sensitive data.
* Do not store!
* Use cryptographically secure hashing!
* Encryption is actually bad!

### Cryptographic hash function

* A one-way function $h$
* Used to verify integrity of messages
* Collision should be very unlikely: $h(m_1) = h(m_2)$ where $m_1 \neq m_2$
* Given a hashed value, finding a different message that yields the same hash should be almost impossible

Notes:
* One way functions.
* Used for quick data comparison.
    * Verify data integrity.
    * Validate passwords.
* Collision should be practically impossible.

### Password storage

* Some cryptographic hash functions are fast
    * Unsuitable for storing passwords
    * Makes brute-forcing easier
* Hash functions are predictable
    * Possible to precalculate (rainbow table)

Notes:
* There are many considerations.
* Avoid implementing this yourselves.
* Use popular, built-in tools!
* Endless pitfalls exist.
    * Which compromise security.

### Password hashing

* Subcategory of cryptographic hashing
* Usually involves multiple rounds or some other mechanisms to slow the process down
* Algorithms need to be carefully selected
    * MD2/4/5 are unacceptable
    * SHA-1 being phased out

Notes:
* Password hashing is its own science.
* Often multiple rounds of salted hashing.
* Algorithm matters!

### Salt

* Random string added to the password before hashing
    * Should be at least 32 bits
    * Follow recommendations for hash function
* Stored along with the hashed password
* Prevents rainbow table attacks
* Built into some password hash functions

### Pepper (secret salt)

* Static (secret) string that is added to the password before hashing
    * Cannot be changed
* Not stored with the hashed password
* Protects against brute-force attacks in case of leak

### Algorithms

* *bcrypt* – Based on blowfish
* *scrypt* – High memory use
* *PBKDF2* – Generic algorithm
* *Balloon* - High memory use

## Rules of thumb

### General

* Collect as little sensitive data as possible
    * Can't leak what we don't store
* Serve as little data as possible
* Expose as little data as possible

### In transit

* Use encrypted protocols

### At rest

* Encrypt sensitive data
* Keep encryption keys safe
    * Use secrets (or key) management systems

### Password

* Choose a good hash function
* Salt and pepper

## Epilogue

### Further reading

* [NIST - Cryptographic Standards and Guidelines](https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines)
* [OWASP - Protect Data Everywhere](https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere#)
* [OWASP - Cryptograhic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)
* [NIST - Authentication and Lifecycle Management](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf)

### Hall of fame

* [British Airways hit with €22m fine for being phished](https://edition.cnn.com/2019/07/08/tech/british-airways-gdpr-fine/index.html)
* [Marriott hit with £20.4m fine for being hacked](https://www.theguardian.com/business/2019/jul/09/marriott-fined-over-gdpr-breach-ico)
* [InfoMentor fined 3.000.000 isk for breach](https://www.personuvernd.is/personuvernd/frettir/personuvernd-sektar-infomentor-ehf.-vegna-oryggisbrests#)
* [Icelandic minister shows her driver's license](https://twitter.com/aslaugarna/status/1222561959834419200)
* [Australian PM posts picture of plane ticket](https://mango.pdf.zone/finding-former-australian-prime-minister-tony-abbotts-passport-number-on-instagram)
* [Facebook friends are not always "friends"](https://www.reddit.com/r/Whatcouldgowrong/comments/ly6j7c/wcgw_with_sharing_your_achievements_on_the/)