Brute force password cracking

skyglider

Veteran Member
Messages
7,143
Solutions
21
Reaction score
2,010
Location
US
I've read that using brute force methods, the cracker could have a computer try hundreds of thousands, if not millions of combinations and crack a password. The time to do that is calculated by taking the number of possible combinations and the speed of the computer.

But that doesn't make sense to me. If someone gave the cracker the actual password and he set it as THE PASSWORD TO MATCH in his computer, then had his program try all possible combinations until there was a match, then the time it takes to crack the password would be what they said.

But in actual practice, say the cracker tried a brute force method against my bank. Wouldn't his computer have to try password-1 and have the bank's computer accept or reject it. Then try password-2, etc, etc. This could only proceed at the speed of the bank's online system and line speed. So it seems to me that the brute force software could not run faster than the bank's system and line speed. ---- Plus, wouldn't the bank stop accepting passwords due to too many being tried?

This is not even mentioning that the cracker needs to know the username to even try to crack the password.

What am I over looking in my thinking?
 
Last edited:
Solution
I’m no security expert by any means, but here is the overall impression I currently have.

Brute force attacking is used when a database/file with usernames and passwords is stolen from a web site or system that has been compromised at the administrative level. The password values stored within the database are (hopefully) encrypted in some form or another.

The brute forcing isn’t interactive attempts to gain access to the web site. It is attempts using different combinations of encryption methods and “seed” values to see if they produce the same encrypted value stored in the database. If they do, then you can reverse the process to get the actual password and use it to go back the compromised system and interactively log into it...
They'd have to steal my thumb along with the phone.
I'm not sure how much faith I'd place in the bet that there are no back doors into your phone...
I'll take my chances that the average thief in this area won't know how to open them - even if they exists - which I doubt
Unfortunately, thieves know how to search the Internet too.
Then they would know that there are no back doors
"I'm not sure how much faith I'd place in the bet that there are no back doors into your phone..."

Me either. That must be an unusual phone. Good luck in any case.
Maybe you’d like to share the link that the average thief in my area could find on the internet that would allow him backdoor access into my phone.
After he steals it he'd know what OS to start searching on, depending on the phone's brand. But it's your phone, not mine. Not my problem. Good luck.
 
Last edited:
They'd have to steal my thumb along with the phone.
I'm not sure how much faith I'd place in the bet that there are no back doors into your phone...
I'll take my chances that the average thief in this area won't know how to open them - even if they exists - which I doubt
Unfortunately, thieves know how to search the Internet too.
Then they would know that there are no back doors
"I'm not sure how much faith I'd place in the bet that there are no back doors into your phone..."

Me either. That must be an unusual phone. Good luck in any case.
Maybe you’d like to share the link that the average thief in my area could find on the internet that would allow him backdoor access into my phone.
After he steals it he'd know what OS to start searching on, depending on the phone's brand. But it's your phone, not mine. Not my problem. Good luck.
Yes that’s what I thought.
 
Hi Billiam29,

Thanks for your explanation. Now I understand how brute force cracking works.

So if a person, (say Tom), uses both a master password and a keyfile, then the cracker would have to gain access to Tom's computer and be able to find and extract the keyfile in order to brute force crack Tom's database?

Trying to figure out the angles,
Sky
So here's what I've figured out so far to be safe:
  1. Having at least a 20 character master password using the first letter of a long phrase, or using words from a foreign language not in the dictionary, plus special characters for one's master password will be roadblock 1.
  2. In addition to the master password, using a keyfile that's only stored on the user's personal devices (and not in the cloud) to unlock the database will be a road block 2.
  3. Using a password manager that allows storing its database in the user's personal cloud will avoid being in targeted databases that are stored in the password manager's server. Road block 3.
  4. Since the cracker needs to download the database to try to crack it: --- If one stores their database on their personal cloud, enabling 2 factor authentication (2FA) to that account will be road block 4.
Pretty impenetrable don't you think?

Sky
 
Last edited:
What's a keyfile?
A keyfile is an additional requirement to open one's encrypted database, in addition to the master password.

In some password managers (like Keepass) it can be a random generated file that the password manager can create or it can be any file like a jpg, pdf, doc, txt, or whatever file that the user selects. In other password managers (like Enpass) the keyfile can only be a random generated file that Enpass creates (as far as I know).

Then both the master password and the keyfile are used to encrypt the user's database. So to decrypt the data base BOTH are needed.

If the database is kept in the cloud, the keyfile should NEVER be stored in the cloud. It should only stored on the user's devices. To be extra safe, one could only store the keyfile on a USB drive and plug that drive in only when the user is actually using the computer. However a USB drive won't work on a phone.

To open the encrypted database in the cloud, the user must enter his/her master password and then browse his/her computer/phone to select the proper file that has been designated as the keyfile. Having both, the password manager can then download the encrypted database from the cloud and decrypt it for the user's access.

