2014-02-15 09:27:46.953164+00 by meuon 2 comments
I like "Basic Auth" (over SSL), especially when it's 4am and I'm trying to kludge some DES mycrpt cookie magic into a bogus authentication method so someone can use an overdesigned <form> style login page "like everyone else". The idea of trying to convey authentication information across websites (pseudo securely) via cookies and server to server cross checks is insane.
[ related topics: Net Culture Clowns ]
comments in ascending chronological order (reverse):
#Comment Re: made: 2014-02-16 19:29:16.313737+00 by: dexev
How does Basic Auth protect you against CSRF attacks?
#Comment Re: made: 2014-02-17 03:45:52.438934+00 by: meuon
I barely know how a CSRF works although I've actually used some of those techniques in a SCORM API used for learning management systems across different domains/urls. In each CRSF attack I know of personally, they are abusing cookies or remote controlling another open browser window. In the case of cookies, "Basic Auth" wins, because cookies are not involved, the credentials are not stored in an easily snarfable place in a decent browser. But if you have some code running in Window A, or as an application (trojan) that can "robot" or proxy Window B (on the important site), nothing will save you.
In "Juice" (which uses basic auth) we constantly see probes from other systems that people are logged into while using Juice, often via Facebook or something attached to Facebook. Sometimes something related to nastier sites. They show up in our dashboards and reports as failed login attempts, and after a small number of failed logins, we block the source IP's. When I run analysis.. (we log -everything-) I find these other systems hit the server with cookies captured from a live Juice session... but never with the Basic Auth credentials. Probably possible to grab from a truly compromised system, but not just from a cookie snarfer. I know it's possible to capture the Simple/Basic auth credentials from the live data stream via HTTP (done it), and that it is possible but much much harder via HTTPS (not done it), but I have yet to see it in the wild.
On my best installs, I have issued client SSL certificates and control access that way as well.. We also limit users to known IP address ranges. But our core application is a limited user application.
So, I think it's better, but it is still smart to do the normal things you would do to limit CSRF. Special cookies per session and IP.. (which break when they come from many IP addresses like on many mobile networks), referrer header checking..