Can brute force password cracking be easily prevented?

[John S]

Lately I've been reading that with current techniques, previously
"unbreakable" passwords can be quickly broken by high powered computer
attacks using brute force.

What I can't understand is why people who write software which requires a
password will allow this to happen.

I would have thought that it would be relatively easy to include something
like a small time delay in the code, which would wait for, say, a
millisecond before responding to a password log-on attempt. This would
presumably negate the ability of a brute force attack to try large numbers
of passwords in a short time.

An alternative would be to allow only a limited number of failed attempts
at log on before shutting down the application, and requiring a re-start.

Would these techniques be practicable, or am I missing something obvious.

(Maybe I'm posting in the wrong group, but I guess people interested in
viruses will possibly be interested in password cracking?)

Cheers,

John S

[danny burstein]

In <uru2ifmkfk5u$.wqlpmtmd...@40tude.net> John S <gorb...@invalid.invalid> writes:

>I would have thought that it would be relatively easy to include something
>like a small time delay in the code, which would wait for, say, a
>millisecond before responding to a password log-on attempt. This would
>presumably negate the ability of a brute force attack to try large numbers
>of passwords in a short time.

>An alternative would be to allow only a limited number of failed attempts
>at log on before shutting down the application, and requiring a re-start.

A very common technique is to allow, say, three password
attempts. After the third one there's a 30 second timeout.

After the tenth a ten minute one. After 20 there's an hour.

(numbers chosen for illustration)

Doing a complete lockout is generally udnesirable because
it would allow for a denial of login attack... in other
words, if the Bad Guy [tm] wanted to lock General Washington
out of his account at the Valley Forge Bank, all they'd
have to do is try a dozen times...

(Far too many places that don't need it do, in fact, have
this policy. uggh).

>Would these techniques be practicable, or am I missing something obvious.

The "password cracking" that's often talked about is doing
a decoding of the master password file. "Somewhere on the system"
is a list of the 10,000 accounts, usernames, and passwords.
The password file is encrypted so that the word "subway" might
be ")&TDVUOYF(_".

If you've got access to that file (which for various reasons
is all too accessable on, again, far too many systems), it's
now getting possible to decrypt it.

- in the older days you (the Bad Guy) could take a list of
the 10,000 or so likely passwords, use the same encryption
algorythm the system uses, and generate your own file of
encrypted passwords. Then you could mix and match. That
would get you a hefty number of logins.

- Now you can do a direct decryption...

--
_____________________________________________________
Knowledge may be power, but communications is the key
dan...@panix.com
[to foil spammers, my address has been double rot-13 encoded]

[Dustin]

John S <gorb...@invalid.invalid> wrote in
news:uru2ifmkfk5u$.wqlpmtmd...@40tude.net:

> An alternative would be to allow only a limited number of failed
> attempts at log on before shutting down the application, and
> requiring a re-start.

I suggested a slightly modified version of this during a discussion with
another local technician. It went as follows. Allow login attempt for a
preset number of times. Say, 3. After the 3rd login attempt, continue to
ask for username/password but dont login even if its correct.

All login attempts must stop for a preset time period before the
protection will reset and give you 3 real tries. The bruce force app
doesn't know how many times it got to try or that no matter how many times
it tries now, it's still not getting in, even if it does get the right
login/password

Always ask for username and password, then login or don't. Never ever
tell the user they got one of the two right/wrong.

> (Maybe I'm posting in the wrong group, but I guess people interested
> in viruses will possibly be interested in password cracking?)

Good guess. :)


--
My take home pay isn't enough to take me home!

[David W. Hodgins]

On Thu, 10 Jan 2013 23:46:56 -0500, John S <gorb...@invalid.invalid> wrote:

> Lately I've been reading that with current techniques, previously
> "unbreakable" passwords can be quickly broken by high powered computer
> attacks using brute force.
>
> What I can't understand is why people who write software which requires a
> password will allow this to happen.

Only if the "bad guy" has access to the encrypted passwords, or the
crappy software vendor doesn't bother to include delays in the
password verification software.

For cases where the attacker has access to the encrypted passwords, adding a
delay in the password checking, would be bypassed by the "bad guy" compiling
their own password checking, without any such delay.

In the cases where the software provider didn't include such delays, as
recent news articles have been about, the system administrator should
switch to software that is secure (I.E. Not from m$ or Adobe).

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[John S]

