Request Pricing
En
Request pricing

Login

Credential theft: Defense techniques

Defense against reuse of stolen credentials with mobile device binding relies on using device keys to establish connection.

When a new client device is enrolled in the system, it generates a key pair - a private and a public key. The public key is shared with the server and the private key is written to the device TEE. TEE (Trusted Execution Environment) such as Android KeyStore or iOS Keychain guarantees that the generated private key can’t be extracted from the mobile device.

Subsequently, every authentication request is signed using the device key. The server will inspect whether the signature was made with a  key that corresponds to any user’s device already enrolled. If the device is unrecognized, the authentication request shall be refused.

fun onLoginClicked() { showLoading("Logging in…") // Step 1: Ask server for a challenge val challenge = requestChallenge() // Step 2: Sign challenge with keystore val signature = signWithKeystore(challenge.number.toByteArray()) // Step 3: Send user authentication payload, challenge + signature to server val resp = login(userAuthenticationPayload, challenge.number, signature) // Step 4: Handle response val token = resp.sessionToken storeSessionTokenSecurely(token) toast("Logged in successfully") }

If your user authentication payload is always the same (e.g. if this is the username + its password), then the previous code example won’t protect you against replay attack. The attacker can intercept the authentication payload & its signature & replay it since it doesn’t change.

There are many possible ways to harden the basic authentication flow against replay attacks. One of the techniques that is used often - either in conjunction with other techniques or standalone - is a challenge-response technique.

A random one-time challenge, initiated by the server or an independent third party, prevents replay attacks, making generated payloads effectively one-use. The diagram below provides an example of a simple challenge-response flow implementation. 

The goal of this example is to demonstrate the key principles behind replay protection. We advise not to implement authentication protocols yourself, and instead refer to authentication standards.

--- title: Challenge-response --- sequenceDiagram actor User participant Keystore participant Mobile app participant Server User->>Mobile app: Login Mobile app->>Server: Requesting challenge Server-->>Mobile app: Challenge number <1234> Mobile app->>Keystore: Sign Authentication payload + <1234> Keystore-->>Mobile app: Signature Mobile app->>Server: Authentication payload + Signature Server->>Server: Verify the Signature Server-->>Mobile app: Session token Mobile app-->>User: Logged in successfully

// Code example illustrating the challenge-response interaction // Both server and client are done in pseudocode to illustrate the key concepts and the dynamic of a typical query. // WARNING: Use this example only for education purposes. We advise to use standard implementations in production. // Server code ... router.get('/challenge', defineEventHandler(async (event) => { const challenge = String(Math.random()); // Store the state // For stateful servers - on the server itself // For stateless servers - in an independent storage state['challenge'] = challenge; return { "challenge": challenge, }; })); router.post('/authenticate', defineEventHandler(async (event) => { const body = await event.req.json(); const authenticationPayload = body['authenticationPayload']; const challenge = body['challenge']; const signature = event.req.header['X-Signature']; // Verify if the challenge value is intact if (challenge != state['challenge']) { return NoAccess('The challenge value is corrupted'); } // Verify that the signature is correct if (!validateSignature(body)) { return NoAccess('The signature is not intact'); } return authenticate(authenticationPayload); })); // Mobile app code ... fun Authenticate(authenticationPayload: AuthenticationRecord) { val challenge = server.challenge() val payload = BuildPayload.payload( body: BuildPayload.body(authenticationPayload, challenge), ) payload.headers.set('X-Signature', PayloadSigner.sign(payload.body)) val result = server.authenticate(payload) return result }

Residual risk: Protecting the initial device enrollment scenario

This device binding defense technique works only when the device has been previously enrolled in the system. The moment of the device enrollment itself is a point of vulnerability. Prior to the device binding, it is sufficient for the user to provide their authentication credentials to enroll their new device in the system.

At this moment typically applications use the strongest and the most strict authentication, including biometric / KYC authentication. It is critical that the authentication uses methods that are the most difficult to recreate manually and require automation. For example, using facial recognition requires the potential attacker to resort to deep fakes to recreate authentication. Combining mobile device binding with mobile application attestation provides the best results to defend against credential theft during the device enrollment process.


Possible teaser - a code example that uses application attestation

Guardsquare

Table of contents