Message-ID: <646661981002251526k45de80e1m275b995f0bbd4158@mail.gmail.com>
Date: Thu, 25 Feb 2010 15:26:39 -0800
From: Sai Emrys <sai@...zai.com>
To: Dan Kaminsky <dan@...para.com>
Cc: tips <tips@...hcrunch.com>,
	full-disclosure <full-disclosure@...ts.grok.org.uk>,
	news <news@...register.co.uk>, liz <liz@...aom.com>,
	Lance Wantenaar <lance.wantenaar@...yjet.com>
Subject: Re: EasyJet is storing user passwords in the clear

On Thu, Feb 25, 2010 at 2:57 PM, Dan Kaminsky <dan@...para.com> wrote:
> That's 20% with a work effort of effectively 0 per password with a single
> dictionary.  Spend a few minutes of brute force on each pass and the success
> rate grows.

Of course. Which is why I said it depends on what you consider "minimal". ;-)

> A SQL Injection hole *is* the compromise. This says, given the compromise,
> the work effort is somewhat lower than it might be.  The dependency chain is
> clear.

IMO it's relevant not because it would result in worse compromise of
EasyJet data - although if it's a surreptitious attack it'd allow
normal login as the user, which could have its own problems. (Frankly
I think this is unlikely, as most attackers who matter will only be
looking to do stuff en masse.)

It's relevant because most users are stupid and use the same
username/password everywhere. A nice juicy database of credentials -
with full contact info etc - will surely get reused against banking
websites, etc.

> There is actually something interesting about this work, in that it's a
> really good illustration of the difference between what you can legally look
> for in web apps vs. binaries that sit on a machine that you own.  You hit
> Forgot My Password, and in doing nothing illicit, nothing unusual, you learn
> a deep detail about the backend implementation -- that it stores plaintext
> passwords.
>
> That's good to know, but with the exception of situations where SQL is in
> the URI, we don't get to look for the really scary stuff.  At least, not in
> a legally safe manner.

Which is exactly why I decided not to. ;-)

Since I was already telling them about this underlying issue and got
what could be reasonably be interpreted as some legal threats in
response, I have no intention of doing any gray area testing without a
"get out of jail free" contract. If someone else happens to do so and
tell me the results, I'll be interested, but I think it's probably
better for me to not give their lawyers anything to use.

I also think it's interesting how much one can figure out from a
system with completely innocent behavior, or even from one's *routine*
behavior. There've been 'con presentations (e.g. by Johnny Long) about
how much one can figure out from individuals by innocent observation.
Perhaps a collection of such things against websites or local apps
would be interesting also?

(Also this kinda reminds me of http://www.crypto.com/papers/mk.pdf - a
paper I quite enjoyed. That wasn't *quite* as innocent, but it still
leverages a bit of knowledge to do a remarkably effective attack with
very little exposure and without doing any actions that are evidently
abnormal.)

> The point I'm making is that they could do better, but not that much better.
> Auth is broken, we need to get past passwords, etc.

I think that the existence of other vulnerabilities doesn't mean you
shouldn't still be attending to basics.

Salted hashes done right provide complete protection against password
disclosure and rainbow tables. That's about it, granted. But that's
hardly worthless.

I've not seen anything from you re. a next-gen solution to the other
issues with passwords. Got a paper / post (yours or others') I could
see that elaborates?

Thanks,
- Sai

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists