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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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”
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

8. Questions?
   

   View Slide

9. Break
   git clone git@github.com:ericmann/php-security-tut.git
   docker pull schickling/mailcatcher
   

   View Slide

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
    

    View Slide

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!
    

    View Slide

12. STORE THE HASH ON REGISTRATION, VERIFY ON LOGIN
    Exercise: Add Password Hashing
    

    View Slide

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”
    

    View Slide

14. This sounds a lot like usernames and passwords
    Security: Account Recovery
    

    View Slide

15. Source: https://blog.ircmaxell.com/2014/11/its-all-about-time.html
    Security: Account Recovery
    

    View Slide

16. Source: https://blog.ircmaxell.com/2014/11/its-all-about-time.html
    Security: Account Recovery
    

    View Slide

17. REUSE OUR PASSWORD CODE FOR RANDOM TOKENS
    Exercise: Add Account Recovery
    

    View Slide

18. Questions?
    

    View Slide

19. Break
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

23. Exercise: Add TOTP 2FA
    

    View Slide

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
    

    View Slide

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
    

    View Slide

26. Demonstration: Push Notifications
    

    View Slide

27. info@tozny.com
    (844) 628-2872
    www.tozny.com
    THANK YOU!
    

    View Slide

28. Open Discussion
    

    View Slide