True and that mostly doesn't happen. The bigger issue is a data security breach where the bad guys get hold of tons of encrypted information in one fell swoop. Now, you can take advantage of time and programs like Hashcat to decrypt at relative leisure. And since most people use the same username and password at multiple sites, all that's necessary is a good program to ramble around the internet randomly entering usernames and passwords at banking and retail sites until--boom!

Sophisticated hackers are like good burglars and robbers. If they get your credit card information, they may not directly use your credit card but instead use the information they obtain to open another account that you're not aware you have--until you get the first month's bill for $10,000.

This doesn't resolve OP question but for everyone else, recommend enabling two tier authorization whenever available. In theory, the only way to access/login, even if pw cracked is to steal your phone.

The particular example he's giving is of recovering a password from a file, where the password is hashed into something like an encryption key using a standard algorithm. If you've stolen the file, you can then recover the passwords using various mechanisms.

There are various levels there, but the speed of brute-force lookup you can do on a file of password hashes exceeds the theoretical network rates -- it's not simply a matter of slowing things down, even a site with no blocking mechanism is going to only be able to do a few tens of thousands of login attempts per second on a single account, and as you say, adding some kind of throttling and lockout is pretty easy.

By contrast, if you've got the file locally, you can try depending on the example, up to nearly a trillion and a half possible passwords per second. The encryption type matters a lot, though -- the best algorithms are about 1,000 times slower to test per http://hashcat.net/oclhashcat/ and there are other techniques that can slow down the test rate by a roughly equal amount.

That's still at least a million tests per second locally, something that's virtually impossible against any kind of individual public network endpoint unless you've got an entire botnet at your disposal (and maybe not then -- and a million failed logins in that time frame are going to register on someone's console even at a site like Facebook or Google.)

the only protection is being inconvenienced and building VERY large passwords with mixed characters, and the only way to manage this is with Keepass or Lastpass and with a long passphrase and make sure you don't have malware on your computer such as keyloggers.

Two tier authorization is nice for some apps, but for Google I tried it and it was so onerous that I had to turn it off.

You misunderstand how passwords are cracked. Professionals crack passwords off-line, not on-line.

> GRC Password Haystacks ...

The tools that estimate password strength are ... crap.

According to one popular password strength meter, BandGeek2014 should
take 74+ centuries to crack; another estimated six [6] years. Big spread, eh?

Reality: Hashcat cracked it in less than 90 minutes.

12 characters and no symbols. Still better than "starwars" or "password" though :D. How fast does Hashcat do 20 random multi symbol types? Just for my personal interest ;)

... and how does it know it has cracked it, if it reads gibberish on every iteration?

Google is probably one that I would use the two tier system. For 'trusted' devices, once you do it the initial log-in, usually don't ask again unless you clear cache/history/cookies. And there's always the authenticator app as backup to getting a text message to smartphone.

Other sites I use include amazon, eBay, PayPal, iCloud. POV ;)

Cracking passwords, in that sense, works backwards.

You have a hash (examples here) and try different passwords until you generate the matching hash value.

Of course, you need a dump of passwords first.

If it's going to be single-factor authentication, more complex passwords are more difficult to circumvent than biometric passcodes.

Biometric passcode locks are not all that difficult to circumvent, even as it would tend to localize the password circumvention at first. For example, there are people who have used their sleeping/hung-over roommates' fingers to access the data of phones that get unlocked by a fingerprint. And there have been examples of people using photos -- even of fingerprints -- to access devices locked with biometric passcode.

That helps, thanks ^

Since we are really talking about an offline brute force cracking it presumably means that length and mixed character types are the only thing that will take time and slow up the attacker? Hence my query about 20 letters, so that
!1234567890.Abcdefgh Is a magnitude smaller than !1234567890.Abcdefghi
and therefore much less secure?

I am really trying to gauge how long it will hold back the attacker so that changes could be made if the hack became public!

How long?

It depends on many factors:

Length
Randomness/entropy
Hashing algorithm
System salt
User salt

Whenever hashing passwords, it is imperative to choose an algorithm that is resistant to hardware acceleration.

Fast hashing algorithms that are insecure: MD5, SHA1

Fast hashing algorithms that are secure, but should not be used for passwords: SHA2, because it is easily accelerated.

Slow hashing, secure algorithms that are resistant to hardware acceleration: bcrypt, scrypt or PBKDF2

MANY sysadmins are epic failures when it comes to getting these matters precisely correct.

That is helpful to me too, but stretching my subject knowledge now!

Does that mean that even if I choose a 20 digit multi character password all this can be affected and degraded by the way that the website operator chooses to encrypt the password before they store it? Some methods being harder than others to crack?

Exactly.

So the real problem is that sites use weak encryption on sensitive files!;)