Well, in the beginning I developed a view (that futurely would expand to a set of views) that needed authentication, but users wouldn't authenticate directly via a login form - they would be redirected from an authenticated area of my client's website. So we came up with the idea of a secure authentication token that could transmit the relevant login information from their website to mine. Actually my view came to be embedded in an iframe in my client's website, so I came up with a GET-only solution. I'm no security specialist and I thought that was good enough for the time... So in that case the only security improvement I can imagine is using JavaScript to negotiate the login with a POST request... but I would still need to mix tokens and cookies - are there better ways to do that?
At the time I did some quick research but did not find any 'ready' token generation method so we developed our own; the cleartext contains a timestamp, the login data and a secret, then it is AES-encrypted and base64-encoded. But thanks for the pointer on JWT, I'll study it better :) Thanks for your reply :) On Friday, July 17, 2015 at 2:28:21 PM UTC-3, Vincent Catalano wrote: > > Hello Eduardo, > > After looking over your code, I think there are some major security > concerns with how you are handing user authentication. It looks like you > are attempting to mix two different types of authorization and > authentication techniques, token and cookie based. Although a token based > approach is feasible, and depending on your application may the proper way > to go - I use it in a number of my apps - there are a few security concerns > that need to be taken into account. Is there a specific reason you need to > authenticate users with a GET request? If so, I would highly recommend > using something like JSON Web Tokens (http://jwt.io/) and using a > different approach to authenticating your uses. > > If you want a bit more direction on how to implement this approach, let me > know. > > -Vincent > > On Fri, Jul 17, 2015 at 2:24 AM, Oliver <[email protected] <javascript:>> > wrote: > >> Access Tokens in the query string seem insecure to me since they persist >> in server log files... >> >> On 17.07.2015 07:55, Eduardo Dobay wrote: >> > Hello all! I've been thinking of a way I could create an >> application-wide handler that would authenticate a user when a >> > token is present in the query string (...?token=XXX). I ended up with >> two approaches and would like to know if either of >> > them is preferred in Pyramid, or if there is any problem with the >> solutions I came up with. So here goes (at the end >> > there's a link to a demonstration project I uploaded to Github): >> > >> > 1. Authentication via request handler and redirect >> > >> > Seems like the shortest code: a request handler checks for the `token` >> GET parameter and, having found it, pops it and >> > emits a redirect to the same URL with that parameter removed, also >> saving the login cookie with `remember`. Seems good >> > and simple, but an additional request is made due to the redirect. >> > < >> https://github.com/edudobay/pyramid-auth-example/tree/9c3539406edf84ecda9585b4c19f4d38401eec44#authentication-via-custom-policy >> > >> > 2. Authentication via custom policy >> > >> > To avoid this extra request, I ended up subclassing the default >> AuthTktAuthenticationPolicy and adding extra >> > functionality that checks for the `token` parameter. In this check I >> add a callback that will use `remember` to include >> > the necessary headers in the response. I needed to add a new field to >> the Request object — and I don't know if this is a >> > good practice — to save the username (read from the token) allowing me >> to pop the `token` from the GET dictionary — >> > otherwise the callback would be re-added every time the property is >> read. >> > >> > Concerning this added field, I found this example of @reify while >> searching through the discussion list, but not sure it >> > suits my needs, or even if it does any improvement in my case... >> > http://plope.com/static/pyramid_cookbook/authentication.html >> > >> > --- >> > The demonstration: >> > >> https://github.com/edudobay/pyramid-auth-example/tree/9c3539406edf84ecda9585b4c19f4d38401eec44 >> > --- >> > >> > Thanks so much! >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "pylons-discuss" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to >> > [email protected] <javascript:> <mailto: >> [email protected] <javascript:>>. >> > To post to this group, send email to [email protected] >> <javascript:> <mailto:[email protected] <javascript:>>. >> > Visit this group at http://groups.google.com/group/pylons-discuss. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/pylons-discuss. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Vincent Catalano > Software Engineer and Web Developer, > (520).603.8944 > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
