Transcript
Page 1: Secure Password Storage

Secure Password StorageJOSHUA SMALLHTTPS://GITHUB.COM/TECHNION/LHNSKEY - ROOT PASSWORD GENERATOR FOR CVE-2013-2352.

HTTPS://LOLWARE.NET/CW.HTML – CONNECTWISE PASSWORD “ENCRYPTION” [email protected]

DJB’S CRYPTO SNAKE OIL COMPETITION SUBMISSION: HTTP://SNAKEOIL.CR.YP.TO/SUBMISSIONS.HTML

Raspberry Pi Powered NTP

Server

Page 2: Secure Password Storage

Typical Web Sign Up Form

Page 3: Secure Password Storage

The Problem

Page 4: Secure Password Storage

Typical Usershinycatz.com Compromise

Attacked notices:“secret” is the password for John’s hotmail

User: All he can do is read my email!

Hotmail inbox: Welcome to mybank.com

Mybank.com: Forgot your password? Click here and we’ll email you a new one

shinycatz.comEmail: [email protected]: secretUser: Oh all they can do is produce fake cats in my name!

Mybank.comEmail: [email protected]: supersecretUnique password – good boy John!

Page 5: Secure Password Storage

Typical Vendor

Page 6: Secure Password Storage

Terrible Solution

function encryptpass($password){$key = “omgakey”;Return base64_encode(

mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$key, $password,

…Function decryptpass($secret){$key = “omgakey”;…

Page 7: Secure Password Storage

Comically terrible solution

Page 8: Secure Password Storage

User Solutions

Lastpass and similar apps Unique passwords everywhere! Uptake from users: very low

Page 9: Secure Password Storage

Hash Algorithms!

MD5: Officially Broken! Do not want! SHA1: Published 1995, theoretical attack: 2^61 SHA256: Brute force at 2^128 This would make SHA256 completely secure for

our purposes, for completely random input But passwords are not random

Page 10: Secure Password Storage

Key space

One byte stores eight bit of data But only 96 ASCII characters are printable That leaves roughly 6.5 bits of entropy per byte Average password is 6 characters long That’s only 39 bits of brute force - feasible

Page 11: Secure Password Storage

Improvements

Stretching: Literally “perform the hash x times” Salt: incorporate a random string. This prevents

“rainbow tables”, ie a big database of precomputed hash values

Page 12: Secure Password Storage

SHA512crypt

Literally applies the principles of “stretching” and “salting” to SHA512

Default in several current Linux distributions for passwords in /etc/shadow

Page 13: Secure Password Storage

Bitcoin

Uses the SHA algorithm CPU: Core i7 820: 13.8Mhash/s GPU: GTX295: 120.70Mhash/s ASIC: Antminer S1: 180,000Mhash/s

Source: https://en.bitcoin.it/wiki/Mining_hardware_comparison

Page 14: Secure Password Storage

Scrypt

Developed by Colin Percival, presented May 2009 Designed to offer significantly lower advantages to

GPU and ASIC devices Uses a hard to optimise hash function Is not only computationally hard- but memory hard Original paper:

http://www.tarsnap.com/scrypt/scrypt.pdf Used in Dogecoin Dogecoin ASICS pushing 70KHash/s a big deal! Increasing difficulty doesn’t just slow things down, it

can break those ASICS by exceeding their memory

Page 15: Secure Password Storage

Very short algorithm summary

Source: https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-00

Page 16: Secure Password Storage

Problem: Accessibility

Use in applications: Reference app Implementation function:

Produces a binary string as output

Page 17: Secure Password Storage

Introducing libscrypt

Simpler API:

Produces one string containing salt, difficulty operators and hash altogether

Output is already BASE64 encoded, ready for storage

Simple checking function

Page 18: Secure Password Storage

Accessibility: Platform support

Fedora RPM Debian (and derivatives) package FreeBSD ports OpenBSD ports Homebrew (OS X) Tested on ARM (Raspbian) Tested on IBM s390 for some reason

Page 19: Secure Password Storage

Difficulties

Potential DoS opportunity Rate limit Proof of work Captcha

Page 20: Secure Password Storage

Future Improvements

HSM Polypasshash

Questions?


Top Related