On Fri, 11 Jan 2013 04:59:16 +0000 (UTC), danny burstein wrote:

snip ...

>
> The "password cracking" that's often talked about is doing
> a decoding of the master password file. "Somewhere on the system"
> is a list of the 10,000 accounts, usernames, and passwords.
> The password file is encrypted so that the word "subway" might
> be ")&TDVUOYF(_".
>
> If you've got access to that file (which for various reasons
> is all too accessable on, again, far too many systems), it's
> now getting possible to decrypt it.
>
> - in the older days you (the Bad Guy) could take a list of
> the 10,000 or so likely passwords, use the same encryption
> algorythm the system uses, and generate your own file of
> encrypted passwords. Then you could mix and match. That
> would get you a hefty number of logins.

OK, understood.

However, if a bad guy has the file of encrypted names and passwords etc,
how would he know which system has been used to encrypt them in the first
place? (I'm assuming there are quite a few different methods of
encryption).

John S

[FromTheRafters]

John S used his keyboard to write :

The strength of an algorithm lies in the fact that the algorithm itself
need not be 'secret' - only the key needs to be secret. There's a good
chance that the "method" is already known to the attacker.

[Brian Gordon]

In article <XnsA1454890F19CB7Z317AGDTEHHI8AJ283@no>,

Dustin <drop.thos...@raidsplace.org> wrote:
>John S <gorb...@invalid.invalid> wrote in
>news:uru2ifmkfk5u$.wqlpmtmd...@40tude.net:
>
>> An alternative would be to allow only a limited number of failed
>> attempts at log on before shutting down the application, and
>> requiring a re-start.
>
>I suggested a slightly modified version of this during a discussion with
>another local technician. It went as follows. Allow login attempt for a
>preset number of times. Say, 3. After the 3rd login attempt, continue to
>ask for username/password but dont login even if its correct.
>
>All login attempts must stop for a preset time period before the
>protection will reset and give you 3 real tries. The bruce force app
>doesn't know how many times it got to try or that no matter how many times
>it tries now, it's still not getting in, even if it does get the right
>login/password
>
> Always ask for username and password, then login or don't. Never ever
>tell the user they got one of the two right/wrong.
>

Back in the "good old days", the bright lights that maintained the company's
Unix systems, where we had source access, did just about this. After 'n'
failed attempts (n=5, as I recall), that incoming stream was handled by a
different, home-brew, login handler, that gave the same prompts, waited a
little while, and then reported thyat the login had failed. It was willing to
play that game forever :-)

That was before things like denial of service attacks.

I forget what the reset trigger was.

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Brian Gordon -->bri...@panix.com<-- brian dot gordon at cox dot net |
+ briang...@hotmail.com Bass: Lexington "Main Street Harmonizers" chorus +
-------------------------------------------------------------------------------

[Brian Gordon]

In article <XnsA1454890F19CB7Z317AGDTEHHI8AJ283@no>,
Dustin <drop.thos...@raidsplace.org> wrote:

>John S <gorb...@invalid.invalid> wrote in
>news:uru2ifmkfk5u$.wqlpmtmd...@40tude.net:
>
>> An alternative would be to allow only a limited number of failed
>> attempts at log on before shutting down the application, and
>> requiring a re-start.
>
>I suggested a slightly modified version of this during a discussion with
>another local technician. It went as follows. Allow login attempt for a
>preset number of times. Say, 3. After the 3rd login attempt, continue to
>ask for username/password but dont login even if its correct.
>
>All login attempts must stop for a preset time period before the
>protection will reset and give you 3 real tries. The bruce force app
>doesn't know how many times it got to try or that no matter how many times
>it tries now, it's still not getting in, even if it does get the right
>login/password
>
> Always ask for username and password, then login or don't. Never ever
>tell the user they got one of the two right/wrong.
>

Back in the "good old days", the bright lights that maintained the company's
Unix systems, where we had source access, did just about this. After 'n'
failed attempts (n=5, as I recall), that incoming stream was handled by a
different, home-brew, login handler, that gave the same prompts, waited a

little while, and then reported that the login had failed. It was willing to

[kurt wismer]

On Thursday, January 10, 2013 11:46:56 PM UTC-5, John S wrote:
> Lately I've been reading that with current techniques, previously
> "unbreakable" passwords can be quickly broken by high powered computer
> attacks using brute force.
>
> What I can't understand is why people who write software which requires a
> password will allow this to happen.

