PHP Userland Security - Step by Step and Beyond

46093583d8895095adb1b0071c505af2?s=47 Eric Mann
November 15, 2017

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!

46093583d8895095adb1b0071c505af2?s=128

Eric Mann

November 15, 2017
Tweet

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