1 / 43

Passwords: Keys to the Kingdom What Developers Should Know

Passwords: Keys to the Kingdom What Developers Should Know. Patrick Hynds Microsoft Regional Director CriticalSites CTO. Patrick Hynds. CriticalSites Chief Technology Officer Microsoft Regional Director Extensive Consulting Experience Regularly speaker at technical conferences:

anakin
Download Presentation

Passwords: Keys to the Kingdom What Developers Should Know

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related