TrialPay Security Tech Talk at Stanford ACM

All Rights Reserved | Copyright 2011

Stanford ACM Tech Talk

Jan 2013


Agenda

• TrialPay Overview

• Securing Your Startup: Basics

• Two-Factor Authentication for VPN

• Two-Factor Authentication for SSHD

• Credit Card Vault

2

All Rights Reserved | Copyright 2011 3

TrialPay is a transactional advertising company

TrialPay presents consumers with relevant promotions before, during, and after transactions -- creating a network that allows our clients to gain access

to millions of new customers and monetize their current visitors more effectively


Tracking online promotions to sales in-store via card-loaded offers

4

Promotion Tracking Purchase Reward

Promote offline offers: Offers promoted across the web, mobile, & social media (incl. TrialPay network of 300M+ users)

Users activate online: Users activate offers by submitting credit or debit card

Track offline: Offer redemptions tracked in-store via registered card to attribute online source

Reward user: We credit user with their reward (e.g. statement credit, virtual currency, gift card) upon offer completion

1 2 3 4


Example user registration flow – Credit Card Form


Agenda


• Securing Your Data: Basics




6


Getting Started

• Google Apps Two-Factor Authentication (2FA)

• Amazon Web Services 2FA and ACLs

• Secure Wireless Network – per-user certs

• HTTPS for everything

7


Passwords

Reference: http://xkcd.com/936/


Passwords (cont’d)

• 14-character password minimums, but more never hurts!

• Basic GPU can crack 16B passwords per second

• Make sure shadow files are configured correctly (e.g. crypt-sha512, not default DES or md5, 50K rounds)

• GOOD: $6$rounds=50000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

• BAD: $1$DaqXb3sb$m84WH8wkxBVl2WvZQboia.:13530:0:99999:7:::

9


Agenda






10


2FA for VPN – Standard VPN Login

11

1) Connect to VPN Client

2) Enter Credentials

3) VPN Device Authenticates

4) Inside the VPN!


2FA for VPN – Traditional 2FA

• Traditional solutions use tokens (hardware, Google Authenticator, text messages)

• Unintuitive input of token (concatenate with password)

• IT burden

• Hassle for end-user accessing VPN multiple times per day

• Wouldn’t it be nice to leverage existing security mechanism?

12


2FA for VPN – Enter Google Apps!

• User 1-click visits a Google App Engine hosted site https://xxxxxxxx.trialpay.com which auto-logs you in on browsers where you already read your Google Apps email.

• This page just shows a 60 second timer for the user to complete the rest of the VPN login process.

13


2FA for VPN – Technical Details

• Google App Engine – python script to get username from Google Apps and create 60-second memcache key

• Auth Server – add Perl script to authorize with Google App Engine site

• Reference: http://enginerds.trialpay.com/2013/01/08/leveraging-google-apps-email-to-set-up-two-factor-authentication

14


Agenda






15


2FA for SSHD – Background

• For bastion / entrypoint servers into network, passwords by themselves are insufficient

• Tokens are viable, but introduce complexity / hassle

• SSH keys are convenient for developers

• Passphrase-protected SSH keys are encouraged and can suffice for 2FA, but SSHD cannot enforce passphrase-usage

• SSHD supports multiple authentication schemes, but they cannot be enforced simultaneously

16


2FA for SSHD – ForceCommand to the rescue!

• /etc/ssh/sshd_config

• sshd_gatekeeper.sh

• IP whitelisting

• Send intrusion alerts

• Don’t forget to actually check the password!

• Reference: http://enginerds.trialpay.com/2012/07/24/dual-factor-authentication-for-sshd/

17


Agenda






18


Credit Card Vault

• Best practice is to insulate sensitive credit card data from rest of system in a secure “vault”

• Vault has two major services: tokenizer and proxy

19


Credit Card Vault – Tokenizer

1. HTML form is served from App server

2. The information provided by the user is sent directly to the vault by the browser (running JavaScript code from App)

3. The vault issues a token that maps to the credit card number

4. The browser sends the token and other non-sensitive information to App server

App server Vault

Browser CC #CVV

submit

1 2

4 3


Credit Card Vault – API request proxy

• This assumes that 3rd party service’s API is HTTP based

• Vault acts as a HTTP proxy with token to CC number translation

1. App server sends a HTTP request via Vault

GET /auth?cc=token:1234&amount=4.00

Host: api.visa.com

2. Vault substitutes token:1234 with real CC number and relays the request to Visa

GET /auth?cc=4444000012344321&amount=4.00

Host: api.visa.com

3. Visa processes the transaction and responds with a transaction id

4. Vault passes Visa’s response back to app

App server 3rd partyi.e. Visa

Vault1 2

4 3


Credit Card Vault – Key Encryption

• Encrypt cardholder data using highest-grade standards (e.g. AES-256)

• Standard mechanism is to use a global key

• But what if key is compromised?

• Instead take a multi-layer approach

• Master key + per-card key

• Cardholder data stored in one DB

• Per-card keys stored in another DB (and managed by a separate team)

22


Credit Card Vault – Token Generation

• Token = 64-bit unique id, maps to cardholder data

• Exposing last 4 CC digits in app is common use case, try encoding into token, e.g.

• Token: 1304274640000970420

• Last 4: 0742

• Even though cardholder data cannot be reverse engineered based on token, better safe than sorry! Encrypt token in response back to app server.

• payload = {“token” => “1234”, “info1” => “abc”, “info2” => “def”}

• message = {“payload” => aes_encrypt(payload), “aes_iv” => “09...AF” }

• output(json_encode(message)) 23


Credit Card Vault – Other things to consider

• 2FA to physically access datacenter (password + handscan)

• Additional firewall layer in front of CC Vault

• Backups stored remotely for disaster recovery

24


Thank You!

• We’re Hiring!

• Eddie Lim ([email protected])

25

Technology

TrialPay Security Tech Talk at Stanford ACM