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