Test Server should keep track of nonce

[martindale]

As per #12, the included test server should reject requests that that do not correctly include a nonce.

[darkblue346]

I looked at the code today after seeing the korben post, wondered a little time about the treatment of nonces, was about to send a mail to [email protected] then saw this already has an issue. So posting here instead.

Could you also provide a clean treatment for nonces ? I don't feel it's an easy task. For example, Client Side : how do you choose the nonce to send from the client side, so that it won't be rejected by the server ? How to do so from multiple browser tabs ? Once you have resolved the two above problems : How do you keep the nonce small (so that you can compare and store it fast ? ) If you make the nonce finite size, how do you handle the finite size of the nonce (once there are no more nonce ? (new SIN creation ? )

Server Side How to store the nonce ? It seems to me that we need a transactionnal (no mongo here, or traditional session no-sql store) persistent store. How can we use this with a distributed architecture ? Does "bitauth" break REST architecture ?

Additional note (my current view of the problem ): It seems to me that bitauth is just (not) implementing a nonce mechanism over standard Elliptic Curve Cryptography authentification. It seems to me it doesn't implement "perfect forward secrecy", so that for me : using bitauth < encrypting with ECC an http request then sending this request over SSL < over SSL : using ECCDH to create a temporary session key from stored public keys then using this keys to encrypt with and http request then sending < NOT DOING CRYPTOGRAPHY IN JS IN THE BROWSER until there is proper browser module support.

[illuzen]

Why don't we forget having the client pick the nonces?

• User requests access
• Server issues nonce challenge
• User signs nonce, returns signature and public key
• Server checks signature, checks if public key / SIN is allowed access to requested resource

Maybe I'm missing something, but it seems like we could get away without having to remember anything for longer than a session (just issue a new random number), and it avoids the possibility of someone intercepting a previous signature for a higher nonce and using that to login.

[darkblue346]

@snakecharmer1024 It's almost a month since I looked to bitauth, so I may have not understood you. Even if "User requests access" is encrypted, it is still subject to replay attacks. And it seems your solution need one more round-trip every time, which will have to be handled by the common developper.

[illuzen]

@darkblue346 Ok I think I see what you mean. Like this?

• User requests access over SSL
• Server issues nonce challenge
• User signs nonce, sends signature and public key
• Attacker intercepts message and resends it, gaining access
• User is unable to access due to attackers access

Is that roughly what you mean? This stuff is challenging to think about clearly.

[braydonf]

@martindale is this still relevant