Improve server authentication flow

[infinisil]

As mentioned in #34, the demo server currently has some problems which make it unsuitable to copy from for an actual website server:

• Because it stores whether users are authenticated in memory, restarting the server logs out every user
• Because this state is looked up via the session id, which is stored as a temporary client cookie, the user closing their browser logs them out
• And because there's no cleanup of session state, memory is leaked

We can fix this by:

• Using random tokens to be stored by persistent client cookies and storing those tokens in the database on the server side for each user, indicating the sessions that are authenticated.
  • This also has the nice property of being able to implement allowing users to see all the sessions they're logged in with and revoke them
• Storing whether a user has begun registration or login in the client script directly (which is happening already), and signing it
  • This can be nicely implemented using JWT, for which there is a great Haskell library jose, which we're already using anyways

[lykahb]

I see the demo server more as extended documentation, rather than a template for production. Fixing the session issues would make it larger and less focused on illustrating proper usage of haskell-fido2.

What do you think of adding a readme.md for the demo server with a list of caveats instead?

[infinisil]

@lykahb I think it would be valuable to have this because:

• The way this is currently handled makes the code actually more complicated. If we move the ephemeral state to the client we can remove the dependency on STM and remove essentially all in-memory server state
• Programmers generally want to reuse existing solutions. If we provide a good example in the library we can save a lot of work for other people. Especially for single-person developers that just want to add secure authentication to their website
• It feels wrong to create a secure library but an insecure example
• In the future we could move reusable components of the example into the library itself for convenience
• It turns out that implementing this properly actually requires some additional requirements from the library which we previously weren't aware of

[infinisil]

I guess regarding complexity, both the current way and the proposed way have some, but it took me a lot of time to understand the current code, and I believe it would be a lot easier to understand with the proposed way.

[lykahb]

@Infinisil I completely agree that the current code in the demo is complex and takes a lot of time to understand. I see the current state as an awkward one between a minimal server that only illustrates the usage of the library (ignoring the rest of user management), and a ready-to-use template. It has too many other things going on to be the former, and is not solid enough to be the latter.

In my last comment I had the former case in mind. But evolving it in either direction would be an improvement. If this change simplifies it too, that'd be great!

[infinisil]

I just took a good look at the whole problem of session storage, here's some notes:

• The Webauthn spec requires a cryptographic challenge for registering and login operations
• Both these operations make an initial request to the server to ask for a cryptographic challenge, which they then send along once they have a result. Note that

  [The challenge] MUST be randomly generated by Relying Parties in an environment they trust (e.g., on the server-side), and the returned challenge value in the client’s response MUST match what was generated.

• The current demo stores this challenge on the server with a custom session storage implementation. It looks up the session with a session id stored as a client cookie
• The web server that the demo uses does not support any session storage on its own
• Different Haskell web servers have session storage support, but in different ways:
  • Yesod uses clientsession, which stores the whole session state encrypted and signed in a client cookie, making the server stateless
  • Spock implements server-side session storage
• The problem with a stateless server, using client side session storage, is that in this context it allows replay attacks. The spec explicitly mentions to store the challenge on the server:

  This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the Relying Party SHOULD store the challenge temporarily until the operation is complete.

• So while it is tempting to use Yesod's session handling, that can actually compromise the security of Webauthn to some degree (depending on your threat model).
• So the current solution is actually pretty decent, but we need to fix the problem of memory leaks (which can currently easily be exploited by just generating a ton of challenges)
• We should change the name of this state, as it's not really a session state (which is implied to be longer-term), but rather an intermediate state to join together two requests to the server

[infinisil]

Work is in progress for this to be fixed in #42

[infinisil]

Done with above PR