In comp.security.misc Ivan Shmakov <***@siamics.net> wrote:
>>>>>> Rich <***@example.invalid> writes:
>
> [Cross-posting to news:comp.security.misc, as this article's
> matter is not specific to GNU/Linux.]
>
> [...]
>
> > For password auth, if a proper length, properly random, password is
> > utilized, the space of possible keys (passwords) is already large
> > enough that even with knowledge of the username, an attacker will
> > not guess the password in any reasonable timeframe.
>
> > Sadly, too many folks passwords are much too weak (not proper
> > length, not randomly generated)
>
> I'm actually curious on what recent research says about the
> amount of randomness that one should have in one's password?
Can't comment on specific research, don't have the citations to
reference.
> (Or, to put it other way around, how simple one password has
> to be for it to be possible to break it in reasonable time
> under one threat model or another?)
Typically, the analysis is comparing the actual threat model to brute
force of the password (brute force will always work, just not in a
reasonable timeframe if the number of combinations to test is
sufficiently large).
So, for some 'brute force' data one has to set some parameters to
measure anything, so lets pick some parameters (math below performed
with 'bc' command):
1) 8 character password (traditional Unix crypt() password length)
2) A system (cpu/gpu/asic) that can test 1 billion passwords per second
A) password selected from the 26 lowercase ASCII letters:
26 letters, with 8 positions, provides 26^8 possible combinations:
$ echo "26^8" | bc
208827064576
So 208 billion possible combinations. But at 1 billion tests per
second, brute forcing that one will take, on average [1] 104 seconds
and at most 208 seconds. So, eight characters, just lowercase, not
secure.
B) password selected from 26 lowercase and 26 uppercase ASCII letters
(total of 52 characters):
echo "52^8" | bc
53459728531456
Doubling the possible number of letters, we now have 53459 billion
possible combinations. At 1 billion tests per second, that will take
26729.5 seconds on average and 53456 seconds worst case. But, 53456
seconds is only 14.84 hours. So this is still insecure.
C) password selected from the 95 'printable' ASCII characters (I'm
including space in the printable set here):
$ echo "95^8" | bc
6634204312890625
6,634,204,312,890,625
Now we have 6.6 million billion possible combinations. Worst case at
1B tries per second is 6634204 seconds. That many seconds works out to
76.78 days. Much more secure than A or B, but still, 76.78 days is not
that long, so even this is insecure.
D) Any possible byte value is allowed as a "password character". So
now we have 256^8 combinations, which works out to:
$ echo "256^8" | bc
18446744073709551616
18,446,744,073 , 709,551,616
If I'm counting correctly, we now have 18.4 billion billion
combinations. Best case (half the time of the maximum) we have
9223372036.5 seconds to find the password. That works out to this many
days:
$ echo "scale=2; 9223372036/60/60/24" | bc
106751.99
And 106751 days is 292.27 years (at 365.25 days per year). For most
humans, a password that will likely take 292 years to find is going to
be largely considered secure (even if it is 8 characters).
This is why all of the literature is always hammering on "longer
passwords" and "use more of the possible letters/characters/bytes".
Increasing the number of possible letters/bytes in use, and/or the
length (updating the math above for a longer password is an exercise
left for the interested reader) is the most effective way to thwart
attacks. And 'random generation' of the password is the easiest way
for humans to "use more of the possible letters/bytes" available as the
password value.
[1] reason is that a brute force attempts will, on average, need to
only try 1/2 of the possible space when attacking large numbers of
different passwords. Any given single password will take whatever
number of tries it takes.
> For instance, there's an entire class of passwords, such as
> ghjDthrf1 and gf!Hjkm, which, while most certainly /not/ random,
> would require some rather specific assumptions about the targeted
> user to guess correctly in a reasonable number of attempts.
The thing is, systems like jack the ripper that are tuned to password
cracking already have hundreds of possible rule sets to try various
different 'patterns' that humans come up with for creating 'random
looking' passwords that really are not random. And as humans generate
new rule sets, those end up getting added to the jack the ripper rule
sets, negating their general value for adding security.
> The obvious problem with completely random passwords is that
> they generally require some means to store them securely, and
> these means in turn may become both an attack vector and a
> single point of failure.
Yes, but humans are notoriously bad at selecting strong passwords when
left to their own accord (beyond a very few who understand the value of
proper selection of possibilities). A password manager program allows
any given, quite non-random, human to actually create passwords that
are more truly random than anything the human themselves would
naturally create. Having truly random passwords, selected from a large
enough set of possible characters, and of a sufficient length (doubling
the length of the password examples above markedly changes the timing
factors) provides much better security at the small expense of the
password manager being a single point of attack. But, if you, joe
random internet user, are being targeted at such a level that your
attacker is attempting to breach your local system to obtain your
password manager data file (most of these are stored encrypted
themselves) then you are in a whole different level of attack senario
than what most individuals need to protect themselves from. So the
benefits of a manager far outweigh the costs of the manager. Note in
the above I'm only considering locally stored manager files. Those
managers that store one's passwords 'in the cloud' naturally do create
nice attack vectors and single points of failure (because now, instead
of attacking "you" individually, the cracker has to attack "cloud
password manager X" and if successful, he/she obtains passwords for
many users at once. So the payoff vs. risk scale there is weighted
heavily in favor of the huge payoff from the 'cloud storage' managers.
> FWIW, I tend to prefer "word-based" passwords (or even
> "sentence-based"; not dissimilar to, say, 2onEjoy) to random ones.
Single dictionary words are trivial to crack in very short time frames.
Jack the ripper, with a sufficiently long word list, will find a
dictionary word in a very short time frame.
Sentence based ones are better than pure word based ones, but there's
still patterns in sentence based passwords, patterns that can be
formulated into patterns for tools like jack the ripper to test
against. Yes, that increases the time of the attack, but nothing like
how the numbers blow up when the password is based on "any one of the
characters from large set X could appear here" (random generation).
> > that having the username not be easy to deduce does add security for
> > them. But their proper solution should be to "utilize a proper length,
> > properly randomly generated, password" rather than "hide my username".
>
> Another important measure to use is to limit the number of
> authentication attempts per unit of time. Applying a generous
> number of iterations of a message digest function to the password
> already does this, but also using something along the lines of
> fail2ban won't hurt.
You are assuming an online attack. For that threat senario, yes, a
slow down in attempts and/or a fail2ban block will, typically, keep
even a weak password from being 'found'.
But most attacks today are not "online" they are "offline". And those
are where the attacker managers to get an online service to cough up
their stored password data, and the attacker is then free to go
somewhere else (AWS, their 5 GPU cracking box under their desk, etc.)
with sufficient computational resources to try to crack the passwords.
And there a fail2ban or online slowdown is ineffective.
This is the typical attack senario today (offline), which is why a
randomly generated password of sufficient length is the best one to use
(even if doing so requires a password manager and creates a single
point of failure). The user with the password manager's randomly
generated password of sufficient length simply will likely not have
their password cracked by the attacker.
The password manager also gives one additional benefit. It removes the
human incentive (limited ability to memorize 'passwords') to reuse the
same password across plural sites. Each site can have a unique,
random, password, with zero reuse. Which limits the damage should an
attack get lucky and succeed against one of those passwords. Only that
one password, on that one site, is revealed. The remaining sites
passwords are still safe, and the user only has to deal with the mop-up
of that one site. Of course, depending on exactly which site was that
'one site' (i.e., banking site) determines the actual damage the user
incurs.