Agreed, let's take this off-list. If anyone else wants in on the discussion, feel free to email myself, James, or Aaron.
Brendan On Monday, May 19, 2014 9:07:24 AM UTC-4, abedra wrote: > > > On 05/18/2014 09:25 AM, James Reeves wrote: > > I don't want to seem like I'm "badgering" you. You have a lot of sound > ideas. But I don't think we should be trying to work around insecure > designs; we should be making it easier for people to design things securely. > > In terms of *specific* things wrong that I've yet to mention: the > middleware you have won't work for all session stores; only session stores > that create a new session if a key is not found. Ideally session stores > should reject session IDs that don't exist, rather than construct new ones. > > - James > > > After reading this thread I would like to make a couple of quick points. I > think that ring-auth is a step in the right direction and has the right end > goals in mind. To cut past the tension a bit I think that what James is > trying to say is "let's try to make this less confusing and work within the > constraints of the current system". This really isn't a bad idea. In fact, > it is usually the way to succeed as an add-on to a library. I understand > all of the original points made by Brendan and agree with almost all of > them. That being said, I would encourage a little more work here to try and > blend just a bit more. I am happy to take this off list and start a more > productive discussion on how with a smaller group if there's interest. > > - Aaron > > > > > On 18 May 2014 14:06, Brendan Younger <brendan...@gmail.com > <javascript:>>wrote: > >> >> >> On Saturday, May 17, 2014 9:03:01 PM UTC-4, James Reeves wrote: >> >>> On 18 May 2014 00:09, Brendan Younger <brendan...@gmail.com> wrote: >>> >>>> For anyone else following along at home, I'll just re-iterate the >>>> benefits of using ring-auth versus trying to write your routes *just >>>> right* to avoid the myriad security issues listed at OWASP. >>>> >>>> - If you initiate a session with a user over HTTP and later on that >>>> user logs in over HTTPS but you don't change the session id in the cookie, >>>> then everyone at the coffee shop has access to the authenticated session. >>>> Ring-auth protects you from this. >>>> >>> >>> This is true, but I don't think we should be aiming to protect people >>> from doing the wrong thing, so much as stop them from doing it in the first >>> place. >>> >>> You seem to be aiming this middleware at people concerned about >>> security, but not so concerned as to follow best practice. I'm a little >>> baffled by this use-case. >>> >> >> On the contrary, I'm protecting the user from oversights or bugs in the >> webapp. Saying that there would be no security issues if only everyone >> wrote perfect software is a tautology. >> >> >>> >>> >>>> - If you use a CSRF middleware, but at any time leak the session id >>>> cookie over HTTP, then your CSRF protection is broken. Ring-auth protects >>>> you from this. >>>> >>> >>> CSRF protection doesn't matter if your session is compromised. CSRF is >>> a mechanism for sending a HTTP POST with the user's session ID. If you >>> already have the session ID, there's very few reasons why you'd bother with >>> CSRF. >>> >> - If you ever send your CSRF token over HTTP, then the entire coffee >>>> shop can entice the user to "Click here now!" and send money to their >>>> off-shore account. Ring-auth helps you avoid sending the CSRF token in >>>> the >>>> clear. >>>> >>> >>> Hm? How? There doesn't appear to be anything in your code that looks >>> for the CSRF token embedded in the response body. >>> >> >> Because the :csrf-token is only present in the :auth-session, you can >> be sure that if your code has access to the :csrf-token, then it's >> communicating over HTTPS with the user. I could not use ring-anti-forgery >> here because there is no provision to place the token in anything except >> :session. >> >> >>> - If you get a request over HTTP which should have gone over HTTPS >>>> and respond with an error, but don't immediately delete the session, then >>>> everyone at the coffee shop has seen the authenticated session id >>>> (assuming >>>> you forgot to set Secure). Ring-auth protects you from this. >>>> >>> >>> Again, I don't understand the use-case for this. Setting the secure >>> flag on the session cookie is the clearly the better option. I'm having >>> trouble seeing how you'd present this in your project's README. >>> >>> >>>> - If a user closes their browser on a public computer but forgets to >>>> sign off, the next user can go back to the site, and hopefully the browser >>>> has cached the cookie giving them access to the first user's account. >>>> Ring-auth will help prevent this as soon as the "Cache-Control" header is >>>> set. >>>> >>> >>> A session idle-timeout isn't necessarily a bad idea, though again this >>> could be implemented as middleware on top of the existing session >>> middleware. >>> >>> I'm not sure what bearing the Cache-Control header has in this case. >>> >> >> The Cache-Control header instructs proxies and the like to not cache >> the Set-Cookie header. See section 4.2.3 of >> ftp://www.ietf.org/rfc/rfc2109.txt. >> >> >>> - Not to mention the helpful errors that try to help you develop >>>> secure routes with warnings when you're doing something obviously insecure. >>>> >>> >>> This isn't a bad idea. >>> >>> >>>> None of these things come out-of-the-box with Ring's wrap-session, >>>> even with {:secure true} set. >>>> >>> >>> No, and I agree that there are definitely pieces of middleware that >>> could help, but I disagree on how ring-auth currently goes about it. >>> >>> Improving Ring's security is a laudable goal, but it's also something >>> you need to be very careful with. Rather than building on existing >>> infrastructure, such as the secure cookie flag or the existing wrap-session >>> middleware, you're building your own ad-hoc systems. This is not a good way >>> to build secure software. >>> >> >> Yes, you've repeated yourself several times on this subject. However, >> at some point you need to engage with the code that is actually present in >> ring-auth rather than repeating the abstract goal of building on existing >> infrastructure (which ring-auth mostly does). All it does is replace the >> logic in wrap-session mainly because wrap-session doesn't have a way of >> regenerating session identifiers. >> >> You keep repeating that best practices for Ring sessions are to set the >> secure flag, have unguessable session identifiers, don't use the same >> cookie for secure and insecure sessions, etc. except that none of these are >> the default in Ring and have to be thought through individually by >> developers. Saying that it's their own fault if they somehow miss one of >> the things on the list is not helpful. >> >> Ring-auth implements the OWASP suggested measures for securing sessions >> all in one place, makes choices about things like generating the session >> identifier where there is an obvious right choice from a security >> perspective, and tries to catch common bugs or misconfigurations where >> possible. It's clear you have philosophical differences regarding how it's >> implemented, but unless you have some specific point about the security of >> ring-auth, I would ask you to stop badgering. >> >> You have a lot of sound ideas, but any library that purports to >>> improve security needs to be very carefully considered, and should be held >>> to a far higher standard. >>> >>> - James >>> >>> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
