Re: [GSoC] Development of Cuirass.

[Mathieu Lirzin <mthl@gnu.org>]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On 03/12/2017 07:41 PM, Mathieu Lirzin wrote:
>> Hello Florian,
>> 
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> 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
>>>
>>> https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication
>> 
>> 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