Re: [GSoC] Development of Cuirass.

["pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>]

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. :)


By the way, your plans for Cuirass sound great. Thank you!

Regards,
Florian

[1] https://wiki.openstreetmap.org/wiki/OAuth