Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test Server should keep track of nonce #13

Open
martindale opened this issue Jul 6, 2014 · 5 comments
Open

Test Server should keep track of nonce #13

martindale opened this issue Jul 6, 2014 · 5 comments

Comments

@martindale
Copy link
Contributor

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

@darkblue346
Copy link

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
Copy link

illuzen commented Aug 6, 2014

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
Copy link

@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
Copy link

illuzen commented Aug 7, 2014

@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
Copy link
Contributor

braydonf commented Jan 7, 2015

@martindale is this still relevant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants