Slide 1

Slide 1 text

PHP Userland Security php[world] 2017

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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”

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Questions?

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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!

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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”

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Questions?

Slide 19

Slide 19 text

Break

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Exercise: Add TOTP 2FA

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Demonstration: Push Notifications

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Open Discussion