"pelzflorian (Florian Pelz)" <[email protected]> writes:
> On 03/12/2017 07:41 PM, Mathieu Lirzin wrote: >> Hello Florian, >> >> "pelzflorian (Florian Pelz)" <[email protected]> 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
