Your Password Complexity Requirements are Worthless. Rick Redman KoreLogic

Transcription

1 Your Password Complexity Requirements are Worthless Rick Redman KoreLogic

2 Introduction Rick Redman < > 88FB D23C 5AC A933 6E99 4E2C EF75 Penetration Tester since 1999 Web Application security tester since ~2001 I Created and run the DEFCON contest Crack Me If You Can I run KoreLogic's Password Recovery Service (PRS). Used for incident response/forensics/password audits and recovery. I do this for a living. Published numerous wordlists/rules/tips/videos on password cracking Spoken at OWASP National, OWASP Austin, ISSA Meetings, DerbyCon, ISSW, DEFCON, ShmooCon, Bsides, PasswordsCon, TechnoForensics, etc

3 Introduction We are talking about password cracking/recovery. This is what takes place after a site is compromised. But we are also going to talk about protecting our end-users Both from application mistakes And from them-selves Example: LinkedIn Password hashes were posted anonymously. Within an hour, it became obvious that the source was LinkedIn. Currently at 97% cracked.

4 Introduction In general Users: Use simple passwords Use predictable passwords Have no clue what makes a password complex Internet Sites: Do not require users to choose complex passwords Do not know what a complex password is Do not store passwords in a secure manner Are a decade behind enterprises on password policy This is important for later

5 Current Password Complexity Defenses: Enterprise Password complexity rules Minimum length (Must be 8 characters) Character classes (Must contain a digit) Enterprise Password rotation History retention (No password re-use allowed) Better hash types (rarely implemented). Blacklisting top 500 passwords (see Twitter) JavaScript password meters These have NOT changed in the last 5-10 years! We need a better defense - One based on REAL data. One designed to annoy password crackers.

6 Current Password Complexity Defenses: OWASP s Recommendation: at_sheet#password_rotation Password Complexity Applications should have a password complexity requirement of: Passwords must be 8 characters or greater Passwords must require 3 of the following 4 character types [upper case letters, lower case letters, numbers, special characters] Your Enterprise likely has the same password requirements. Possibly 4/4 required.

7 Classic Password Cracking Methods (15+ years old): Naive bruteforce (impractical) Wordlists (Names, places, sports, company names) Mangling rules (Such as, capitalize first letter) Markov Chains (mathematical patterns based on position of letters next to other letters) Popular tools: Hashcat / OclHashcat, L0phtCrack, John the Ripper, InsidePro, PassWare, etc.

8 Newer Password Cracking Methods: Password reuse. (LinkedIn example). Rule generation based on previous data. Rule generation based on user-base or source of password leak ( Link Linked Linkedin LinkedIn ) Pattern Based (topologies) This is what we are here to talk about. This is what we _should_ be defending against. I will prove this.

9 Lets build a cracking machine.. A little math, for $2,000 you can build a small password cracking rig of 4 high-end GPU cards. With that one machine, you can crack all 8-character NTLM password hashes (NTLM is Microsoft Windows uses) in 3 days. All 8-character MD5 password hashes in 6.5 days. All 8-character SHA1 password hashes in 20 days. All 8-character SHA256 password hashes in 50 days. All 8-character SCrypt password hashes in billion years (SCrypt is what PCI/OWASP Recommends)

10 Lets build a cracking machine.. For reference: LinkedIn used SHA1 hashes to protect their passwords. LinkedIn password hashes were obtained by hackers 6 months before they were released. KoreLogic uses the equivalent of 10 of the example systems for our password recovery server (PRS).

11 Lets build a cracking machine.. But as you add length, the time gets longer quickly (against MD5): All 8-character MD5 password hashes in 6.5 days. 9 characters: ~500 days 10 characters: ~145 years 11 characters: ~12,000+ years So 9 character passwords are safe!? 500 days is a lot! (all sarcasm intended). So MD5 is safe?! (More on this later).

12 Who doesn t hash their passwords? Some sites do not even hash their password s at all. And end up being shamed publicly.

13 Patterns / Topologies Selective Brute Force: Rather than testing all possible passwords, pick some specific subsets, or patterns, and try all passwords that fit that pattern ( topology ). For instance Austin1! Sports9? Hiphop4$ Camels2% All use the same pattern: Uppercase, 5 lowercase, 1 number, 1 special. We will use the same notation as the Hashcat (JTR as well) tools: 'u' to represent "any uppercase letter" 'l' for "lowercase letter" 'd' for "digit" 's' for "special" (punctuation) The above example is then?u?l?l?l?l?l?d?s, or just ulllllds for short. 8 character password: 4^8, or 65,536 possible topologies

