[Ur] Securing sessions in Ur/Web

[Adam Chlipala]

On 1/21/19 2:22 AM, Simon Van Casteren wrote:
> 1. Yeah after some experimentation I understood the builtin cookie 
> security mechanism is there for XSRF attacks only. That's why I made 
> my own cookie forgery protection by hashing the contents of the cookie 
> and always checking that digest when reading the cookie. I feel that 
> that is pretty safe (and much faster than always hitting the database) 
> since the only problem I can think of with that is somebody actually 
> getting a hold of the cookie itself, but once that happens you're 
> pretty much screwed anyway?

You're right that this seems to be a classy use of crypto to optimize a 
protocol while maintaining security!

> 2. Agreed on the password business. The authentication part of my 
> application is not final, but at the moment I'm supporting two 
> methods. One, which is the preferred one, is via email: You input your 
> email, I send you a email with a (limited time) authentication link, 
> you click it and you're authenticated.

That's a rather insecure method, actually.  I'm not sure whether I like 
it more or less than passwords!  There are many possible attack points, 
especially for users on WiFi via untrustworthy access points.

> I also still plan to provide sign in via Twitter / Google / Facebook 
> but haven't had the time to implement them yet (all of them take quite 
> some time to implement). The more of these I get implemented, the more 
> I'll hide the username-password route.
>
> All of these sign-in strategies can probably be packaged up as nicely 
> as with the GitHub example you've implemented. A ready made directory 
> of authorization strategies should be available at some point for the 
> Ur/Web community, much easier to use that in any other language, exciting!
Yeah, that's my goal with the World library.  Several providers use 
OAuth (like GitHub does) and are thus quite easy to add, since OAuth is 
factored out into a separate module.
> However, the way how to authenticate is orthogonal to the 
> authorization part and how I save that in cookies/DB tables, but point 
> well taken.
True, but World does handle that part, too, behind the scenes.  (It 
happens to store hard-to-guess session IDs in both cookies and DB. I'm 
only talking here about the GitHub module, the only full one implemented 
to date.)
> One thing I did think was nice about environment variables was that I 
> could pass a different key to each of my server processes. I run a 
> seperate Ur/Web server for each of my clients, so if one key gets 
> compromised, it doesn't affect the others.
I generally compile a separate server binary for each client, leaving 
open the possibility of configuring even more at compile time.  I have a 
separate config.ur file per client, sometimes set up with a configure 
script.