What are the chances of Bruteforce or some similiar program being able to crack a password that must be within 4-8 characters long and can contain alpha and numeric characters?
The reason I ask is because the company I work for is having a problem with AIM kids gaining access to passworded products that we sell. The customer sets up thier own passwords, so they are not randomly generated. I am trying to figure out how this is possibly happening and am wondering if they could be BF our website.
Any ideas? Can BF even be used on a webpage?
This is insanely easy. If it’s a 4 char password, let’s assume for the sake of argument it’s alphanumeric. That’s 26 letters + 10 numbers, so 36 possibilities per character. 363636*36 is a little less than 1.7 million combinations. A reasonably fast computer could pull it off in less than a second, assuming it tries ALL combinations. Using a dictionary of english words, I can’t see it taking more than a minute, even if all 8 chars are used.
This is assuming that they actually have to bruteforce the password. I’m not sure which product you’re discussing, but if it’s a protected software product, someone could be distributing a “cracked” version with the password protection removed, or have developed a fake authentication method. I would suggest going to Warez (pirated software) websites and trying to track down the product, and seeing what methods were being used to gain access. This would be the most productive.
As for attacking the website, you could always just check the logs for repeated bad password inputs from a given IP.
I’m not aware of a particular program called Bruteforce, but one attack technique is known as brute force. The technique involves writing a program to systematically try every possible password in what is known as the ‘password space’. However, a quicker method is known as a dictionary attack, which is probably what is happening to you. Since users get to pick their own passwords, they will generally use a word they can remember. The attack program has a dictionary of common words that it trys. To proctect from these types of attacks, the system should be set up to disable the userid once 3 failed password attempts have been made. It is quite easy to write a program to fill in and submit web-based forms.
I thinkPhlip is saying that they have password protected pages on a webpage which unauthorised people are gaining access to.
Is that right ?
How do you know people are gaining access ?
I’ve never heard of a program called BRUTEFORCE but if it does a ‘brute force’ attack (basically try every possible combination of letters/numbers until one works) then it depends on a few factors.
How long the passwords are (on average), how long it takes to do one attempt, whether multiple incorrect passwords are recorded.
It’s more likely people are discovering the passwords some other way, off your server or by guessing likely passwords.
Without a better idea of how the passwords work and how you know they’ve been broken I can’t offer anything further.
SD
On preview I notice everyones said all this already but I’m posting anyway.
Basically, without giving away my company info or anything like that, I believe that they are gaining access to passworded webpages, not to a program. The passwords MUST be between 4-8 chars long.
There is no “stopper” in place to prevent a massive amount of guesses at the pword. I have already pointed that out to the developers.
In that case a brute force attack is less likely because of the time-delay between submitting the password and recieving it. Even doing around 20 passwords a second you’d take over almost a day to do all the 4 char combos. ( I think I’ve got that right )
Either your security has been compromised and they’ve stolen the password file (even if this is encrypted they could brute-force this).
They’ve guessed the passwords (by using common choices, or by knowing personal information about the user and guessing that).
Or they’ve been given the passwords some other way. Maybe a disgruntled ex-developer, some-one registering normally then selling/sharing the password.
That’s about all I have. And what FDISK said about checking the weblogs.
That was what I was wondering. I wasn’t sure if a BRTUEFORCE methos would work on a web form because of the delay. I am guessing that is would also bog the server down would it not?
Symantec has patches and upgrades available for nine different versions of PCAnywhere. If you use an older version and are concerned about security issues, you may want to check out what fixes they’ve made available.
Remember hacking is as much art as it is science. In order to break in a hacker needs BOTH the used id and password. If your company uses something like first initial/last name for user ids you’ve made it very easy on the hacker. Also disable the Administrator user id and apply administrative rights to your own user name and/or a few other people (always have more than one administrator equivalent account). Also disable the Guest user id if it exists on your system.
As for brute forcing a password I think FDISK has underestimated the number of combos a computer has to go through for this. Not being a mathematician I’m not sure though. However, I have poked around with brute force hack programs on my own system before. The program estimated the time it would take to hack the password. If I did only alphanumeric with 8 characters it estimated a time of about three hours. If I did alphanumeric, upper and lower case letters and special characters the program estimated three months to hack the password. BIG difference.
As a result you might want to see if your logon system can force a password not only of minimum length but to also include at least one uppercase letter. Soomething as simple as that drastically increases the problem for the hacker.
As a network admin, I’ve used a tool called l0phtcrack (it’s now called LC3). Basically, it can crack most passwords in about 12-24 hours, depending on processor speed and other considerations. It can (and will) crack any password that is an english word in about 5 minutes.
Of course, you have to provide it with password hashes (the encrypted bits that go across the network), but this is fairly easy and automated.
The recommendations I’ve heard for a secure password:
At least eight characters total.
At least one lower-case letter
At least one upper-case letter in a position other than the first
At least one numeral
At least one non-alphanumeric character
Not found in any standard English-language dictionary
If I’m counting correctly, that means 94 possibilities for each character, and 94[sup]8[/sup], or 6.1*10[sup]15[/sup] possible passwords.
Unfortunately, there’s no easy and secure way to ensure that your users are doing this. The number of characters is the only thing that a password-validation program would be able to easily check: If you send the passwords “in the clear” to the validator program, then they can be intercepted there. About your only workable way to check is to actually run a password-cracking program on your own systems, and see what it turns up.
Ok I can understand blocking an account when multiple tries are made but why 3? I have many passwords and sometimes I don’t remember which one I used and get very close to that 3 limit (sometimes I run over it and have to go throught the process).
I would think 10 or even 30 password attempts would be almost as effective at stopping dictionary attacks but give you a chance to get it right if you have multiple passwords.
The other thing about it is that 3 logon tries kind of forces you to use a more memorable password and that would lead to an easier to crack password.
Whack-a-Mole: You’re right, I did vastly underestimate the number of combinations. A more proper number is, by my updated count, 62. 2*26 + 10. However, a dictionary attack based on common passwords could still probably get through in a few seconds to a few minutes at most. Any brute force attack against a web server should be notable in logs, however.
Extrapolating from the speed of my 1Ghz Athlon at RC5-64 cracking, I’d guess that a system of similar speed to mine would be able to completely brute force a file encrypted with a 4 char key, assuming that each byte has 256 possibilities, in about 20 minutes. Remember folks, use long keys:)
I’m responsible for password security where i work, but I have very little formal computer training.
A lot of users want to satisfy our complicated password requirements by doing something like “Debbie1.” in which Debbie is their girlfriend’s name. I won’t let them, based on my fuzzy belief that a password consisting mostly of a long word is easier to crack than a password containing no words.
Is this accurate, or is “Debbie1.” just as difficult to crack by brute force as “zN66/iykw” ?
(FTR, I know “Debbie1.” is easy to crack if you know what the user’s girlfriend’s name is; right now, I’m just talking about cracking programs)
If you’re submitting password values through a form on the web, there is a way to gain access without overloading the server.
Are you storing password values in a flatfile (like an encrypted .txt file somewhere) or are you keeping the passwords in a database (like SQL Server)?
If its the latter, than its possible your developers have set up the page so that the password value that the user enters on the web form is incorporated into an SQL statement and then executed on the database. If thats the case, and the SQL statement isn’t being parsed properly, a hacker could quickly gain access to everyone’s passwords.
For Example:
Let’s say your web form is set up with a Textbox for the Password, and the form just passes this password value in as a SQL Statement (such as “Select * From Table where Password = Textbox Value”). If the user enters a value like “x OR 1=1” then its possible to skip over the password authentication, or even execute other statements (like Updates or Deletes).
