2-Factor Authentication with PASOE June 2017 Cameron David Wright & Mike Jacobs Progress

Agenda Introduction to “Two-Factor Authentication” The Technology The Client Side of Things The Server Side of Things Putting Everything Together in One Amazing Demo

Introduction to “Two-Factor Authentication”

When Single Passwords Are Not Enough… Single Factor Authentication (1FA) using a single user-id & Password are easily broken Something you know ( password ) Two Step Verification (TFA) is stronger but not by much A server challenge that is cannot be automated Two Factor Authentication (2FA) is stronger than Two Step Authentication Something you have ( phone, e-mail account, token, app, ...) Something you are ( dna, fingerprint, ... )

Two Factor Authentication Is Not Perfect Two Factor Authentication is still susceptable to some attacks Credentials theft: phishing, eavesdropping, man-in-the-middle (MITM) Weak credentials: vertical & horizontal password attacks Session: Session riding, session fixation Trojan & malware: compromised clients on VPN Password reuse: allowing same password for multiple levels of data access

Two Factor Authentication Process Client Registers device Generate / record client secret & device info Password Authenticated? Client Password Login Reject Send 2FA code to registered device Wait for code Code Authenticated? Client reads 2FA code from device, sends code Reject Proceed

Anybody can make 2FA code work… The challenge is to make it work securely

The Technology

Getting the Technology, Design, & Implementation RIGHT Client registration in encrypted database columns A [strong] source of user accounts for 1st factor authentication ( AD, LDAP, … ) One-time Passwords (OTP) for the 2FA code All OTP have an expiration time and limited number of retries Encrypted OTP column storage Secured back-Channel ( aka out-of-band ) second factor device plug-ins

Getting the Technology, Design, & Implementation RIGHT HTTPS is THE ONLY option for 1st & 2nd factor transmission Fail gracefully – ALWAYS ( you will be hacked ) Surrender NO information that can be used by a hacker ( failure code & “it failed” ) Server side logging can be enabled for every 2FA phase success & failure Don’t forget multiple asynchronous client requests

The Client Side of Things

Client-side : Web static artifacts (UI) You NEED Webserver – to serve up static pages jQuery – ties everything together HTTPS - secures your connection You WANT - to make everything look pretty Kendo UI Bootstrap Font-awesome

Client-side : 3 Page design Page 1 – Registration Provide your user credentials (username@domain) Select response type (Email, SMS) Provide response address (email address or mobile phone number) Page 2 – First Factor authentication User credentials (username@domain) 1st factor secret (password) Process REST call Page 3 – Second Factor authentication 2nd factor secret Spring security post

Client-side : Process flow Collect user credentials (username@domain) and password Submit to REST call to initiate login 200 – prepare for 2nd factor 302 – redirect if no registration exists 401 – error with credentials Collect user credentials (username@domain) and one-time-password Submit to Spring security 401 – error with 2nd factor credentials 302 – redirect on successful login to main page

Client-side : It is that simple Yeah but what about my legacy application? OpenEdge.Net.HTTP.* These class libraries can be used just like a browser to make your web and spring security posts Create an HTTP Client Create a URI object Create a request object Execute the request Process the response Rinse and repeat for both factor authentication If you attended 277:Everyday OOP made easy with Chad Thomson, you are ahead of the game

The Server Side of Things

2FA Implementation Design User-id password Spring Security BASIC XXXX authentication Client Registration Service Interface Client Registration object Primary User Accounts User-id password Spring Security BASIC XXXX authentication 1st Factor Authentication Web Handler 1st Factor HOTP push object 2FA Authentication Policy object challenge (HOTP) Overall 2FA process design The design takes into account: Load balanced servers Using a 2FA process as a service Using a 2FA process by WEB, REST, & AppServer clients Leverages Spring Security for the strong authentication process execution & Role based access to the application’s data & operations Explore each of the parts in next slides 2nd Factor Authentication Realm object User-id challenge Spring Security FORM OERealm authentication Data Service Service Interfaces Application Data Services Progress

