PHP Userland Security php[world] 2017 

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 

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 

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” 

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 

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 

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 

Questions? 

Break git clone [email protected]:ericmann/php-security-tut.git docker pull schickling/mailcatcher 

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 

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! 

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

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” 

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

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

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

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

Questions? 

Break 

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 

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 

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 

Exercise: Add TOTP 2FA 

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 

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 

Demonstration: Push Notifications 

[email protected] (844) 628-2872 www.tozny.com THANK YOU! 

Open Discussion