Password Storage Sucks!


Published on

Password storage strategies

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • Open Web Application Security Project
  • Password Storage Sucks!

    1. 1. Password Storage Sucks! How to properly store passwords in your database
    2. 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
    3. 3. Oh yeah… twitter … @nerdybeardo
    4. 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. 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. 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. 7. Why are we here? •Because developers suck at security! •And our users are paying for our suckiness!
    8. 8. How many people know what Angular is?
    9. 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. 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. 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!
    12. 12. Do you know who this is?
    13. 13. Game Theory Player1 Player 2 Hawk Dove Dov e Hawk 0,V V,0
    14. 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
    15. 15. Pshhhhhh…. “People will get their money back if my shit is owned, I don’t care…”
    16. 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. 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…
    18. 18. So you think you’re secure…
    19. 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
    20. 20. Why Not Encryption? H(x) = x mod 10
    21. 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
    22. 22. Merkle Damgard Construction
    23. 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. 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)
    25. 25. Rainbow Connection Rank Password MD5 SHA1 1123456 e10adc3949ba59abbe56e057f20f88 3e 7c4a8d09ca3762af61e59520943dc26494f89 41b 212345 827ccb0eea8a706c4c34a16891f84e 7b 8cb2237d0679ca88db6464eac60da96345513 964 3123456789 25f9e794323b453885f5181f1b624d0 b f7c3bc1d808e04732adf679965ccc34ca7ae34 41 4Password dc647eb65e6711e155375218212b39 64 8be3c943b1609fffbfc51aad666d0a04adf83c9 d 5iloveyou f25a2fc72690b780b2a14e140ef6a9e 0 ee8d8728f435fd550f83852aabab5234ce1da5 28 6princess 8afa847f50a716e64932d995c8e743 5a 775bb961b81da1ca49217a48e533c832c3371 54a 7rockyou f806fc5a2a0d5ba247160075845279 9c f1cf651ce1a2191a760c0b2f161234f7958e26 e4 81234567 fcea920f7412b5da7be0cf42b8c9375 9 20eabe5d64b0e216796e834f52d61fd0b7033 2fc 25d55ad283aa400af464c76d713c07 7c222fb2927d828af22f592134e8932480637c
    26. 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. 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. 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. 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. 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. 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. 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. 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.
    34. 34. Last thoughts… •Developers need to engage the Infosec community •OWASP Meeting’s •Local security meet ups!
    35. 35. Ok I’m done now… Follow me on twitter: @nerdybeardo Blog: