full-disclosure - Re: EasyJet is storing user passwords in the clear

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <4418BEF8-3411-4639-A389-41F3713328CA@doxpara.com>
Date: Thu, 25 Feb 2010 17:57:59 -0500
From: Dan Kaminsky <dan@...para.com>
To: Sai Emrys <sai@...zai.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 Feb 25, 2010, at 5:44 PM, Sai Emrys <sai@...zai.com> wrote:

> Dan -
>
>>    I see where you're coming from, but what are the most recent  
>> statistics
>> on the effectiveness of hash cracking?  Isn't it something like 70%  
>> of the
>> passwords in the field can be cracked with a minimal amount of brute
>> forcing?
>
> Of course this depends on what you mean by "minimal".
> http://www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf
> claims 20% success with a 5k dictionary based on the RockYou password
> db. Presumably this would be at least somewhat worse with an unknown
> db, since their results are from post hoc knowledge.
>

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.

>>    There are best practices, and there are vulnerabilities.  I  
>> don't think
>> anybody's going to argue it's not best practice to store hashes  
>> rather than
>> plaintext, but lets not delude ourselves regarding their  
>> effectiveness.
>
> Fair enough. As I wrote in a comment on my blog post, the
> vulnerability here is not that EasyJet data would be compromised - if
> this is relevant, that's already happened - but that it would lead to
> easy escalation of the compromise.
>
> Not every vulnerability disclosure is on the level of structural DNS
> issues. ;-) I think that this is at about the level of finding a blind
> SQL injection hole.
>

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.

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.

> Is it an awesome new hack? Hardly.
>
> Is it incompetent of EasyJet, given that it's a large company with a
> lot of users' data? Yes.
>

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.

> 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/