[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC] Development of Cuirass.

From: Mathieu Lirzin
Subject: Re: [GSoC] Development of Cuirass.
Date: Mon, 20 Mar 2017 23:05:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

"pelzflorian (Florian Pelz)" <address@hidden> writes:

> On 03/12/2017 07:41 PM, Mathieu Lirzin wrote:
>> Hello Florian,
>> "pelzflorian (Florian Pelz)" <address@hidden> writes:
>>> On 03/12/2017 03:49 PM, Mathieu Lirzin wrote:
>>>> Sensitive requests should be done with an
>>>>   authentification mechanism which is not determined yet.  I currently
>>>>   have no experience with any and lack the knowledge to properly choose
>>>>   one.
>>> I’m new to Guix and Scheme and no expert in Web programming, but in
>>> order to prevent CSRF and in order not to rely on JavaScript, the server
>>> should run with HTTPS (of course) and
>>> · use a secret session token and
>>> · send a customized Web page to the client adapted so that each link and
>>> form to the server includes the session token as a GET or POST parameter.
>>> An alternative is Basic Access Authentication with HTTPS or Cookies with
>>> HTTPS but they are vulnerable to CSRF.
>>> See stackoverflow, for example
>> Thanks for your input.
>> Have you any experience/advice regarding OAuth or Json Web Token (JWT) ?
> Sorry, I have no experience with these. I think I’ve basically
> understood what OAuth is for after reading the OSM wiki, [1] but I’m not
> sure what you want to use it for.
> I assume the following scenario:
> The user wants to log in.
> · The Cuirass Web server would receive the log-in credentials as POST
> parameters from an HTML form.
> · Now it needs to check whether the password is correct, e.g. by looking
> up the salt stored for the supplied username, computing the bcrypt hash
> of the supplied password and stored salt and comparing it to the stored
> bcrypt hash for the user name.    ← This requires Cuirass to store a
> table containing user names, salts and bcrypt hashes. Do you intend to
> use some OAuth / OpenID / whatever thing to outsource the log-in
> management to an “identity provider”? I presume you don’t.
> · You generate a secret session token shared between server and client
> which you
>   — embed in each link and in each form you send to the client as part
> of the session and
>   — can verify the session token on the server.    ← I did not know
> about JWT, but from a first glance it seems very appropriate for this
> use. Instead of storing on the server which sessions are still active,
> the token stores all information about the log-in and its content is
> encrypted with the server’s secret key. This seems like a great idea,
> also there maybe is (or should be) a library to manage JWT. I learned
> something today. :)

I need to do my homework before being able to go further in this
discussion.  Thanks for you analysis.

Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

reply via email to

[Prev in Thread] Current Thread [Next in Thread]