Slide 1

Slide 1 text

JULIA POTAPENKO MAKING AUTHENTICATION MORE SECURE

Slide 2

Slide 2 text

JULIA POTAPENKO • Lead iOS Engineer at Stuzo • Security Engineer • Mobile Lead at WWCode Kyiv • Co-organizer of OWASP Zhytomyr • Speaker at OWASP, CocoaHeads, WWCode and WTM events

Slide 3

Slide 3 text

WE WILL TALK ABOUT ★ What can go wrong before you start coding ★ Top common mistakes of iOS engineers ★ Frictionless local authentication

Slide 4

Slide 4 text

BEFORE CODING BEGINS

Slide 5

Slide 5 text

BEFORE CODING BEGINS

Slide 6

Slide 6 text

BEFORE CODING BEGINS your

Slide 7

Slide 7 text

SDLC SOFTWARE DEVELOPMENT LIFE CYCLE Requirements definition Design Development Testing Deployment Maintenance You are here

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

SDLC SOFTWARE DEVELOPMENT LIFE CYCLE Requirements definition Design Development Testing Deployment Maintenance You are here

Slide 10

Slide 10 text

SDLC SOFTWARE DEVELOPMENT LIFE CYCLE Requirements definition Design Development Testing Deployment Maintenance You are here S- SECURE

Slide 11

Slide 11 text

SDLC SOFTWARE DEVELOPMENT LIFE CYCLE Requirements definition Design Development Testing Deployment Maintenance You are here S- SECURE Security training

Slide 12

Slide 12 text

SDLC SOFTWARE DEVELOPMENT LIFE CYCLE Requirements definition Design Development Testing Deployment Maintenance You are here S- SECURE Security training + security requirement + risk assessment

Slide 13

Slide 13 text

SDLC SOFTWARE DEVELOPMENT LIFE CYCLE Requirements definition Design Development Testing Deployment Maintenance You are here S- SECURE Security training + security requirement + risk assessment + threat modeling + secure design review

Slide 14

Slide 14 text

RISKS IT IS NOT ONLY ABOUT MONEY AND HACKERS

Slide 15

Slide 15 text

RISKS • Legal Responsibility • Reputation Risks • Operations Risks • Competitors IT IS NOT ONLY ABOUT MONEY AND HACKERS

Slide 16

Slide 16 text

RISKS • Legal Responsibility • Reputation Risks • Operations Risks • Competitors IT IS NOT ONLY ABOUT MONEY AND HACKERS http://www.enforcementtracker.com/

Slide 17

Slide 17 text

EXAMPLE. USER REGISTRATION

Slide 18

Slide 18 text

EXAMPLE. USER REGISTRATION 1. Enter phone number

Slide 19

Slide 19 text

EXAMPLE. USER REGISTRATION 1. Enter phone number 2. Enter OTP

Slide 20

Slide 20 text

EXAMPLE. USER REGISTRATION 1. Enter phone number 2. Enter OTP 3. Accept TC & PP

Slide 21

Slide 21 text

EXAMPLE. USER REGISTRATION 1. Enter phone number 2. Enter OTP 3. Accept TC & PP

Slide 22

Slide 22 text

“THE PROBLEM IS NOT ON OUR SIDE”

Slide 23

Slide 23 text

OWASP MASVS MASVS (Mobile Application Security Verification Standard)

Slide 24

Slide 24 text

OWASP MASVS MASVS (Mobile Application Security Verification Standard) • ARCHITECTURE, DESIGN AND THREAT MODELING • DATA STORAGE AND PRIVACY • CRYPTOGRAPHY • AUTHENTICATION AND SESSION MANAGEMENT • NETWORK COMMUNICATION • ENVIRONMENTAL INTERACTION • CODE QUALITY AND BUILD SETTINGS • RESILIENCY AGAINST REVERSE ENGINEERING

Slide 25

Slide 25 text

