On 1/18/19 10:14 AM, Simon Van Casteren wrote:
When a person logs in, username-password style, I make a cookie with
this form:
{ Role: <ADT, admin or not basically>
, Email: string
, CreatedOn: time}
I'm saving the role in the cookie, so subsequent security checks in
the page generators and rpc functions don't need to hit the database.
Actually, that's an insecure method. The Ur/Web implementation is not
meant to prevent cookie forgery! Rather, it just tries to make sure any
side-effecting operation that reads a cookie was triggered by an
explicit form submission within your application (that's XSRF protection).
1. Is this safe? Is this a good solution? Or am I better off
abandoning the whole thing and going back to putting just a SessionId
inside a cookie and going to the database with that SessionId to check
for authorization? Or another solution that I'm not thinking of at the
moment?
Creating a unique and effectively unguessable session identifier to
store in the database is a pretty good solution. Actually, however, I
recommend avoiding implementing your own authentication whenever
possible! You could consider using the Ur/Web World library
<https://github.com/urweb/world>, which is growing in a lazy manner, as
different usage modes are requested. Specifically, it's only been used
for authentication via GitHub, as far as I know.
Passwords are just a sordid business, so best to avoid or at least push
off onto some other web service, IMO.
2. A problem I'm having is storing the key that is needed to run the
digest. My plan was to pass it via an environment variable to my
program, but getenv inside a page generator causes the compiler to
complain, saying that it could cause side-effects... Anybody have any
ideas how to handle this? I feel like putting my key in plain text
inside my source code is not very good, but maybe I'm wrong about that?
I don't see a fundamental security advantage of a sensitive value in a
source file (and therefore compiled into the application) vs. in an
environment variable (and therefore presumably appearing as plaintext in
a script somewhere to set the variable). I would even think there is a
teeny bit of extra security in compiling the key into a binary on a
build machine and then uploading the binary to a server that will only
have the key appearing in the binary instead of a more-easily-viewed
text file. (Of course, even a modestly sophisticated adversary can grab
a password out of a binary.)
However... it was an oversight that the compiler didn't recognize getenv
as having only benign effects! I believe I have fixed that issue now in
the compiler, so please let me know if that method hasn't switched to
working.
_______________________________________________
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
