[Cryptography] Basic auth a bit too basic

[Watson Ladd]

On Sun, Feb 7, 2016 at 8:56 AM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> On Sat, Feb 6, 2016 at 10:58 PM, John Gilmore <gnu at toad.com> wrote:
>>>> It would be technically straightforward for browsers to have a logout
>>>> button that forgets the auth credentials for the current page, or to
>>>> invent an HTML meta tag that tells browsers to forget auth credentials
>>>> for the current page's domain (give or take the same cross-domain
>>>> issues with cookies.)  The fact that nobody's done either suggests
>>>> that it's not a big problem in practice.
>>
>> Well, the fact that Firefox hasn't done it means that the job has been
>> outsourced to the a popular extension.  Cookie Monster has a menu item
>> for it (pop-up menu -> View Cookies -> Delete Cookies for
>> example.com).  It also lets you delete cookies more generally, as well
>> as providing easy ways to set recurring policies like "For sites I
>> haven't otherwise mentioned, never accept cookies", "Never accept
>> cookies for the site I'm currently viewing", "Always turn all cookies
>> into session cookies for this site", or "Accept cookies temporarily
>> from this site, then after this session, go back to not accepting
>> them."
>>
>> [Are there are any "auth credentials" other than cookies that are used
>>  by more than a tiny fraction of web sites?]
>
> The major one that I see is with company intranet sites using
> Integrated Windows Authentication (SPNEGO, Kerberos, NTLM,
> maybe others). IWA is an "always on" type of authentication.
> The danger with that is there session timeout doesn't really protect
> you from things like XSS and CSRF attacks because even if the
> current session has timed out, you just get assigned a new session.

Logging out doesn't really help. Let's consider this hypo.

I find that corporation A is using an insecure product B where a CSRF
or XSS attack will lead to me getting credentials I want. Problem:
people rarely log into product B, as its some sort of payroll/tax
system that gets checked maybe once a year by most employees.

Solution: phish. Send an email asking them to click on a link to check
their direct deposit information. The link redirects their browser to
correct website, so it looks exactly right. I have however thrown up a
popunder that will start mounting the CSRF attack. Eventually the
victim does log in.

Importantly I have to solve this problem regardless of whether
sessions are expiring, or people aren't logging in often.

For XSS if the XSS is reflected users will be prompted to log in.
Typically this will result in a redirect to the original URL, causing
things to work again. It's not 100% guaranteed that you can evade
this, but roadbump not locked door.

>
> And even if you tell your browser "stop ending the Authentication:"
> header for this particular site, it will automatically redo the negotiation
> again. AFAIK, the only effective logout mechanism here is to kill your
> browser.
>
>> In general, Firefox maintainers seem to take the attitude that it's OK
>> if Google, Facebook, and NSA can track you everywhere you go on the
>> web.  Fixing that seems much less important to them than making sure
>> that every website everywhere always works the way the third-party
>> designers intended -- even when the designers were malevolent (or
>> merely ignorant and manipulated by one of the big tracking companies).
>> Extensions that plug into Firefox, like NoScript, Cookie Monster,
>> Privacy Badger, Request Policy, RefControl, etc, are willing to break
>> some web sites in return for giving the *end user* control over who is
>> tracking them.
>
> I think Firefox takes the assumption that if you are only concerned about
> tracking, then you can use Private browsing windows and for anything
> else, there are plug-ins or add-ons. This probably is a good thing as
> Firefox is already extremely complex.
>
>> Merely getting rid of your browser's Referer headers by default will
>> eliminate a large amount of tracking, while breaking only a tiny
>> number of sites (that require Referer to defend against cross-site
>> scripting, a foolish idea since Referer lines are easy to spoof).
>
> You probably meant CSRF rather than XSS. That is much more common,
> although as you point out, still largely ineffective. As far as ditching the
> Referer headers, it really doesn't seem to break all that much. I've seen
> corporations with transparent proxies at least block Referer headers
> pointing at their internal sites. So, if done judiciously--e.g., block the
> Referer header unless it refers to the same site as the destination site,
> it likely won't break anything.
>
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
> NSA: All your crypto bit are belong to us.
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.