OWASP MASVS MASVS (Mobile Application Security Verification Standard) • ARCHITECTURE, DESIGN AND THREAT MODELING • DATA STORAGE AND PRIVACY • CRYPTOGRAPHY • AUTHENTICATION AND SESSION MANAGEMENT • NETWORK COMMUNICATION • ENVIRONMENTAL INTERACTION • CODE QUALITY AND BUILD SETTINGS • RESILIENCY AGAINST REVERSE ENGINEERING

Slide 26

Slide 26 text

MASVS LEVELS

Slide 27

Slide 27 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 28

Slide 28 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 29

Slide 29 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 30

Slide 30 text

BAD JWT TOKEN EXAMPLE https://jwt.io/

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 33

Slide 33 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 34

Slide 34 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 35

Slide 35 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 36

Slide 36 text

MASVS. AUTHENTICATION. LEVEL 1. Description 4.1 If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. 4.2 If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. 4.3 If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. 4.4 The remote endpoint terminates the existing session when the user logs out. 4.5 A password policy exists and is enforced at the remote endpoint. 4.6 The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. 4.7 Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.

Slide 37

Slide 37 text

MASVS. AUTHENTICATION. LEVEL 2. Description 4.8 Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain. 4.9 A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. 4.10 Sensitive transactions require step-up authentication. 4.11 The app informs the user of all login activities with their account. Users are able view a list of devices used to access the account, and to block specific devices.

Slide 38

Slide 38 text

MASVS. AUTHENTICATION. LEVEL 2. Description 4.8 Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain. 4.9 A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. 4.10 Sensitive transactions require step-up authentication. 4.11 The app informs the user of all login activities with their account. Users are able view a list of devices used to access the account, and to block specific devices.

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

WARNING

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

A BETTER WAY TO DO IT

Slide 44

Slide 44 text

A BETTER WAY TO DO IT

Slide 45

Slide 45 text

WHAT THE CODE LOOKS LIKE IN DISASSEMBLER?

Slide 46

Slide 46 text

MASVS. AUTHENTICATION. LEVEL 2. Description 4.8 Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain. 4.9 A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. 4.10 Sensitive transactions require step-up authentication. 4.11 The app informs the user of all login activities with their account. Users are able view a list of devices used to access the account, and to block specific devices.

Slide 47

Slide 47 text

2FA FLOW

Slide 48

Slide 48 text

2FA FLOW Lets connect the requests

Slide 49

Slide 49 text

2FA FLOW

Slide 50

Slide 50 text

MASVS. AUTHENTICATION. LEVEL 2. Description 4.8 Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain. 4.9 A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. 4.10 Sensitive transactions require step-up authentication. 4.11 The app informs the user of all login activities with their account. Users are able view a list of devices used to access the account, and to block specific devices.

Slide 51

Slide 51 text

DIGITAL SIGNATURE / TRANSACTION SIGNING • Key exchange • Client creates private, public key pair • Private key is stored in Secure Enclave • Public key is sent to the Server • When transaction is initialized on the client side • Client computes hash from transaction data • Client encrypts hash with its private key to compute signature • Client attaches signature to the transaction data and sends to the Server • Server side validation • Server receives signed transaction data from the Client • Server separates transaction data from the signature • Server decrypts signature with public key received from the Client to get hash value • Server computes transaction data hash and compares it to the decrypted hash

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

MASVS. AUTHENTICATION. LEVEL 2. Description 4.8 Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain. 4.9 A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. 4.10 Sensitive transactions require step-up authentication. 4.11 The app informs the user of all login activities with their account. Users are able view a list of devices used to access the account, and to block specific devices.

Slide 54

Slide 54 text

MASVS. AUTHENTICATION. LEVEL 2. Description 4.8 Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain. 4.9 A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. 4.10 Sensitive transactions require step-up authentication. 4.11 The app informs the user of all login activities with their account. Users are able view a list of devices used to access the account, and to block specific devices. Architecture matters

Slide 55

