On Mon, Mar 8, 2010 at 6:06 PM, Sergiu Dumitriu <[email protected]> wrote:
First, as Alex said, cookies are not an option since CrossSite requests are valid, normal requests, and they will use the correct cookies.
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.
Second, I already analyzed the possibility of using digest authentication instead of basic (for WebDAV for example), and that's not possible with XWiki, since it requires access to the plain text password. With the current way that passwords are stored (as any object property), it would be too unsafe to do that.
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 intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.
In terms of security, there are several drawbacks with Digest access authentication:
Many of the security options in RFC2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC2069 mode.
Digest access authentication is vulnerable to Man-in-the-middle attack; for
example, a MitM attacker could tell clients to use Basic access authentication or legacy RFC2069 Digest access authentication mode. To extend this further, Digest access authentication provides no mechanism for clients to verify the server's identity.
Some servers require passwords to be stored using reversible encryption.
However, it is possible to instead store the digested value of the username, realm, and password.[1]
Alternative authentication protocols
Some strong authentication protocols for web based applications include:
Public key authentication (usually implemented with HTTPS / SSL client certificates).
Kerberos or SPNEGO authentication, primarily employed by Microsoft
IIS running configured for "Integrated Windows Authentication".
Secure Remote Password protocol (preferably within the HTTPS / TLS layer).
Weak cleartext protocols are also often in use:
Basic access authentication scheme
HTTP+HTML Form based authentication
These weak cleartext protocols used together with HTTPS network encryption resolve many of the threats that Digest access authentication is designed to prevent.
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
Many of the security options in RFC2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC2069 mode.
Digest access authentication is vulnerable to Man-in-the-middle attack; for
example, a MitM attacker could tell clients to use Basic access authentication or legacy RFC2069 Digest access authentication mode. To extend this further, Digest access authentication provides no mechanism for clients to verify the server's identity.
Security with holes like that isn't really security -- it's just obscurity. -- Niels, http://nielsmayer.com