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.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