14 Patterns / Topologies The question then is: Do users bias towards certain common password topologies? If you can guess which patterns users have over-used, you can effectively bruteforce *just* those topologies, and crack a disproportionate number of passwords? We analyzed the passwords we had cracked from several different enterprise assessments, looking for frequently used topologies. Think of enterprise passwords as passwords that *have* meet password complexity (usually 8 length, having 3 of 4 categories (upper / lower / special / digit).

15 Patterns / Topologies Sample Organization #1 - Fortune ,356 of 263,888 NTLM logins cracked (including histories) over 99% 7,308 unique topologies found Most popular topologies: 33,458 ullllldd (8 character) 12.7% (Example: Austin15) 33,394 ulllllldd (9 character) 12.7% (Example: Hideout15) 27,898 ullldddd 10.6% 19,190 ullllllldd 7.3% 13,204 ulllldddd 5.0% (cont ) (Example: Rock2015) (Example: Ladybird15) (Example: Austi2015)

16 Patterns / Topologies The top 5 patterns are used by a total of 48% of all users. The top 100 patterns are used by a total of 85% of all users. 99.9% of passwords meet their complexity requirements Look at how similar the top 8-char topologies are to the top 9-char ones! They just added one lowercase letter (used a longer word).

17

18 Patterns / Topologies Sample 2 - Fortune 500 Company 419,287 of 449,192 NTLM logins cracked (including histories) 93% 14,266 unique topologies found Most popular topologies: 19,200 ullllldd (8 character) 17,914 ullllldds 14,025 ulldddds 12,477 ulllllds 9,216 ullsdddd 4.3% (9 character) 4.0% 3.1% 2.8% 2.1% Top 5 topologies crack 16% of all passwords. The top 100 topologies are used by a total of 62% of all users.

19

20 Patterns / Topologies We analyzed the password topologies used in 8 different enterprises of 4,000 or more logins where we had cracked more than 90% of all password hashes. We found that they had many popular topologies in common. This proves that these patterns/topologies are one key to how users create passwords. Therefor, we need to prevent them.

21

22 Patterns / Topologies Things the data told us: This data confirmed things we had long observed anecdotally: Users will pick the lowest-common-denominator that will be allowed by policies. When required to use 3 of 4 character classes, the most popular is: one upper, then several lowers, then 2-4 digits. If required to use 4 of 4 charsets, users just add a special to the end. (And most often that special character is!') If the minimum length increases, users are most likely to just use a longer base word, adding a lowercase letter. User behavior trends apply across organizations.

23 Patterns / Topologies Bottom line: Complexity rules don't help as much as enterprises think they do. If same complexity rules are deployed on web applications, the same patterns will emerge. But: If your web site/application does not require password complexity, your passwords are much much much worse. See: rockyou.txt (google it) See: LinkedIn (next slide) If you use the standard enterprise password requirements on your web application, it does _not_ make your users create stronger passwords. Enterprise complexity recommendations do _not_ make users create stronger passwords.

24 Patterns / Topologies Example: LinkedIn No forced complexity, but user base more likely to know password complexity rules

25 Whats the big deal? So why is this important to developers? and/or application testers? Because, FIX IT! That is why. Web Applications are not enforcing password complexity. This should be a finding/risk in a security report. This should be a requirement for PCI compliance. Java-Script password complexity meters are a risk They can be bypassed They leak information Most are NOT trained on real patterns or based on real data (See new few slides for examples)

26 Current Strength Meters Denver14 is good? Ullllldd Is in the top 100 list of most common patterns. Would crack in <1 minute.

27 Current Strength Meters Bacon14! is Strong? Really? Ulllldds pattern. It in the top 100 list of most common patterns. Would crack in <1 minute.

28 Current Strength Meters Denver14 will not take 15 hours to crack. This pattern takes <1 minute to run. And is in the top 100 most common patterns.

29 Current Strength Meters Bacon14! will not take 3 days to crack. This pattern takes <1 minute to run. And is in the top 100 most common patterns.

30 Current Strength Meters At least one site got it right. > Denver14 on both examples

31 Whats the big deal? (continued..) As auditors/testers are we asking about password storage? hash format? salts? Is this a line-item on our check lists? Will clients/developers even know? Windows SysAdmins: Don't have a choice in what hash format you use. UNIX/Linux SysAdmins: _DO_ Have a choice in which format they use. OWASP has a decent Cheat Sheet about this: eet All web applications accessed by an PCI-aware tester should follow the guidelines in this cheat sheet. Of the 500 or so large password leaks disclosed by attackers in the last year, not a single one followed these guidelines. (See LinkedIn eharmony) Closest: Adobe breached. They used DES, but with a common key.

32 Example of how its done correctly. Public Disclosure.

33 Type Value Type Value md5() 630 ntlm() 7 Password md5(md5(p).s) 134 sha512() 2 hashing in md5(s.p) 120 sha256() 3 crypt md5() 5 More Proof: the wild is md5(md5(s).md5(p 108 )) horrible. sha1() 94 md5(s.p.s) 3 Of all sites mysql5() 53 drupal7() 1 with md5(p.s) 38 md5(s.md5(p)) 1 password crypt des() 36 sha1(md5(p)) 2 mysql323() 34 sha1 base64() 1 sha512(p.s) 28 ssha1() 7 md5(md5(p)) 20 md5_half() 5 phpass() 15 crypt blowfish() 4 sha1(s.p) 14 ntlm() 7 hashes leaked in the last 6 months:

34 Defenses need to evolve Defenses need to evolve. We need to add a new dimension to password strength enforcement. Rules like minimum length, minimum character sets required, no dictionary words, etc are still needed. We need a way to analyze our risk/threat to our enterprises We also need a way to prevent users from gravitating towards the same password patterns (topologies) and overusing them. How long are we going to be complacent about this? How long is the fear of auditing passwords going to out-weigh the risk of not knowing what our users are setting as their passwords?

35 Password Audits (Warning - Shameless Plug) Example Report: During this audit, KoreLogic recovered passwords for 41.83% of the users in the ABCDEF domain [1]. Of these, 34.49% were active, and 7.34% were disabled. Viewed independently, 79.36% of the active and 12.99% of the disabled user passwords were recovered, respectively. Total Accounts Cracked = 4400 Total Accounts = Enabled Accounts Cracked = 3600 Total Enabled Accounts = 4600 Disabled Accounts Cracked = 700 Total Disabled Accounts = 6000 (Notice that the disabled accounts are hard to crack! ~13%)

36 Password Audits (Warning - Shameless Plug) Example Report: When this client started performing password audits, they were unaware of the amount of accounts with old, outdated passwords Over a 5 month period, they have disabled over 5000 accounts that were no longer needed. This cut the password-based attack surface in half! (roughly) The first time an audit was performed 90% of the passwords were cracked. 90% -> 79% improvement = a metric management can understand.

37 Password Audits (Warning - Shameless Plug) Example Report: Password Length Analysis: % (1300) % (1200) % (700) % (500) % (240) % (140) % (110) % (23) % (27) % (6) % (3) % (1) % (1)

38 Password Audits (Warning - Shameless Plug) Example Report: Most common strings of interest (e.g., years, months, seasons, etc.): 149 [CLIENT NAME HERE] Summer Spring June July 6 August 6 Fall 6 Winter 5 May

39 Password Audits (Warning - Shameless Plug) Example Report: Active users with recovered passwords older than one year: 542 (Possible metric to show improvement over time) Single password used the most: 239 unique instances (3 were disabled) Single password used the 2nd most: 19 unique instances (1 was disabled) (Possible metric to show improvement over time) Administrative accounts with recovered passwords: 27 (Possible metric to show improvement over time)

40 Defenses need to evolve Topology Related Defense: What are some ways we could use this knowledge to level the playing field? Blacklist the most common, predictable topologies. Don't allow multiple users to stack up on the same topology force them to spread out. Wear-Level them across the possible topology space. (Advanced topic). Require a minimum topology change between old and new passwords. The primary cost of these is keyspace reduction and userannoyance.

41 Pathwell Tool KoreLogic (with support from DARPA) has developed an open-source PAM replacement for Linux/UNIX systems that implements this. Basic Idea: Block the most common topologies. Example: Block ULLLLLDD ( Such as Denver14) based on its pattern. This will diversify the topologies used by end-users. And will remove the most common topologies from your users passwords. It is currently being ported to be used in a web environment. But the idea can easily be performed using server-side applications - or JavaScript/HTML5. i.e. SSO/LDAP/AD/SiteMinder Plugin

42 Pathwell Tool Advanced Topics/Functionality. When a password changes, the topology used by the new password cannot match the topology of the previous password. When a password changes, the topology used has to be mathematically diverse from the previous password. Hint the user about how to not use black-listed topologies. Do not prevent users from choosing bad passwords, but use PathWell backend to LOG the topologies used. Can be used to learn your users behavior without viewing plain-texts. Do not allow more than (x) users to use the same topology.

43 Pathwell Tool For a list of the 100 most popular password topologies used in Corporate/Enterprise environments check out: 4/04/pathwell_topologies These are the topologies/patterns that should be banned in Enterprise environments.

44 You!= Snow Flake You are not a special unique snow flake. That little trick thats in your head, that you think no one else knows (or can figure out) is used by millions of other people. Even people who use Austin16/ Summer16 / Summer2016/Password1/Texas2016 think this. Tell your users this, prove it to them, embarrass them if you have to, and THEN Train them how to be a unique snow flake. Prevent them from making the simple mistakes.

45 You!= Snow Flake