secure login procedure

Question

I am considering two login procedures, both via HTTPS GET API:

procedure A:

Reuqest:

https://host/login?id={identity}&time={client_timestamp}&nonce={ramdon_string}&sign={signature}

Response:

{"stat": 0, "token": "token_string"}

Where:

• id: identity of the request client, which is public (a hardware identity printed on label)
• time: unix timestamp of the client, which must be in-sync with server clock (with allowed error about +/- 5 minutes). This is added to prevent replay attack.
• sign: an hmac-sha256 of nonce+time+<shared-secret>. nonce is saved at server-side for a period of time, within which re-use of same nonce is not allowed.

procedure B:

Request:

https://host/login?id={identity}

Response:

{"stat": 0, "token": "encrypted&base64 encoded token"}

In this scheme:

• server will generate a token (if id is valid), encrypt <token><salt> with shared-secret using AES cipher.
• server will lookup cache to prevent re-encrypt of same token. The cache will be valid for a period of time to save server CPU resource.
• client will decrypt the token using shared-secret and use the first N byte as token (token length is pre-defined).

My question is, considering that the channel is HTTPS, encryption key is pre-shared, which procedure is considered more secure, and why? Thanks.

Answer 1

They're equally safe. HTTPS is designed against most MITM-related attacks, including replay attacks, so the only thing you have to ensure is that your client has the pre-shared key.

For the first method, it is ensured by the HMAC hash. For the second one it is ensured because only the client can decrypt the token.

However, storing keys reversibly on a server is not recommended because your server might be hacked. This can be solved by storing the hash of your client key on your server with some secure password hashing algorithm(bcrypt, PBKDF2, etc).