very often it comes down to the people writing such software not knowing enough about password security.

for example, some people think passwords are only broken by putting one password after another into the logon prompt - a so-called online attack - while completely ignoring the potential for offline attacks (where the password database is stolen and attacked without accessing the system the passwords are for) and the steps needed to thwart those.

some places actually store plaintext passwords so that if an attacker gains access to the password database there's no additional work they need to do.

some simply encrypt the passwords. encryption is insufficient because it can be reversed if you know the encryption key, and if someone gains enough access to get the password database, they probably can get the key too. if you ever use the password recovery feature of a site and they tell you what your password was then they're either not protecting the passwords at all or they're doing something dumb like encryption.

some will use a one-way hash algorithm instead of encyption. this is better because the transformation can't be reversed, but all an attacker needs is to find a string that produces the same hash value your password produces, which they can do by trying all possible passwords up to a certain length. in fact, if they're just using a plain cryptographic hash algorithm attackers can build a lookup table of strings and their corresponding hash values (a so-called "rainbow table") just one time and then after that all the attackers need to do is look up the string that produces the particular hash values they're interested in. the attackers can re-use that table over and over again and the lookup process is pretty trivial.

some are smart enough to thwart rainbow tables by using salt with their hash algorithm (essentially combining the password with a unique value prior to hashing such that the unique value or salt is different for each user who's password is hashed). this would require a different rainbow table for each possible salt value and that's just not feasible.

unfortunately, while salted hashes thwart rainbow tables, they don't stop advances in the speed of just running through all probable passwords. some of these advances come in the form of common password lists from previous password cracking attempts (the more passwords we know have been used before, the more we can try first before moving on to plain brute force), as well as an ever broadening library of rules people use to transform those previously mentioned common passwords into seemingly more complex passwords.

ultimately, to stop offline attacks one has to not only use salt, one has to use a hash algorithm where the "work factor" can be specified. normal cryptographic hashes are designed to be fast - that's why password crackers can try such a large number of possible passwords per second. a password hash algorithm where the work factor can be specified is the only way to actually slow down such offline attacks to the point where they become unfeasible. unfortunately very few people who develop software know anything about this.

as for online attacks there are things that people don't consider there as well. for example what most people consider when they think of an online attack is that the attacker puts in one username and then tries over and over again to find out what that particular user's password is. they think they can thwart this by doing account lock outs after a certain number of failed logon attempts - but what if instead the attacker tried one password against many users? or what if the attacker changed both the username and the password on each attempt? account lockouts don't work for that. you have to slow them down based on where the logon attempts are coming from rather than what account is being tried.

[snip]

> Would these techniques be practicable, or am I missing something obvious.

i don't think you're missing something obvious, but you are missing something. there are actually a lot of nuances to password security. it's not as straightforward as it seems. that's a big part of the problem - people underestimate the complexity of how to do things right and then password security gets implemented by someone who doesn't know enough about what they're doing.

[David W. Hodgins]

On Fri, 11 Jan 2013 20:56:28 -0500, John S <gorb...@invalid.invalid> wrote:

> However, if a bad guy has the file of encrypted names and passwords etc,
> how would he know which system has been used to encrypt them in the first
> place? (I'm assuming there are quite a few different methods of
> encryption).

The same way that the system that is supposed to be able to decrypt the
passwords knows. The method used is normally stored as a code in the
file.

[Brian Cryer]

"John S" <gorb...@invalid.invalid> wrote in message
news:uru2ifmkfk5u$.wqlpmtmd1g1g.dlg@40tude.net...

> Lately I've been reading that with current techniques, previously
> "unbreakable" passwords can be quickly broken by high powered computer
> attacks using brute force.
>
> What I can't understand is why people who write software which requires a
> password will allow this to happen.
>
> I would have thought that it would be relatively easy to include something
> like a small time delay in the code, which would wait for, say, a
> millisecond before responding to a password log-on attempt. This would
> presumably negate the ability of a brute force attack to try large numbers
> of passwords in a short time.

That is the way that many systems work. That plus the idea of automatically
locking the account out after a number of failed attempts.

Is there a particular application/system which you are thinking about? This
is why brute force attacks are rarely viable. The main exceptions being
where an attacker has managed to obtain a list of encrypted or hashed
passwords, and doesn't need to go via the application in order to try to
break them.
--
Brian Cryer
http://www.cryer.co.uk/brian