I've got to commend ASF for admitting a mistake publicly, and warning us about the methodology being used to hack the accounts. Many times we all see a sort of "passing the buck" by big firms that get hacked. So...kudos to ASF. Also, I have to think that the "3 tries and you're out" password scheme can be effective, at least in slowing down brute force.
Your advice is useful on something like a desktop computer where only one user has access at a time from a single point of entry. On a web server, I think this technique would make it trivial for anyone to launch a DoS attack, locking thousands of users out of their accounts.
This still comes down to poor password discipline. LONG passwords are the best way to mitigate dictionary attacks although delays and fail2ban are also good.
A better way to block a brute force password attack is to lock an account for a short period of time after a small number of failed attempts.
For instance, locking an account for 1 minute after 5 failed attempts DRASTICALLY slows down brute force attempts. Increasing the delay for subsequent failures (say up to an hour) would make brute-force attacks stop in their tracks. Hundreds of thousands of attempts would take weeks, months, or years depending on the approach taken.
A notification to admins and the user being attacked would further ensure that repeated failed attempts result in that user being disabled.
All of this takes time to develop, and isn't necessarily the top priority of developers or management until someone makes it a priority. Sadly, by the time it's a priority, it's usually too late.
that tinyURL will be used to cloak compromised "real" URLs ?
It has seemed to me from the outset that any URL that doesn't easily parse into a meaningful is likely to be used as a vector for maliciousness. The average punter is barely savvy enough to read the URL in any case, when it's an inscrutable handful of characters there is no hope. Let's face it, whoever was zapped here on an Apache issue log was no naïve end user...
Spoofing doesn't stop an IPS or SIEM from alarming, in fact sigs are specifically written to detect such attacks. Are they not running an IPS (SNORT?) or have anything sorting/collating/reviewing logs?
@AB: Changing IPs every 3 tries would be an obstacle.
As would simply an alarm that thousands of attempts were coming from anywhere. By the way, I've already suggested using Firefox with a custom user agent string to initially validate that password attempts come from an apparently authorized source.
If you can't answer my question simply and directly, I think it a good question.
"threw hundreds of thousands of password combinations at its servers"
I repeat from I think the Twitter compromise story: Isn't there ANY alarm for this? Are modern systems so stupidly designed as to allow unlimited attempts, instead of ignoring an IP after three failed attempts?
I've got to commend ASF for admitting a mistake publicly, and warning us about the methodology being used to hack the accounts. Many times we all see a sort of "passing the buck" by big firms that get hacked. So...kudos to ASF. Also, I have to think that the "3 tries and you're out" password scheme can be effective, at least in slowing down brute force.
Your advice is useful on something like a desktop computer where only one user has access at a time from a single point of entry. On a web server, I think this technique would make it trivial for anyone to launch a DoS attack, locking thousands of users out of their accounts.
This still comes down to poor password discipline. LONG passwords are the best way to mitigate dictionary attacks although delays and fail2ban are also good.
A better way to block a brute force password attack is to lock an account for a short period of time after a small number of failed attempts.
For instance, locking an account for 1 minute after 5 failed attempts DRASTICALLY slows down brute force attempts. Increasing the delay for subsequent failures (say up to an hour) would make brute-force attacks stop in their tracks. Hundreds of thousands of attempts would take weeks, months, or years depending on the approach taken.
A notification to admins and the user being attacked would further ensure that repeated failed attempts result in that user being disabled.
All of this takes time to develop, and isn't necessarily the top priority of developers or management until someone makes it a priority. Sadly, by the time it's a priority, it's usually too late.
that tinyURL will be used to cloak compromised "real" URLs ?
It has seemed to me from the outset that any URL that doesn't easily parse into a meaningful is likely to be used as a vector for maliciousness. The average punter is barely savvy enough to read the URL in any case, when it's an inscrutable handful of characters there is no hope. Let's face it, whoever was zapped here on an Apache issue log was no naïve end user...
Spoofing doesn't stop an IPS or SIEM from alarming, in fact sigs are specifically written to detect such attacks. Are they not running an IPS (SNORT?) or have anything sorting/collating/reviewing logs?
Interesting....
As would simply an alarm that thousands of attempts were coming from anywhere. By the way, I've already suggested using Firefox with a custom user agent string to initially validate that password attempts come from an apparently authorized source.
If you can't answer my question simply and directly, I think it a good question.
I wonder... Could it have been the Chinese government again?
Do you really think those guys attacked from 1 single IP or didn't know how to spoof IP's?
I repeat from I think the Twitter compromise story: Isn't there ANY alarm for this? Are modern systems so stupidly designed as to allow unlimited attempts, instead of ignoring an IP after three failed attempts?