Can brute force password cracking be easily prevented?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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

Re: Can brute force password cracking be easily prevented?


Quoted text here. Click to load it


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).

Quoted text here. Click to load it

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
             dannyb@panix.com
[to foil spammers, my address has been double rot-13 encoded]

Re: Can brute force password cracking be easily prevented?

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

snip ...
Quoted text here. Click to load it

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

Re: Can brute force password cracking be easily prevented?

John S used his keyboard to write :
Quoted text here. Click to load it
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.



Re: Can brute force password cracking be easily prevented?


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Good guess. :)


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

Re: Can brute force password cracking be easily prevented?

Quoted text here. Click to load it

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     -->briang@panix.com<--     brian dot gordon at cox dot net |
+ brianggordon@hotmail.com   Bass: Lexington "Main Street Harmonizers" chorus +
-------------------------------------------------------------------------------

Re: Can brute force password cracking be easily prevented?

Quoted text here. Click to load it

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
play that game forever :-)

That was before things like denial of service attacks.

I forget what the reset trigger was.

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

Re: Can brute force password cracking be easily prevented?


Quoted text here. Click to load it

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.)

Re: Can brute force password cracking be easily prevented?

On Thursday, January 10, 2013 11:46:56 PM UTC-5, John S wrote:
Quoted text here. Click to load it

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

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

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=
.=20

some simply encrypt the passwords. encryption is insufficient because it ca=
n be reversed if you know the encryption key, and if someone gains enough a=
ccess to get the password database, they probably can get the key too. if y=
ou 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 o=
r 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 attack=
ers 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 at=
tackers 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 has=
h algorithm (essentially combining the password with a unique value prior t=
o 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 ea=
ch possible salt value and that's just not feasible.

unfortunately, while salted hashes thwart rainbow tables, they don't stop a=
dvances in the speed of just running through all probable passwords. some o=
f these advances come in the form of common password lists from previous pa=
ssword 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 previo=
usly mentioned common passwords into seemingly more complex passwords.

ultimately, to stop offline attacks one has to not only use salt, one has t=
o use a hash algorithm where the "work factor" can be specified. normal cry=
ptographic hashes are designed to be fast - that's why password crackers ca=
n 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 actual=
ly slow down such offline attacks to the point where they become unfeasible=
. unfortunately very few people who develop software know anything about th=
is.

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 at=
tack 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 faile=
d logon attempts - but what if instead the attacker tried one password agai=
nst many users? or what if the attacker changed both the username and the p=
assword 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 tha=
n what account is being tried.

[snip]
Quoted text here. Click to load it

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

Re: Can brute force password cracking be easily prevented?

Quoted text here. Click to load it

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


Site Timeline