1
$\begingroup$

We have a classic web application, and when a user sign in, we return a session token (UUIDv4). The user can choose if the session should expire when the browser/app is closed or if he prefer to always be connected (1 year at least).

If an attacker get the session token, I want a way to mitigate the possibility to uses it.

A solution could be to also add a One Time Password in each API client call. On the server side, if the session token is correct we also need to check that the OTP is good.

We uses micro-services in FaaS/workers where the CPU time is limited, it's why we also search the fastest method to verify an OTP.

Which kind of OTP could I use please? I suppose HOTP isn't good because of the nature of TCP/IP where some requests couldn't be correctly acknowledged and de-sync the counters from the client / server. I suppose TOTP isn't good too because the client time is not necessarily in sync with the server (or, we also need to send the current client time, but I'm afraid this creates a bias in the protection )

[EDIT] May be my question wasn't precise enough, so I've posted my idea of a One-Time-Password based on HMAC + SHA1 + timestamp: https://security.stackexchange.com/questions/268882/protection-against-user-session-attacks-hijack-replay-tampering-csrf-xss

If you have a better suggestion (faster OTP verification / better session protection), I invite you to share it.

$\endgroup$
7
  • $\begingroup$ The goal is to have a second factor in each API call, and this 2nd factor need to be recalculate in the client-side before each call (depending of a secret shared with the server side) $\endgroup$
    – lakano
    Commented Mar 2, 2023 at 13:22
  • $\begingroup$ What's the point of having a session token as well as the OTP? $\endgroup$
    – knaccc
    Commented Mar 2, 2023 at 15:23
  • $\begingroup$ @knaccc The session token is returned to the client after a successful sign in ( login/password ) and permit us to known who is it, his authorizations and even to revoke the token when needed. It's the classic scheme of session token of web application. The one-time password is a key is a 2nd layer of security in case of MITM interception, as our session token could be stored for long time, we increase the risk of interception of the session token. But if the attacker got it (or even the last OTP), he can't uses it because he don't known the shared-secret to create the next OTP. $\endgroup$
    – lakano
    Commented Mar 2, 2023 at 15:32
  • $\begingroup$ note UUID is designed to be unique, not designed to be unguessable. A random number from a secure PRNG could be much better from a security perspective. $\endgroup$
    – Meir Maor
    Commented Mar 3, 2023 at 4:31
  • $\begingroup$ @MeirMaor First, thank you for your typo corrections in my post (I'm still learning english). About your suggestion of random number, the Crypto interface of browser seems to have a PRNG suitable for cryptographic purposes named getRandomValues(), and also propose a randomUUID() function that in theory uses getRandomValues(). The v4 UUID includes 122 bits of random values. Do you believe it's not safe enough and I should uses 128 bits of random values only? $\endgroup$
    – lakano
    Commented Mar 3, 2023 at 9:12

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.