<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 1/18/19 10:14 AM, Simon Van Casteren
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC0+czq8m0G_DzNwCg8PzqzA11X0U4qTZpz4rXn1-1qgGoFCDg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">When a person logs in, username-password style, I
make a cookie with this form:
<div><br>
</div>
<div>{ Role: <ADT, admin or not basically></div>
<div>, Email: string</div>
<div>, CreatedOn: time}</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
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).<br>
<blockquote type="cite"
cite="mid:CAC0+czq8m0G_DzNwCg8PzqzA11X0U4qTZpz4rXn1-1qgGoFCDg@mail.gmail.com">
<div dir="ltr">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?</div>
</blockquote>
<p>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 <a
moz-do-not-send="true" href="https://github.com/urweb/world">the
Ur/Web World library</a>, 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.</p>
<p>Passwords are just a sordid business, so best to avoid or at
least push off onto some other web service, IMO.<br>
</p>
<blockquote type="cite"
cite="mid:CAC0+czq8m0G_DzNwCg8PzqzA11X0U4qTZpz4rXn1-1qgGoFCDg@mail.gmail.com">
<div dir="ltr">
<div>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?</div>
</div>
</blockquote>
<p>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.)</p>
<p>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.<br>
</p>
</body>
</html>