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

2. 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

3. Introduction to “Two-Factor Authentication”

4. 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, account, token, app, ...)
Something you are ( dna, fingerprint, ... )

5. 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

6. 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

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

8. The Technology

9. 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

10. 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

11. The Client Side of Things

12. 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

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

14. Client-side : Process flow
Collect user credentials 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 and one-time-password
Submit to Spring security
401 – error with 2nd factor credentials
302 – redirect on successful login to main page

15. 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

16. The Server Side of Things

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. Putting Everything Together in One Amazing Demo

24. 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