2FA Implementation Design: Database Storage ClientRegistration ID Active OERealmID RegID Registration-date LastAccess Out-of-band-type OOB-address OOB-ID … TwoFactorPolicy Policy-name Active Factor2-expires Loginctx-expires OOB-Types OOB-Media-type HOTP-step HOTP-value-size HOTP-algorithm … LoginContext ID Connection-ID Login-State Login-Date Logout-Date Lockout-start Principal (aka Client-Princpial ) TwoFA-OTP … Policy based implementation – where the policy is the configuration & single point of 2FA process control TwoFactorPolicy table includes Can have multiple policies by name ( default: “default” ) Information for generating One-Time-Passwords based on installation policies Information for which types of OOB devices the installation will accept use of and which ABL classes support those devices Contains cleanup information for controlling the automatic/manual removal of completed 2FA login ClientRegistration Registered user ID based on a Spring Security primary account authentication Has private secret-key for generating One-Time-Passwords unique to the user Has description of which type of Out-of-Band device type to use to push the 2nd factor OTP & what their address is Foreign key’d to some enterprise level user acount ID LoginContext Tracks the 2FA process, results, and troubleshooting information Key’d by registered user ID Contains state, relevant date-times, & the Client-Principal issued by the 1st factor’s user account login Progress

2FA Implementation Design: Client Registration User-id password Spring Security BASIC XXXX authentication Client Registration Service Interface Client Registration object Primary User Accounts Cannot require using 2FA specific user accounts Need an means to store 2FA specific information for any external user accounts Controlled self/controlled registration and stored in database Progress

2FA Implementation Design: 1st Factor Authentication Primary User Accounts User-id password Spring Security BASIC XXXX authentication 1st Factor Authentication Web Handler 1st Factor HOTP push object 2FA Authentication Policy object challenge (HOTP) On error return 401 & { “error” : “authentication failed”, “details” [ “username and password do not match” ] } Obtains sealed Client-Principal from Spring authentication to primary account Find active client registration using hCP:Qualified-User-ID Check max concurrent logins Generate OTP using decrypted client registration secret Create 2FA login context and store in DB hCP:Qualified-User-ID Encrypted OTP Expirations Raw Client-Principal State: START Return 200 and body: { “oob-type” : “…” } Progress

2FA Implementation Design: 2nd Factor Authentication & Data Access 2FA Authentication Policy object Uses Spring Security authentication & Role based authorization processes Uses FORM type security because OTP can only be passed to the server ONCE OERealm Spring Security authentication plug-in used to validate the 2FA login process state and challenge Uses Client-Principal from 1st factor authentication to supply the user account information for the Client-Principal generated by the 2nd factor authentication process Use the policy object for the single integrated process control for login process tracking and data storage On error return 401 & { “error” : “authentication failed”, “details” [ “username and password do not match” ] } Executes OERealm server class for 2FA Find active client registration using hCP:Qualified-User-ID Find 2FA login context by user-id & ‘START’ state Obtain 2FA login context’s Client-Principal & return Qualified-User-ID Roles Properties Validate OTP with encrypted 2FA login context value If fail, increment retry count If success, remove 2FA login context 2nd Factor Authentication Realm object User-id challenge Spring Security FORM OERealm authentication Data Service Service Interfaces Application Data Services Progress

2FA Authentication Policy object 2FA Login Process Flow 2FA Authentication Policy object ( sets state ) Validate 1st Factor User-id & password f1Authenticated f2Challenge One-time-password challenge Push 2nd Factor Challenge unauthenticated f2Expired Validate 2nd Factor f2Failed User-id & challenge f2Authenticated terminate 2FA login User-id – cancel login Admin – terminate login terminated Process starts in f1Authenticated state after 1st factor authentication success for registered user Generate OTP & push to client’s registered device & address If push fails, return to unauthenticated state to allow starting the 2FA process again If push passed, move to the f2Challenge state and wait When 2nd factor arrives – validate it Find registered, active, user – if not move to f2Failed state & cleanup login context If timeout – move to f2Expired and disable further attempts & cleanup login context If invalid challenge – move to f2Failed and disable further attemtps & cleanup login context If Registered user found & challenge matches – move to 2fAuthenticated & cleanup login context Cleanup login context Remove OTP & 1st factor client-principal Record 2FA process complete date-time If the login context record’s lifetime has expired, move it to the cleanup state If the login context is in cleanup state – delete it Cleanup 2FA logins Admin – cleanup cleanup ClientRegistration LoginContext TwoFactorPolicy Progress

Putting Everything Together in One Amazing Demo

Wrapping it all up Using Two Factor Authentication is useful for human direct-logins PAS for OE’s use of Spring Security makes 2FA easier and more secure Follow industry best practices for all ABL authentication process code development To a server all clients are hackers and it must never surrender to persistent attacks Do NOT provide hacker snacks to a client Client developer debugging will be challenging To a client Two Factor Authentication is more challenging to handle the failure cases