Paid Advertising is
ha.ckers sla.cking
For any nonsense or banter that doesn't fit anywhere else. LoL! omg! ROFL! 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
HTTP BruteForciblity
Posted by: iota
Date: April 17, 2008 12:55PM

Thousands of web sites including, are exposed to brute force crack to their users password because they provide informative error messages like "Invalid Password".

Secure advices such as "Provide as less information as possible to attackers" have been spread around since 2000.

But developers look down this advice and they identify it as low-risk.

Let me know your opinion on this issue.

Options: ReplyQuote
Re: HTTP BruteForciblity
Date: April 17, 2008 01:51PM

It's a logical argument which you have presented, iota. Limiting the amount of potentially useful information displayed during incorrect logins is one of several ways to help negate brute-force attempts, but not the only method of course. As with everything else in security the system or application needs to be layered in order to prevent most attacks.
Most developers don't even give it a second thought, however in a large majority of applications users will be presented with an error screen declaring whether a password was incorrect (which in some cases would validate a username's existence), or if a user's account was not found (this could possibly work in scenarios where there are shared passwords, but seperate accounts). Any output by the server should be as broad and generic as possible in order to minimize brute-force attacks, but again this is only a starting point. Some other methods to use in conjunction with this:

1. The usual "lock-out" method
A number of services employ the lock-out method to prevent unauthorized access to accounts, but this should be used to deny IP addresses rather than the accounts themselves. I believe some time ago there was a vulnerability in MSN and MSN messenger, which allowed someone to lock a user out of their account by continually attempting to login to that person's account.

2. Connection attempts versus time-span
Depending on the application it may be possible to correlate repeated connection attempts (usually from multiple IP addresses) that have taken place in a short time-span, or have attempted to gain access to a single account.

3. Embedded content
I've been monitoring a large number of automated attacks against my website for quite some time. Since most of these tools and bots are not using normal web browsers the requests are generally only for pages, and not any subsequent content on the website (images, flash files, et cetera). Makes it a lot simpler to detect malicious traffic.

4. Binding accounts to IP addresses
Another popular method to prevent brute-force attacks from working correctly includes restricting an account to a single static IP address, and requiring that an IP be confirmed for access prior to being able to login to an account.

Again not always the most useful feature when it's the sole form of protection, but when added to the mix it just increases the amount of difficulty for successfully performing various attacks.

6. Personal Questions/Verification
Speaks for itself.

7. Password Policy
Also speaks for itself.

Anyone else have any interesting methods?

Awesome AnDrEw - That's The Sound Of Your Brain Crackin'

Options: ReplyQuote
Re: HTTP BruteForciblity
Posted by: hanfi
Date: April 17, 2008 06:16PM

iota Wrote:
> Thousands of web sites including,
> are exposed to brute force crack to their
> users password because they provide informative
> error messages like "Invalid Password".

I don't think it's usefull to not show this error.
Most of these Sites reveal usernames anyway, in comments from Blogs for example.
If the userbase is big enough one can almost certain guess valid names.
That makes me belive, that those people actualy try brute-force such passwords go for one specific account (in special since salting is used more widely). In this Situation, the additional comfort for new users not get confused too much is much bigger than the leaking of valid usernames.

I would be more worried about the messages about accounts not be activated. If I know that a person tried register some days ago, but never enabled the account, the possibility is big, that the user didn't got the registration mail (or it was silently moved to some spam folders). Then i could try send a mail with a fake-validation-link, and the user may not be too curious.

Options: ReplyQuote
Re: HTTP BruteForciblity
Posted by: id
Date: April 17, 2008 06:23PM

I think it's a split issue, I agree mostly with hanfi here, for the vast majority of sites it isn't worth the costs (user frustration, support, etc); however for high security sites, such as banks, that would never normally show a username there's no excuse for not giving the generic "either username OR password were incorrect"


Edited 1 time(s). Last edit at 04/17/2008 06:24PM by id.

Options: ReplyQuote
Re: HTTP BruteForciblity
Posted by: Malkav
Date: April 17, 2008 07:31PM

many banks use display randomized pads to enter the password, so the only thing left is username

altough the method of the pad is quite good, extreme care must be taken by the JS coder not to frustate non IE user.

guess what they do ?


Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote
Re: HTTP BruteForciblity
Posted by: Anonymous User
Date: April 18, 2008 04:29AM


but this should be used to deny IP addresses rather than the accounts themselves.

I consider logging and informing most important in these cases. The system should of course not block the account - and if then just for about 5 to ten seconds. If a brute-force attack was suspected the user should be informed via mail - or customer service. GMX does this IIRC.

Also - like mentioned in 2.) very important forms should be protected by a delay - most OS show how this works and webapps can do the same with little implementation effort. If communicated and implemented right even the user will like this kind of constraint - in case JS was switched on and the frontend designer did a good jawb ;)

Options: ReplyQuote
Re: HTTP BruteForciblity
Posted by: Anonymous User
Date: April 18, 2008 04:30AM

Ah - and to avoid misunderstandings - sleep() is of course not bulletproof. Just exemplary.

Options: ReplyQuote
Re: HTTP BruteForciblity
Posted by: thrill
Date: April 18, 2008 11:33AM

I believe that the less information you give, the better off you are. Such is the case with 'network equipment banners'.. one of the last places id and I worked at had the stupidest policy; every single piece of network equipment needed to have:

* This <equipment type> is owned by *
* <name of company>. Any unauthorized *
* access is prohibited. *

And I remember having a very long discussion with a few people about having the <equipment type> and <company name> on the banner. To the right person, just having the company name might be more of an incentive.

Anyway, on another note, you guys just gave me a really good idea for authentication which is very simple to implement. Rather than just having the username/password field, a 3rd field should be entered. This could be something as simple as numbers (check boxes that you define which one you want to use), to names of flowers, places, etc.

IE. login: thrill Password: idIsMyHer0! []1 []2 []3 [x]4 []5.....etc

It's a 3rd form of authentication which again, very simple to implement.. that 3rd field could even be used to salt the pword..

Just a thought.



It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote

Sorry, only registered users may post in this forum.