So even if a cracker manages to download the user's encrypted database, he could not crack the database without having the proper keyfile.

Sky
 
Last edited:
]phone's brand. But it's your phone, not mine. Not my problem. Good luck.
Yes that’s what I thought.
I'm with Aus on this one - you're engaging in a bit of a faith exercise here. Just looking at how often people lose their bitcoin fortunes to their phones, I wouldn't be very optimistic. The phone hacks have become rather impressive.

To the OP: brute force was much more viable in the older days, esp in unix land where the entire encrypted password file was viewable, before people moved away from NIS and toward kerberos and others so the hash wasn't there for the reverse engineering.

As I'm sure you know, these days phishing is the primary method, though sim card cloning plus a small amount of social engineering have provided a second route to getting into an account. If said attacker gets one account with your original password, it's no longer really brute force trying to get into others - they know at least one email address you use, and a password, and odds are decent you reuse the same creds, or something very similar.

Password managers are great for defeating that tendency to reuse, though their max complexity offers a lot less value now that 2FA and quick lockouts are the norm. Malware (key loggers) easily defeat these, and now give a lovely inventory of all accounts you care about. Hence the other poster's suggestion for a local only keystore.

Some people have a lot more to worry about that others. Those who are known to have crypto coins, or perhaps a government secrets rating, or work for a company of key interest - they could be targeted by people with a lot of energy to invest. The rest of us are more vulnerable to the broad sweeping methods, like fish boats dragging nets along the bottom.
 
I've read that using brute force methods, the cracker could have a computer try hundreds of thousands, if not millions of combinations and crack a password. The time to do that is calculated by taking the number of possible combinations and the speed of the computer.

But that doesn't make sense to me. If someone gave the cracker the actual password and he set it as THE PASSWORD TO MATCH in his computer, then had his program try all possible combinations until there was a match, then the time it takes to crack the password would be what they said.

But in actual practice, say the cracker tried a brute force method against my bank. Wouldn't his computer have to try password-1 and have the bank's computer accept or reject it. Then try password-2, etc, etc. This could only proceed at the speed of the bank's online system and line speed. So it seems to me that the brute force software could not run faster than the bank's system and line speed. ---- Plus, wouldn't the bank stop accepting passwords due to too many being tried?

This is not even mentioning that the cracker needs to know the username to even try to crack the password.

What am I over looking in my thinking?
Generally password cracking works by:

(1) Running through a list of 30M++ common passwords and variations and seeing if any encrypt to the same thing. This is for salted hashes.

(2) Using Rainbow Tables, where people with lots of bots (hacked computers) have simply encrypted every possible password up to a certain complexity and stored the answers in tree-structure in a NAS full of multi-terabyte drives, they then just look up the encrypted password to see what the plain-test one was. For unsalted hashes (you can also do #1 if you don't have the resources for this).

Really anyone would only try to brute force your password if you were a squillionaire or had the codes to self-destruct ICBMs in flight (although they'd probably just do a black bag job on your home in that case, and install a keylogger).
 
Last edited:
Really anyone would only try to brute force your password if you were a squillionaire or had the codes to self-destruct ICBMs in flight (although they'd probably just do a black bag job on your home in that case, and install a keylogger).
Yes, it's easier for hackers to wait for a lame company such as Yahoo to lose 3 billion account passwords, and then buy a list of them on the black market. Probably some users never changed their passwords after the breach, even after it was announced years later.

Anybody know how this happened? Was Yahoo storing unencrypted passwords?

Google is less lame than Yahoo, but didn't they also lose G+ accounts? Not to mention most of the credit reporting agencies, who lost info that can be used for identity theft.
 
Last edited:
Really anyone would only try to brute force your password if you were a squillionaire or had the codes to self-destruct ICBMs in flight (although they'd probably just do a black bag job on your home in that case, and install a keylogger).
Yes, it's easier for hackers to wait for a lame company such as Yahoo to lose 3 billion account passwords, and then buy a list of them on the black market. Probably some users never changed their passwords after the breach, even after it was announced years later.

Anybody know how this happened? Was Yahoo storing unencrypted passwords?

Google is less lame than Yahoo, but didn't they also lose G+ accounts? Not to mention most of the credit reporting agencies, who lost info that can be used for identity theft.
You can store passwords in plain text... oops

You can store hashed passwords... but a night comparing them to the results of encrypting a list of common passwords means 90% oops... then using Rainbow tables means 98% oops...

You can salt and hash them in which case its just the people with passwords on the lists of common ones (and a huge bunch of possible variations) who are screwed... okay that's most people...

As to losing passwords that's a combination of new and unexpected attacks being discovered plus humans running stuff and making mistakes. A bit like thinking you could drive 500 miles a day for a year around a city without anyone crashing into you. Might happen, but don't bet your house...

Use a different password everywhere. Make it decently complicated...
 
Last edited:

Keyboard shortcuts

Back
Top