$30 off During Our Annual Pro Sale. View Details »

PHP Userland Security - Step by Step and Beyond

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!

Eric Mann

November 15, 2017
Tweet

More Decks by Eric Mann

Other Decks in Programming

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 [email protected]: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. [email protected]
    (844) 628-2872
    www.tozny.com
    THANK YOU!

    View Slide

  28. Open Discussion

    View Slide