[CentOS] what percent of time are there unpatched exploits against default config?
夜神 岩男
supergiantpotato at yahoo.co.jp
Fri Dec 30 10:40:55 UTC 2011
On 12/30/2011 02:33 AM, Ljubomir Ljubojevic wrote:
> I like to use serial numbers from MB, HDD, etc., as passwords. I never
> use normal words for my passwords, and few other users (with ssh/cli
> access) are carefully checked for their passwords.
>
> If this formula is true "(1/2 . 2 ^ 54 . 1s / 10)" for 9 *random*
> character password, then 0.5 * 18014398509481984 /10 gives
> 900719925474099 seconds to crack it, or 10424999137 days per attacker.
>
> If you use denyhosts or fail2ban, attacker needs 10,000 attack PC's that
> never attacked any denyhosts or fail2ban server in recent time.
>
> So for army of 10,000 attacker PC's, bruteforce ssh needs 1042499 days,
> or 2856 years to crack it. Is this correct figure?
>
Unfortunately, no, it is not a correct number.
There are a few situational variables that have to be considered to
really assess the security of a password, and theoretical best-case
entropy is only a small part of that.
If, for example, you login remotely using a password that has to cross
an untrusted network you should expect that it is being sniffed. Now
this is less a problem because it should be encrypted. The situation is
the same for local Windows or Linux logins -- all systems I know of
encrypt passowords for storage by default, which isn't much different
than how simple password encryption works across the network.
There is a problem with this, however. The password, however long, is
reduced to a fixed-length hash in most password encryption schemes.
Because of the wonders of modulo mathematics the total set of possible
hashes is a lot less than the total set of possible passwords. What this
means is we can start attacking the algorithm itself, in preparation for
trying to decrypt intercepted data (of any type that falls under a
signature/hash type scheme, not just passwords).
We can start a 10,000 computer botnet (or, more realistically, a 10m
computer botnet these days, and this is a technique used right now)
working on the problem of assembling a new index table that orders and
assigns every possible valid hash said algorithm can produce, and start
assigning values.
Essentially, we can move the computing cost up-front by assuming that we
indeed *do* have to try *every* possible password, which means computing
done 5 years ago applies to your brand new password today.
Something weird about the way encryption algorithms tend to work is that
as you move through the list of possible hashes you find large spans of
values that are impossible to actually arrive at given the set of data a
user can enter. You can move those to the side, and this massively
redudces the work load (but its something you can't discover until
you're well into building the hash index, which might be a year or so).
You can also start with targeted hash indexing, meaning you first run
through every possible dictionary word, then every variant of, then
every possible combination of, then every possible combination with l33t
substitutions, then any data set that you can scan from external sources
(meaning things people might see and decide to use as a password that
isn't in the dictionary, which is the category your S/N scheme falls
into...), all of the above with numeric insertions (4, 2 and scattered
single digits are most common, so focus on those), names of companies,
etc. Going this route you can can about 99% of average user passwords in
about a month. This is how John the Ripper works, in a nutshell -- it
has a hash index of pre-checked phrases in a myriad of different hashing
schemes and just checks the hashed password against the index to locate
the list of possible correct ones, which is a pretty short list.
Anyway, to keep from getting into too much math, just consider that
password cracking is not only based on entropy of the password, and the
concept of passwords encrypted for transit or storage has been around
long enough that has tables exist for a vast number of common algorithms.
If you are only logging on locally *and* you are nearly certain that
nobody has access to your password storage, then you're just fine. Most
users who don't spend time using IE to surf unsavory websites and click
on everything those websites has to offer are safe from this. People who
log in remotely, however, face a different challenge. People who login
to a web interface using a password have a SERIOUS problem, in my
opinion, because HTTP cannot be secured, and some websites (even banks!)
sometimes don't have a public HTTPS, but force the user to use a
HTTP->HTTPS redirect, which makes securing it literally impossible.
Blah blah. I'm glossing over some details here and there are as many
different cracking scenarios which involve their own weaknesses as there
are systems.
In short, keys, man, keys. Its not perfect, but it is much stronger than
passwords and in my experience FAR much less hassle.
-Iwao
More information about the CentOS
mailing list