Re: [xwiki-devs] [proposal] Add support for secet token verification

On Mon, Mar 8, 2010 at 6:06 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: Exactly. Which is why a cookie containing key-lengths and expiration times that would make it impossible to inject bad data, via replay, man-in-the-middle or other attacks used to subvert submitted form data, and thereby potentially breach security, rights, authentication, or access control. Of course, I'm assuming SSL/TLS to begin with, so that man-in-the-middle, replay and other such attacks can't be done. Without that, even with digest-auth, it's just security through obscurity, providing extra hoops to jump through and extra layers to break, without actually securing anything. In other words, digest-auth doesn't help. SSL/TLS does. Essentially what we're looking for is a solution that prevents a replay attack with form data. How are you going to do a replay attack and generate a one-time (or short lived) cookie whose key-length would take the age-of-the-universe to brute-force decrypt deterministically (and you'd have to recompute this age-of-universe-length brute-force decrypt every few seconds). Furthermore, what if the cookie contained some out of band data, such as nonces to digitally sign (in javascript) the returning form data to prevent the cryptocookie from being captured and replayed along with bogus form data? Alex mentions "make users authenticate themselves each time theywant to edit a page, which is quite inconvenient for a Wiki." -- this is certainly not what I'm talking about. There's no reason to re-auth for each edit, perhaps re-cookie, but not re-auth. Cookies by definition work cross-site, otherwise how would you implement cookie-nets? Of course browsers can be set to prevent this; those with super-strict cookie blocking might need to make an exception, which they'd need to do anyways for many sites given the pervasive use of cookies integrated with multisite access. If you've been using Java for the last decade, chances are you've been using some of the ones I architected or setup alongside SSL. http://en.wikipedia.org/wiki/Digest_access_authentication#Disadvantages has some interesting insights on why you made the right choice in not doing digest-auth in Xwiki: Disadvantages Digest access authentication is vulnerable to Man-in-the-middle attack; for Some servers require passwords to be stored using reversible encryption. Kerberos or SPNEGO authentication, primarily employed by Microsoft Secure Remote Password protocol (preferably within the HTTPS / TLS layer). HTTP+HTML Form based authentication Which brings us back to traditional form-auth solutions using SSL and crypto-cookies: http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication -- note that digest auth isn't even worth the trouble Digest access authentication is vulnerable to Man-in-the-middle attack; for Security with holes like that isn't really security -- it's just obscurity. -- Niels, http://nielsmayer.com