Slide 55 text

OWASP MOBILE TOP 10

Slide 56

Slide 56 text

OWASP MOBILE TOP 10 M1 Improper platform usage M2 Insecure data storage M3 Insecure communication M4 Insecure authentication M5 Insufficient cryptography M6 Insecure authorization M7 Client code quality M8 Code tampering M9 Reverse engineering M10 Extraneous functionality

Slide 57

Slide 57 text

OWASP MOBILE TOP 10 ~ Biometrics M1 Improper platform usage M2 Insecure data storage M3 Insecure communication M4 Insecure authentication M5 Insufficient cryptography M6 Insecure authorization M7 Client code quality M8 Code tampering M9 Reverse engineering M10 Extraneous functionality

Slide 58

Slide 58 text

TOUCH ID AND FACE ID LOCAL AUTHENTICATION

Slide 59

Slide 59 text

LOCAL AUTHENTICATION • Biometry is stored on device as mathematical representation • It is encrypted with a private key stored in Secure Enclave • Biometry data is used by Secure Enclave only • It can’t be accessed by OS or any application

Slide 60

Slide 60 text

SECURE ENCLAVE CREATE AN EXTRA LAYER OF SECURITY FOR YOUR PRIVATE KEYS. • A part of A7 and newer chips • Secure Enclave Processor (SEP) is separate from Application Processor (AP) • SEP has its own OS

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

KEYCHAIN • A database storing encrypted items • Good for storing passwords, tokens, not for files • Each item is protected by passcode/biometry and device secret • Keychain items are available when user authenticates to the device • To work with Keychain specify a particular policy and user message

Slide 64

Slide 64 text

KEYCHAIN • A database storing encrypted items • Good for storing passwords, tokens, not for files • Each item is protected by passcode/biometry and device secret • Keychain items are available when user authenticates to the device • To work with Keychain specify a particular policy and user message WARNING

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

.biometryCurrentSet

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

LONG STORY SHORT ★ Frida + Objection https://medium.com/securing/pentesting-ios-apps-without-jailbreak-91809d23f64e

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

LETS DESIGN A FRICTIONLESS AUTHENTICATION EXAMPLE As a user, when I’m about to pay for the product in the mobile app, I should be prompt to a step-up authentication and my transaction should be secured. REQUIREMENT

Slide 71

Slide 71 text

LETS DESIGN A FRICTIONLESS AUTHENTICATION EXAMPLE • Step-up authentication. Validate user password before sending transaction data • User can enter password or use biometrics instead ▸ To use biometrics we need to store user password in a Keychain ▸ We store user password encrypted with a private key stored in Secure Enclave • Send password to the Backend to validate. If it is correct the Backend will send one-time transaction session token • Secure the transaction. Use session and digital signature • Use one-time session token in transaction request • Add digital signature to transaction data ▸ Use private key stored in Secure Enclave to generate a public key for the Backend and to sign the transactions DESIGN

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

WHERE TO GO NEXT OWASP MSTG – Testing Local Authentication https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06f-Testing-Local- Authentication.md iOS Security Guide https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf WWDC 14 – Keychain and Authentication with Touch ID https://devstreaming-cdn.apple.com/videos/wwdc/ 2014/711xx6j5wzufu78/711/711_keychain_and_authentication_with_touch_id.pdf David Lindner – Don’t Touch Me That Way https://nvisium.com/blog/2016/06/22/dont-touch-me-that-way.html

Slide 74

Slide 74 text

https://speakerdeck.com/julep/ owasp-mstg-in-real-life https://speakerdeck.com/julep/owasp- mstg-when-authentication-goes-wrong OTHER TALKS https://www.facebook.com/julia.potapenko.16 https://t.me/OWASP_ZHYTOMYR_CHAT https://speakerdeck.com/julep/ touch-id-and-face-id-is-it-secure https://www.facebook.com/wwcodekyiv

Slide 75

Slide 75 text

THANK YOU!