PHP Userland Security - Step by Step and Beyond

Too often, the security of our applications is an afterthought rather than a pillar of design. This leads to embarrassing leaks of information, unintended violations of security best practices, or even critical vulnerabilities. This tutorial will walk through securing an app from first principles through smooth UX. We’ll navigate password hashing, two-factor authentication, and login by way of magic links. We’ll then go even further with auth by way of mobile push notifications!

Transcript

1. PHP Userland Security php[world] 2017
2. Today’s Agenda • Application Overview • Security Overview • 5 min break • Authentication and Password Management • Account Recovery • 5 min break • Multi-factor Authentication • Push Notifications • Open Discussion
3. The Application: RNGCoin • Simple application to mine, store, and exchange a cryptocurrency • This is not a real cryptocurrency!!! • We won’t be building a real blockchain - will use random numbers • Application needs: • Account login and password management • Balance overview • Recovery • Proactive action confirmation
4. Security: Usernames and Passwords • Usernames are unique but not necessarily private • Could (Should?) use an email address • Passwords should not ever be stored in plain-text • Password hashes should use known, stable algorithms • Hashing should be constant-time • Hashing should be “expensive”
5. Security: Account Recovery • Accounts should be recoverable via email • This helps when users forget their password • Recovering via email can also power “magic link” style login • Not requiring a password improves the user experience • It’s one fewer thing for users to keep track of • No passwords means a lost/stolen database can’t be used to breach other accounts
6. Security: Multi-factor Authentication • Usernames are your identifier: “something you are” • Passwords are a first form of authentication: “something you know” • A 2FA device or token adds extra security: “something you have” • Even if a password is breached, 2FA can help to keep a system safe • If you use magic links, the “something you know” disappears - adding a second factor keeps your system secure even if your customers’ email is penetrated
7. Security: Push Notifications • Also qualifies as a “something you have” 2FA approach • Can leverage software on the device to more strongly authenticate • Apple and Android can store asymmetric keys securely • Push notifications can trigger a challenge/response flow • Leverages out-of-band communication to verify authentication
8. Questions?
9. Break git clone git@github.com:ericmann/php-security-tut.git docker pull schickling/mailcatcher
10. Security: Usernames and Passwords • The app already has login and registration features - but passwords aren’t stored or validated • We want to store passwords on registration • We want users to be able to change their passwords • We want to securely hash passwords before storing them • We want to use constant-time comparison to validate passwords
11. Security: Usernames and Passwords • PHP exposes two functions to help us out: • password_hash() • password_verify() • The hashing function will salt the password for you • No plain-text is stored, just the salt and the resulting hash • The verification routine can securely compare a user-provided string with the hashed value • Verification is constant in time!
12. STORE THE HASH ON REGISTRATION, VERIFY ON LOGIN Exercise: Add Password Hashing
13. Security: Account Recovery • Users will forget their passwords, and need a safe way to reset them • This usually means sending an email with a reset link • This link is a token that can take complete control of the account! • For security, let’s take a “split token” approach • The token is 32 random bytes (64 characters) • The first half is stored as a “lookup” • The second half is hashed and stored as a “verifier” • Validation retrieves a stored hash based on the “lookup” and compares the provided value with the hashed “verifier”
14. This sounds a lot like usernames and passwords Security: Account Recovery
15. Source: https://blog.ircmaxell.com/2014/11/its-all-about-time.html Security: Account Recovery
16. Source: https://blog.ircmaxell.com/2014/11/its-all-about-time.html Security: Account Recovery
17. REUSE OUR PASSWORD CODE FOR RANDOM TOKENS Exercise: Add Account Recovery
18. Questions?
19. Break
20. Security: Multi-factor Authentication • There are several options, all relying on some thing in your possession • A hardware token (i.e. a Yuibkey) • A code generator • A mobile phone with an authenticator app • Today, we’ll leverage TOTP - Time-based One Time Passwords
21. Security: Multi-factor Authentication • TOTP uses a secret key shared between the client (phone) and the server • This key is used by the app to hash the current time to generate a 6- digit code • The server can generate the same code independently • We still need constant-time comparison - use hash_equals() • Users should be prompted upon login - either via password or a recovery link
22. Security: Multi-factor Authentication • User profile page (where we change our password) should allow device enrollment with a random key (and QR code) • The code for this is already available, it just needs to be set up • Logging in should delay a full session until a 2FA code is provided • Let’s add an interstitial confirmation screen before the dashboard • Can switch behavior based on the presence of a 2FA device enrollment and a flag in the user’s session
23. Exercise: Add TOTP 2FA
24. Security: Push-based Authentication • Also leverages a secret key • Public key is stored on the server • Private key is stored securely on a mobile device • The server sends a challenge to the mobile device in a push • The mobile device signs the challenge and submits the signature directly to the server • This requires a significant amount of infrastructure setup • We aren’t going to work through it all - instead I’ll demonstrate
25. Security: Push-based Authentication • Can use push as a second factor • Can also use push to verify an action • Protect large purchases with additional authorization • Notify of password changes or account modification • Unlike TOTP, the communication is entirely out-of-band • Unfortunately it does require the mobile device to be online
26. Demonstration: Push Notifications
27. info@tozny.com (844) 628-2872 www.tozny.com THANK YOU!
28. Open Discussion