Protect Your User Accounts Like It's 2019

These are the slides of my talk at the Security Meetup by SBA Research (https://www.meetup.com/Security-Meetup-by-SBA-Research/events/258387229/).

The media are full of news regarding breached user accounts and passwords. Also, password-guessing attacks are rarely well protected against in applications, even in new ones.

Questions you might ask yourself:

- What can we do about that?
- Shall we lock out users after too many failed attempts?
- If we do, shall we lock them permanently or temporarily?
- If temporarily, how long?
- How can I prevent an attacker from systematically locking out users?
- Is user enumeration even a thing?
- How do big companies deal with this?
- What does a modern password policy look like?
- How can I make sure that everything is transparent to my users and that they can notice and react on malicious activity?
- Are there other and better mechanisms to protect user accounts?

Unfortunately, the answers to these questions are not always trivial, and depend on the type of data that your application processes, and also on the requirements regarding the CIA triad. In this meetup, we'll explore which questions you need to answer in order to make an educated decision on what to do.

We'll also explore some pretty smart techniques to achieve a balance between confidentiality/integrity and availability requirements, and how this technique can help you solve a number of other problems.

Transcript

1. Classification: Public 1
2. Classification: Public 2 Protect Your User Accounts Like It’s 2019 Thomas Konrad, SBA Research Meetup on February 6th, 2019 SBA Research gGmbH, 2019
3. Classification: Public 3 SBA Research gGmbH, 2019 $ whoami Thomas Konrad $ id uid=123(tom) gid=0(SBA Research) gid=1(Software Security) gid=2(Penetration Testing) gid=3(Software Development) gid=4(Security Training)
4. Classification: Public 4 Why Are We Here? The starting point. SBA Research gGmbH, 2019
5. Classification: Public 5 Some Assumptions 1. We’re developing an application (web or mobile) 2. The application has user accounts 3. The processed data is at least somewhat sensitive 4. We have a hard time coming up with proper account security solutions SBA Research gGmbH, 2019
6. Classification: Public 6 What Do We Want To Protect Against? Motivations for account security measures SBA Research gGmbH, 2019
7. Classification: Public 7 What do we strive for? SBA Research gGmbH, 2019 Image source: https://i2.wp.com/www.thesecurityawarenesscompany.com/wp-content/uploads/2015/05/CIAtriad- copy2.png?zoom=2.625&fit=2702%2C2448&ssl=1
8. Classification: Public 8 A Basic Threat Model Threat Severity1 C/I/A Countermeasures Password guessing High C/I/- ? Account lockout Medium -/-/A ? Misuse of known passwords (public lists, other apps, ...) Medium C/I/- ? Someone dumps the DB on the Internet Medium C/I/- ? Enumerating valid user names Low C/-/- ? SBA Research gGmbH, 2019 1 The severity really depends on the classification of your data. Don’t see them as absolute and unchangeable values.
9. Classification: Public 9 The Game Is On: Account Security Hammer Head SBA Research gGmbH, 2019 Image source: https://i.ytimg.com/vi/X4pSjBqbE0Y/maxresdefault.jpg
10. Classification: Public 10 The C/I And The A • In (account) security, these two are often contradictory • Often, we have to find a balance • Password guessing (C/I) vs. account lockout (A) SBA Research gGmbH, 2019
11. Classification: Public 11 Thou Shalt Not Pass! Protecting against credentials guessing attacks, a.k.a. “achieving the C and the I” SBA Research gGmbH, 2019
12. Classification: Public 12 What Can We Do For The C And The A? Gimme some ideas! SBA Research gGmbH, 2019 Image source: https://giphy.com/gifs/WilsonTennis-karen-khachanov-1o1iwQngXCF5guav2G
13. Classification: Public 13 Password Policy • NIST 800-63-3 Digital Identity Guidelines • Major overhaul in June 2017 SBA Research gGmbH, 2019
14. Classification: Public 14 Password Policy • Current recommendations in a nutshell o Nuke periodic changes o Nuke complexity rules – Only require a minimum length o Screen passwords against compromised passwords o Maximum length must be at least 64 cars o Require MFA for high-privilege accounts SBA Research gGmbH, 2019 Image source: http://37wz5x2r8vbh3om46wmfhy71-wpengine.netdna-ssl.com/wp-content/uploads/2016/10/yeah-600px.png
15. Classification: Public 15 Password Policy: Tips By NIST SBA Research gGmbH, 2019
16. Classification: Public 16 Password Policy: Screen Passwords • Troy Hunt’s Pwned Passwords API: https://haveibeenpwned.com/API/v2 SBA Research gGmbH, 2019 GET https://api.pwnedpasswords.com/range/{first 5 hash chars} 0018A45C4D1DEF81644B54AB7F969B88D65:1 00D4F6E8FA6EECAD2A3AA415EEC418D38EC:2 011053FD0102E94D6AE2F8B83D76FAF94F6:1 012A7CA357541F0AC487871FEEC1891C49C:2 0136E006E24E7D152139815FB0FC6A50B15:2 ...
17. Classification: Public 17 Password Policy: Screen Passwords SBA Research gGmbH, 2019
18. Classification: Public 18 Use Proper Hashes • Hash algorithms are designed to be fast • If our DB gets breached, we wish they’d be slow • So how should we persist passwords? o Use an algorithm that intentionally makes brute-force attacks slow o If you have the choice, use Argon2 o bcrypt is ok, but has some pitfalls o PBKDF2 is also ok SBA Research gGmbH, 2019
19. Classification: Public 19 Lock Users After Too Many Failed Attempts • Soft lock vs. hard lock o Soft == temporarily o Hard == permanently o Have both implemented! • I’d generally recommend a soft lock o E.g., lock for 5 minutes after 5 wrong attempts • But it really depends on the C/I requirements SBA Research gGmbH, 2019
20. Classification: Public 20 Multi-Factor Authentication • Require not just user name and password, but also something else (optional, but mandatory for admins) • Even if the credentials are breached, the attackers cannot log in • Some examples o A one-time password sent via SMS o A TOTP app (e.g., Google Authenticator) o A hardware token o U2F SBA Research gGmbH, 2019
21. Classification: Public 21 Multi-Factor Authentication: TOTP SBA Research gGmbH, 2019
22. Classification: Public 22 Transparency • Even if we do all we can, there might still be malicious activity • If fishy things happen, we at least want ... o ... the user to know it. o ... have the ability to react on it. SBA Research gGmbH, 2019
23. Classification: Public 23 Transparency: Notifications SBA Research gGmbH, 2019
24. Classification: Public 24 Transparency: Device List SBA Research gGmbH, 2019
25. Classification: Public 25 Transparency: How Do We Track Devices? • With Device Cookies (Device Tokens)! SBA Research gGmbH, 2019
26. Classification: Public 26 Detour: Device Cookies • Device Cookies in a nutshell o Catch successful login events o If this is a new device – Issue a Device Cookie – Send a notification (as you saw before) o The cookie (token) must be long-running o Connect the new session to it o Store source IP, user agent, first access, last access SBA Research gGmbH, 2019
27. Classification: Public 27 Detour: Device Cookies SBA Research gGmbH, 2019
28. Classification: Public 28 Detour: Device Cookies • Device Cookies enable us to do tons of great things o List devices (transparency, remember?) o Notifications upon a login from a new device (transparency, remember?) o Remember MFA for specific devices o Remember previously logged-in users o Slow down password guessing (you’ll see later) o ... • They are a must-have for good account security! SBA Research gGmbH, 2019
29. Classification: Public 29 Detour: Device Cookies SBA Research gGmbH, 2019
30. Classification: Public 30 User Enumeration SBA Research gGmbH, 2019
31. Classification: Public 31 SBA Research gGmbH, 2019
32. Classification: Public 32 User Enumeration • Actually protecting against user enumeration is really hard o Login form? o Login form after a user lockout? o Registration form? o Password reset? o Timing differences? o Other services that use the same user DB? o ... SBA Research gGmbH, 2019
33. Classification: Public 33 User Enumeration • It’s mostly about error messages with really bad usability o “Username and/or password wrong.” o “Invalid credentials. Note that you might get locked out after too many failed login attempts.” o “Password reset request received. If that account exists, you should have gotten an email with further instructions.” SBA Research gGmbH, 2019
34. Classification: Public 34 User Enumeration • Again, this depends on the sensitivity of the fact that somebody is registered. • Think “Ashley Madison vs. The Recipe Collection” • Sometimes, it is ok to accept the risk of user enumeration SBA Research gGmbH, 2019
35. Classification: Public 35 What Can We Do For The C And The I? 1. Use a good password policy 2. User proper hashes 3. Lock out users (hard lock vs. soft lock) 4. Multi-factor authentication (MFA) 5. Transparency (device lists, notifications) 6. Protect against user enumeration (?) SBA Research gGmbH, 2019
36. Classification: Public 36 Thou Shalt Not Lock! Keeping attackers from systematically locking out users, a.k.a. “achieving the A” SBA Research gGmbH, 2019
37. Classification: Public 37 Preventing User Lockout • This is the harder part! • Remember the Hammer Head? SBA Research gGmbH, 2019 https://giphy.com/gifs/cuteness-Hnv3oVMOkmHiE
38. Classification: Public 38 Preventing User Lockout: A Question Of Trust SBA Research gGmbH, 2019 Image source: https://www.supermarketguru.com/site/assets/files/6521/bakerycounter.jpg
39. Classification: Public 39 Preventing User Lockout: A Question Of Trust SBA Research gGmbH, 2019
40. Classification: Public 40 Preventing User Lockout: A Question Of Trust SBA Research gGmbH, 2019
41. Classification: Public 41 Preventing User Lockout: The Pareto Principle • You can save most users from being locked out • But not 100 %! • A note for apps with public registration forms o An attacker could register and issue themselves new device cookies via a script o Therefore: Count failed login attempts also for users and hard-lock them in case they’re attacking SBA Research gGmbH, 2019
42. Classification: Public 42 Let’s Update the Threat Model What do all the countermeasures mean to our model? SBA Research gGmbH, 2019
43. Classification: Public 43 A Basic Threat Model Threat Severity1 C/I/A Countermeasures Password guessing High C/I/- (Temporary) user lockout, password policy, MFA, transparency (device lists and notifications, with Device Cookies) Account lockout Medium -/-/A Selective lockout (with Device Cookies) Misuse of known passwords (public lists, other apps, ...) Medium C/I/- MFA Someone dumps the DB on the Internet Medium C/I/- Proper hashes (Argon2) Enumerating valid user names Low C/-/- (Generic error messages, constant timing on all requests containing the user name) SBA Research gGmbH, 2019 1 The severity really depends on the classification of your data. Don’t see them as absolute and unchangeable values.
44. Classification: Public 44 Advanced Countermeasures Where to go from here SBA Research gGmbH, 2019
45. Classification: Public 45 Advanced Countermeasures • Geo IP blocking • Heuristics • Conditional CAPTCHA • Conditional MFA • ... SBA Research gGmbH, 2019
46. Classification: Public 46 Account Security For End Users How to minimize the risk of a data breach for yourself SBA Research gGmbH, 2019
47. Classification: Public 47 Account Security For End Users 1. Use a password manager (not the browsers’) 2. Don’t re-use passwords 3. Turn on MFA where possible 4. Register on https://haveibeenpwned.com SBA Research gGmbH, 2019 Image source: https://i.1password.com/media/ios-hero.png
48. Classification: Public 48 Summing Up Things to do for better account security SBA Research gGmbH, 2019
49. Classification: Public 49 Summary 1. Define the CIA requirements for your data! 2. Do your Threat Model 3. Implement Device Cookies 4. Protect the C/I (password policy, proper hashes, lock users, (optional) MFA, transparency) 5. Protect the A (selective lock-out with Device Cookies) SBA Research gGmbH, 2019
50. Classification: Public 50 SBA Research gGmbH, 2019 Questions? Image source: https://giphy.com/gifs/reactionseditor-reaction-l0Iy8hSJalxmgTOF2
51. Classification: Public 51 sec4dev • Security conference for developers • Feb 25 to 27, 2019 o Day 1: Whole-day bootcamps o Day 2: Talks, conf dinner o Day 3: Talks • TU Wien, Campus Gußhaus • https://sec4dev.io
52. Classification: Public 52 Thomas Konrad SBA Research gGmbH Favoritenstraße 16, 1040 Vienna tkonrad@sba-research.org @_thomaskonrad SBA Research gGmbH, 2019 Thank you!