Are passwords obsolete ?

[Michael O'Dell]

there are two primary cases to consider:

(1) compromise of cleartext credentials
and
(2) exhaustive brute-force attack against
compromised encrypted credentials

If the cleartext of the credentials is compromised,
the length or alphabet choice is irrelevant - they have the credentials.

Note that some of the biggest data breeches have involved the loss
of cleartext credentials. I have personally had banking credentials
compromised in cleartext form.

In the case of brute-force attacks, at first glance, one would think “longer is better”,
and it is to some degree. Exactly how much better, though, is harder to say.
If the attack is against a single target without access to the encrypted credentials, 
then the larger the search space the longer it takes and longer is certainly better.

If, however, the encrypted credentials are compromised (exfiltration of an encrypted
password file, for instance), then the ready availability of massive computation resources
coupled with extremely large memories and storage has transformed the viability of
large-scale “dictionary” attacks.

In a dictionary attack, the list of potential passwords is generated and each password
is stored with its encrypted text version(s) and is indexed. Knowledge of the password 
algorithms commonly used makes this easier than it might first appear.
An attack on a single encrypted password is then simply a lookup in the index.

This kind of structure is potentially amenable to significant compression using techniques
such as Bloom filters. They are inherently ambiguous, but it could reduce the brute-force
search for a single password to a few hundred strings.

This assumes that the underlying crypto algorithms have not been directly broken.
Most password “encryption” algorithms are in fact crypto-hashing functions which
are simply compared for equality with another hash function and the encrypted
credential is never actually decrypted. This could make the algorithms susceptible 
to research results successfully cryptanalyzing certain important crypto-hash functions.

The worse news is that given the computing performance available today using
GPUs, a pure brute-force attack on passwords *without* significant dictionary-based
aiding is certainly possible - the question is how much patience it requires.
10 thousand dollars of hardware could try a very, very large number of passwords
in a very reasonable amount of time.

So yes, “long is better” is certainly true, but how much “protection” that buys 
is very much a function of a specific attack, what was compromised, and how.

as for long usernames, I’ve never seen any research results that suggests
they provide any significant protection, certainly nothing like long passwords.

one other point - changing passwords frequently is valuable in only one case:
if credentials have been compromised, the change invalidates them. HOWEVER,
the first act in any penetration is to install backdoors that render such changes
irrelevant.

the old saws about guessability of passwords doesn’t matter in the case of 
large-scale compromise. there are much more efficient ways to get them all
than fooling around trying to guess each one of them. the obviousness of passwords
*does* matter greatly in the case of a direct attack against a specific account.

again, however, most attacks against systems these days use different attack
vectors which are successful *without* coming up with privileged passwords.

	-mo




On Aug 29, 2014, at 3:32 PM, Andre Kesteloot <akesteloot at gmail.com> wrote:

> Mike,
> 
> OK, but what do you think of the author's suggestion to use long (24 characters) user-names and passwords (until we find something more "deploy-able", e.g., cheap and secure ) ?
> 
> 73
> André
> 
> 
> On Fri, Aug 29, 2014 at 12:15 PM, Mike O'Dell <mo at ccr.org> wrote:
> 
> Passwords have been obsolete for at least three decades now.
> 
> the only problem is finding something better that's as readily
> deployable.
> 
>             -mo
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://amrad.org/pipermail/tacos/attachments/20140829/6ad589dd/attachment.html>