2. Legal Disclaimers…
Disclaimer 1:
I make no guarantees about beard length. But a beard will always be attached to this sexy
face.
Disclaimer 2
I curse, frequently… sorry
Disclaimer 3
Opinions are my own. Advice provided with no warranty.
If you go back and implement an algorithm I told you to implement you do so at your own risk.
In other words
… Don’t come crying to me on twitter
4. Who am I?
• I am Software architect on the .NET Stack
• I study cryptography for fun (WTF?!?)
• I study application security but not for fun… it’s scary
• Most of my life is spent on a keyboard with the following exceptions…
• I managed to get married…
• And against all odds… I somehow was able to pass on my genes
5. Credentials….
• I have none…
• Except I have a beard…
• And because it’s so awesome people pay me a boat load of money to fix
their shit
• Wait I lied… I’m a certified Scrum master
• Or as my clients call me… The Scum Master
• I’ve also been called Dragon Master
6. How to approach this talk
•Don’t just look at this as a talk on password
storage
•Look at the approach we’re taking to secure our
passwords
•Use the same type of approach for all your PII
Data
7. Why are we here?
•Because developers suck at security!
•And our users are paying for our suckiness!
9. How many people know what a
CSRF is?
• How important CSRF is becoming because of single
page sites?
• Do you know why it’s dangerous to allow your API’s to be
hit as GET requests?
• Are you protecting your API’s with request forgery
tokens?
• In other words CSRF is much more dangerous because
of the use of frameworks like Angular with a REST API,
yet it’s rarely brought up as a topic.
10. I’m dizzy please stop!
• The amount of new frameworks coming out is dizzying
• We are WAY too focused on frameworks, and tools, and the next thing that’s
going to make our site look super awesome.
11. Newsflash!
• Using Angular isn’t going to make you cool! (Is it still ok to say the word
cool?)
• We will still be nerds. (or in my case Nerdy)
• There is going to be a new framework tomorrow.
• Your apps will still be broken!
14. Wild Wild West…
• The internet is the Wild Wild West
• “Cost” of playing hawk on the internet has gone down tremendously
• 17 year old in Eastern Europe can be the cause of 40 million credit cards
being stolen from Target
16. Yeah except…
People in this room control…
•Health Records
•Financial data
•Legal Data
•Buying habits
•Most people use the same passwords for all their
sites
17. Oh the things I’ve seen….
•Password stored only as hash values
•User tables susceptible to SQL Injection attacks
•Backdoor “master” password access to all users
•“Encrypted” in the famous base64 encryption
algorithm
•“Encrypted” in the famous plaintext algorithm
•No Password - How’s anybody going to get to this
admin page? Nobody knows the URL…
19. Not the kind of hash you may be
used to
Blast From the Past
College Professor’s told me..
I can use a hash function to
“map” my data to a “bucket”
Mainly used in hash tables
System.Collections.HashTable
System.Collections.Generic.Dictiona
ry
Fast storage and retrieval
(ooooh yeah)
Example
I have Bins buckets and 100
apples. I want to spread them
evenly to all my bins.
h(x) = x mod 10
21. This ain’t yo mama’s Hash function
Use cryptographically secure hash functions for passwords
• It should be hard given h(m) to find m’ such that h(m’) = h(m)
(pre-image resistance)
• Should be difficult given a message m with hash h(m) to find a
message m’ != m and h(m) = h(m’) (second pre-image)
• It should be difficult to find two messages m and m’ where h(m) =
h(m’)
• Preferable to have a property called the avalanche effect
• 1 bit difference causes at least 50% of the following bits to
change
23. We still have some problems
Fact of life: All cryptographic hash functions are
susceptible to collisions.
• I’m lazy… so here’s my rule of thumb
• Take the output size of the hash algorithm and divide
by 2 and our security level is 2^n
• Search Wikipedia for Birthday paradox for the proper
math
24. Merriam Webster I Shake My Fist At
You!
• Forget all the theory….
• We can just pre-hash a dictionary and match the hash to the original value.
(Rainbow Tables)
26. mmmm…. Salty
• To get around the problem of rainbow tables add a random salt
• Don’t just use random text! I see this time and time again.
• Use Random bytes and add to the password before hashing
• Generate with System.Security.Cryptography.RNGCryptoServiceProvider
• PHP openssl_random_pseudo_bytes
• Ruby: OpenSSL::Random
• Longer and more random is better
• Store the salt in a field in your db along with the username and
password hash (can be unencrypted)
• PasswordField == Hash(saltBytes + GetBytes(passwordEntered))
27. Salty Hash is good but not that
good…
• Most cryptographic hash algorithms are made to perform over
large files, so they are really fast
• My PC (Core i7 3930k) can do almost 360 Mb/s for SHA-1
• So we can generate rainbow tables on the fly from password
databases
• Need to slow it down! So we’ll introduce a work factor
• Work factor tells the algorithm how much “work” to perform
• As computers get faster increase the work factor and re-hash as
users log in
• Good examples are BCrypt, SCrypt, PBKDF2
28. PBKDF2
PROS
•Uses standard Hash Functions
•Takes Salt
•Comes Standard in Many
Frameworks
(Rfc2898DeriveBytes)
CONS
• Possible to mis-configure if
using anything other than the
standard Hash
• Standards for work factor are
really unknown
• Can be attacked using GPU
Array
• Can be attacked using FPGA
Array
29. BCrypt
PROS
• Very Old!
• Open Source!
• Has been used in many secure
software programs
• Much Easier to Configure and
use
•Salt, Iteration and Hash stored
as one field
• Difficult to brute force on GPU
CONS
• Open Source
• Memory requirements make it
vulnerable to things like FPGA
30. SCRYPT
PROS
•Open Source
•Much Easier to Configure and
use
•Salt, Iteration and Hash stored
as one field
• Difficult to brute force on GPU
CONS
• Relatively new
• Open Source
• Good implementations are
harder to find
31. OMG WTF Am I gonna do?
• If you’re not using a salted hash update all passwords with a more secure algorithm.
BCrypt(MD5(Password)) and store a version (Version 1).
• When a user logs in simply upgrade on successful login and save to a new version (Version 2).
string function VerifyPassword(string input, string hash, int version)
if version is 1 then
input = md5(input)
result = bcrypt.verifypassword(input, storedhash)
if result is true and version is 1 then
updatepassword(bcrypt(input,workfactor), 2)
return result
end
32. What if I don’t have a hash at all?
• Even though you are less secure than someone who went through hashing
you’re actually on an easier upgrade path
• Simple compute the BCrypt hash (or whatever else you want to use) over
your user database and store it back in the database
• If you have a lot of users (> 100,000 users) this will take a long time, but
you can take advantage of multi-threading and multiple cores.
• Make your users change their password on first login
33. Other recommendations
• My #1 Recommendation for password storage
•DON’T
• If you can get away with it use an open API like OpenID (google, facebook, yahoo
etc..) this removes the liability from your code and is safer for your users.
• If you can use a standard authentication mechanism such as Active Directory, or a
corporate standard approved by your security team then use that instead.
• Run your entire application under the least privileges you can get away with.
• I highly recommend putting restrictions on which users are able to read the user
table, segregate that table away from the rest of the database if possible and only
allow a single user to have read access, and a single user that has write access.
35. Ok I’m done now…
Follow me on twitter: @nerdybeardo
Blog: http://www.nerdybeardo.com
Hinweis der Redaktion
I attribute that to the beard because I have no freaking idea why
In some ways I don’t want to
You can expose your users to identity theft even if you don’t hold any financial information
Preimage resistance (database of passwords you only have the digest)Second pre-image resistance (HMAC or digital signature where you sign the document you have digest and document)Collission resistance (find me any two messages that have the same hash)The previous example we actually used the collision property to find which bucket data went to. This is a horrible Provide some additional features on top of the algorithms we’ve all developedKeccak pronounced catch-ack
n/2 is approximately the number of tries it will take to get a collisionUse Wikipedia to get the real math (if you really want to)MD5 digest size is 128 bits. Therefore you can find a collision using the birthday paradox in approximately 2^64 triesSha-512 output size is 512 bits. Therefore it would take approximaltely 2^256 tries to come to find a collisionMerkle–Damgård construction
I really don’t know about the RNGCryptoServiceProvider, when I initially made this presentation it wasn’t out that the NSA may have possibly put a back door in Microsofts RNG.
These algorithms are not multi-threaded, I can utilize multiple cores to check multiple passwords at the same timePassword based key derivation function
MostBcrypt implementations store the salt, and workfactor as delimited values in t
