[CentOS] what percent of time are there unpatched exploits against default config?

Fri Dec 30 10:40:55 UTC 2011
夜神 岩男 <supergiantpotato at yahoo.co.jp>

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.