Authentication Scheme

[erikzhang]

No description provided.

[igormcoelho]

Amazing path @erikzhang ! It was less than a month ago that @vncoelho and I got a discussion on the matter. Structure looks nice, it would be interesting to provide some example perhaps, with Alice and Bob, and maybe sone contextualization over existing OAuth 2. Neo can certainly be such pioneer, specially with oracle technology.

[erikzhang]

Any comment? @neo-project/everyone

[shargon]

It's good to me :)

[djnicholson]

This requires the authentication server to be stateful. That could be avoided by including a signature for the nonce and timestamp in the request (and requiring that the client provide the signature in the response).

[erikzhang]

If the server is stateless, how to identify the clients?

[djnicholson]

State will definitely be needed to provide any useful authorization (e.g. a table mapping from Neo address to roles and/or other application-specific identity data). I'm just showing an opportunity to remove a database table and to avoid a database write on the initial authentication request (which could become a vector for unauthenticated denial-of-service).

[erikzhang]

If the server does not record the nonce, it will become reusable. We need a mechanism to ensure that when a client is successfully authenticated, the nonce is immediately invalidated.

[djnicholson]

It would be good to mention here that the server is required to prevent nonce re-use:

When the server receives the response, it should check whether the nonce has expired. If the nonce has expired or not exists, the authentication fails.

It's currently not clear that this is required and a server implementor might choose to delete a nonce after successful use rather than invalidate it. I'm also curious as to why preventing nonce re-use is required (what security property breaks if the server doesn't do that?)

I'd still lean towards having the nonce invalidation happen post-authentication though.

[erikzhang]

For example, I log in to a website by scanning a QR code. If the nonce can be reused, the second person who scans the code will kick my login.

[djnicholson]

It sounds like the nonce is being used as a session ID? If that is the case there is a vulnerability: Anyone who has observed the QR code can later hijack the session (it wouldn't be safe to use this flow in a room with security cameras, for example).

To mitigate this, the nonce should be swapped for a session ID and this swap should only be allowed to happen once (note that there is still a race condition where an attacker can steal the session, though--to prevent that you need some sort of communication channel from the phone back to the browser).

[erikzhang]

The nonce is a one-time random number. There should be a nonce to sessionId mapping table on the server side.

[igormcoelho]

This requires the authentication server to be stateful.

This is an interesting point @djnicholson, I need to study more on authentication. But perhaps, one way of not storing these nonces is to have some good pseudo-random algorithm, such as mersenne twister on server, starting with some secret seed, and then strongly hash mersenne twister outputs (via SHA-256, for example) to generate the nonce. The good thing is that, as long as some timestamp is involved, server can re-execute seeding process to find the nonce, instead of storing it. The bad thing is that, as soon as seed is leaked on server, nonces could be predicted.
Is it Neo servers or other servers that require being stateful?

[chenzhitong]

Rename nonce to UUID?

[chenzhitong]

To prevent site A from using site B's QR code to trick you into logging in. We should add the website name to the Challenge payload. When you scan the code, you will be prompted with "You will be logged in to **** website". It's like having the website name in the SMS verification code.

[chenzhitong]

Do we need to add an expiration timestamp to the Challenge payload.

[chenzhitong]

How the server gets the authentication refused/cancel message? Add State in Response data, include scaned, confirmed, refused, to optimize user experience?

[erikzhang]

If the authentication is cancelled, the server won't receive the response payload. So nonce has an expiration time, and it is recommended to be 5 minutes.

[djnicholson]

To prevent site A from using site B's QR code to trick you into logging in. We should add the website name to the Challenge payload. When you scan the code, you will be prompted with "You will be logged in to **** website". It's like having the website name in the SMS verification code.

The challenge payload will also need to be signed by the website (or the attacking site can just modify it)

[erikzhang]

Rename nonce to UUID?

It's not UUID. It is a one-time random number.

Do we need to add an expiration timestamp to the Challenge payload.

I don't think it's necessary.

[erikzhang]

To prevent site A from using site B's QR code to trick you into logging in.

In QR mode, there is a callback field. The client should show the domain of the callback url to the user. And the user can verify whether the website they are logging in is the domain name.