Passwords: Keys to the Kingdom What Developers Should Know

1. Passwords: Keys to the KingdomWhat Developers Should Know Patrick Hynds Microsoft Regional Director CriticalSites CTO

2. Patrick Hynds • CriticalSites Chief Technology Officer • Microsoft Regional Director • Extensive Consulting Experience • Regularly speaker at technical conferences: • TechEd US and Hong Kong • MDC in Cairo, Egypt • Security Summit in Boston and NYC • Security Editor of .Net Developers Journal • Over 50 technical certifications… • Blog at www.PatrickHynds.com

3. CriticalSites • IBM Premier Partner • MS Gold Partner • Commercial Software Development • Application Security Experts • Risk Assessments • White Hat Hacking (external probes) • Security Audits • Custom Application Development • Knowledge Transfer

4. Overview • Passwords Basic Patterns • Attacks Against Passwords • Service Account Passwords • Best Practices

5. Password Representations in Windows • LM Hash • Old technology used on LAN Manager • NT hashes (NTLM, NTLMV2) • Unicode password or MD4 hash • Used for authentication on more recent Windows systems • Cached credentials • Derivation of NT Hash • Stored User Names and Passwords • Calling application decides on representation

6. The Good, the Bad and the Ugly • NT Hash and Kerberos • Later generations of Windows passwords • Kerberos is Windows 2000 and later (including XP) • LM Hash • Legacy auth mechanism enabled by default in all shipping versions of Windows (including XP and 2003) • Be very afraid! • Typical Extranet • The monsters we typically build ourselves on the last day of a 12 month project • Enough rope to hang ourselves

7. NT Hash Generation • Hash the password • Store it in Active Directory or the SAM MD4 Hash Unicode Pwd WildMan1

8. NT Hash Considerations • Case preserving • Character variations > 630 • Maximum length = 127 characters • Entropy for 14-character password • Using the same char set as LM hash you get about 5.6*1025 possible passwords • Entropy for 14-character password • (full char set) ≈ 1.5*1039 passwords • Entropy for 110-character password • More than 8.4*10307 possible combinations • Unsalted

9. Kerberos Authentication • Authenticates access to domain resources by domain members • Uses different operations than NTLM • Sensitive data is better protected from eavesdropping • RFC compliant (For the most part) • Uses NT hash • Well documented

10. LM Hash Creation • Padded with NULL to 14 characters • Converted to upper case • Separated into two 7 character strings WILDMAN 1****** WildMan1 = + Key Key DES DES Constant Constant LM Hash Concatenate

11. LM Hash Considerations • It’s not actually a hash • Limited character set • Common alphanumeric set only • Case insensitive (Major Flaw) • Character variations ≈ 69 • Padded to exactly 14 characters • Actually two seven-character passwords • Maximum entropy ≈ 7.5*1012 passwords • Unsalted • Takes about 17.5 days to try every combo

12. Disabling LM Hash According to KB 299656

13. Typical Extranet Credential Creation • Stored at account creation • Managed by application • Usually clear text in DB = Very insecure User Selected Username Store Values in DB User Selected Password

14. ASP.Net 2.0 Membership • Implements many best practices • Hashes stored passwords • Enforces password complexity • Implements forgotten password mechanisms • Provides numerous controls • Provides extensible API • Supports provider model with easy default implementation • Out of the box requires complex passwords • Numbers, letters (both cases) and symbols

15. Four Types of Attack • Passive online • Active online • Offline Attacks • Non-electronic attacks

16. Key Point • Bad passwords get broken, even when using good storage and authentication methods! • Solutions • Use better passwords • Don’t let anyone get the hashes • Stay away from dictionary based passwords

17. Passive Online Attacks Wire Sniffing • Access and record raw network traffic • Wait until authN sequence • Brute force credentials • Considerations • Relatively hard to perpetrate • Usually extremely computationally complex • Tools widely available

18. Passive Online Attacks Man-in-the-Middle and Replay Attacks • Get access to communications channel • Wait until authN sequence • Proxy authN-traffic • No need to brute-force • Considerations • Relatively hard to perpetrate • Must be trusted by one or both sides • Some tools widely available • Can sometimes be broken by invalidating traffic

19. 5. Here’s my response 3. OK, here is a challenge 1. Hey, I want to connect 2. What a coincidence, so do I. 4. Thanks! Here’s your challenge, right back at you 6. That’s so nice, here’s your response back SMB Reflection Attack

20. Active Online Attacks Password guessing • Try different passwords until one works • Made easier by • Bad passwords (Core cause) • Open authentication points • Excessive information from server • Lack of password guessing controls • Considerations • Should take a long time • Requires huge amounts of network bandwidth to attack in parallel • Easily detected and stopped

21. Offline Attacks • Attacker has password database • Hard on Windows • Trivial on Unix • Hard on the Web without mistakes • Can attack at leisure • Password representations must be cryptographically secure • Considerations • Moore’s law

22. Offline Attacks Dictionary Attack • Try different passwords from a list • Succeeds only with poor passwords • Considerations • Very fast • Dictionaries include slang, musical group names, place names, etc. • Core problem: Bad passwords • At CriticalSites our standard dictionary has over 5 million passwords

23. Offline Attacks Brute-force Attack • Try all possible passwords until one works • Usually implemented with progressive complexity • Alpha-numeric • Alpha-numeric with upper row • Alpha-numeric with other symbols • Typically, LM “hash” is attacked first • Two seven-character passwords • Case-insensitive • Once found, vary case to find case-preserved password • Considerations • Slow because of the magnitude of possible variations • Theoretically, all passwords will eventually be found • Attack against NT hash is MUCH harder than LM hash

24. Offline Attacks Hybrid Attack • Start with Dictionary • Insert entropy • Append a symbol • Append a number • … • Considerations • Relatively fast • Succeeds when entropy is poorly used

25. Offline Attacks Pre-computed Hashes • Generate all possible hashes before hand • Compare to database values • Storing all hashes requires huge storage • All LM Hashes: 166 Terabytes • All NT Hashes < 15 chars: 140,959,235,198 exabytes • Solution: Use a time-space tradeoff • Generate most hashes • Store commonality • Compare hashes to find set of possible passwords • Brute-force within set • Used by Rainbow Crack • Succeeds because passwords not long enough

26. Offline Attacks Pre-computed Hashes – Considerations • Takes significant effort up front • LM Hashes much more vulnerable due to smaller key space and shorter length • Web services available • SETI-style efforts to generate tables • Mitigations • Use good passwords • Remove LM Hashes

27. Non-Technical Attacks • Shoulder surfing • Watching someone type their password • Common and successful • Mouthing password while typing • Keyboard sniffing • Hardware is cheap and hard to detect • Software is cheap and hard to detect • Both can be controlled remotely • Social engineering…

28. Social Engineering • Human Password Cracking • Requires some skill and boldness • Hackers are usually skilled and very bold • Chocolate Bar example • http://zdnet.com.com/2100-1105_2-5195282.html • Josh English Story (Verizon man) • Make up a password for me

29. Mitigating Threats • Combination of policy and technology • Define Password Policy • Disable LM Hash • KB 299656 – How to disable LM Hash storage • KB 828861 – How to run Win Cluster w/o LM Hash • Assess threats • Internal • External • Deploy appropriate mitigation • Implement Password Policy at OS level

30. Policy-Based Mitigation • Develop a password policy • Require pass phrases • Greater than 15 mixed characters • Password expiration for all accounts • No password reuse (temporal and spatial) • Account lockout (where appropriate) • Physical security policy • Cornerstone for any security • No physical security = no security • No enforcement = No policy

31. Pass Phrases v. Passwords • Pass phrases are long strings • Example: “Rumors is my favorite Fleetwood Mac album” • Very strong protection against attacks • Easy to remember, a bit longer to type • Sometimes break older applications • Passwords are short complex strings • Example: “Qu1ck8r0wnF0x1” • Hard to remember • Often difficult to type • Not resistant against current attacks • Obvious substitutions are quickly broken • Summary: Long easily-remembered phrases are better than short complex ones

32. Technology-Based Mitigation • Disable LM hash storage • Clustering, Windows CE, RTC broken • Clustering, RTC easy to fix • Other applications may be broken • Analysis and testing must be performed • Deploy password policy • Minimum length • Complexity • Expiration • Reuse • Lockout (be careful with this one)

33. Technology-Based MitigationMulti-factor authentication • Why use passwords at all? • Smart cards • Two-factor authentication • Very difficult to thwart • High cost of initial deployment • Long-term cost benefit • Cost of smart cards dropping constantly • Biometrics • Two or three factor authentication • Usually defeated with non-technical attacks • Very expensive • Failure-prone (not good enough)

34. Account Lockout • Used to mitigate online password attacks • Provides limited protection for bad passwords • Very simple denial of service vector • Do not use, except • As simple intrusion detection • In limited environments • Alternatives • Delay between login attempts • Use pass phrases instead • Add questions beyond username and password after specified number of bad login attempts

35. Policy Enforcement • User and Technical Staff Education • Termination for frequent violators • Spot Check with tools like Lopht Crack

36. The Service Account Problem • Service Accounts on Windows • Typically have local Administrator access • Often are members of Domain Admin group • Known to the Network Administrators • Not used to login typically so they are written down • Often difficult to change which means they are almost never changed • Risk • Many otherwise secure networks have ex-employees that still may know the username and password to one or more accounts that are members of the Administrator’s Group

37. Service Account Controller • Features • Manages service accounts & passwords across distributed systems • Change services account passwords by randomly generating one so that no human knows the passwords • Change service account startup settings • Add servers you would like to manage • Add/hide services you would like to watch • Clone configuration once you get it right

38. Service Account Controller • Benefits • Create fully secure service accounts, satisfying compliance and security requirements for Window services • Administer a distributed service account used by multiple servers and/or services from one location across an enterprise • Conceal the service account passwords, so they can't be used as backdoors by rogue administrators

39. Protecting and Synching Service Accounts with SAC

40. Best Practices Windows • Disable the LM Hash • Enforce password policy using: • Network policy (configuration) • Company policy (rules) • Always pass authentication credentials on encrypted channels even if they are hashed • Think about using SAC in combination with windows services for a more secure solution

41. Best Practices Intranet • Allow your applications to accept very long passwords (pass phrases) with diverse character sets • Always pass authentication credentials on encrypted channels even if they are hashed • Consider salting and then hashing your stored passwords (free with ASP.Net 2.0) • Ensure your storage of passwords is secure enough for your situation

42. Summary • Passwords Basic Patterns • Attacks Against Passwords • Service Account Passwords • Best Practices • Windows • Intranet

43. Please fill out your evals! This has been: Passwords: Keys to the KingdomWhat Developers Should Know Presented by: Patrick Hynds Microsoft Regional Director CriticalSites CTO Email: phynds@criticalsites.com Blog: www.PatrickHynds.com Please fill out your evals!