Limiting password check attempts is important too, but if all a bad guy could get access to is user accounts the damage is significantly less.
And I still don't care if everyone else on your network can't access my service; until you find the hacker and put a stop to it, why should I have any trust in your network address? The street goes both ways here.
You wouldn't get his followers, but you'd get a premium name easy.
I don't understand how he thought hi-jacking Obama, Britney and Fox News twitter accounts wouldn't make headlines.
He was hijacking a random account on some totally unknown site called twitter.
I know this is hard to grasp outside the valley, but most people have not ever heard about twitter and will probably assume it's about as important to the internet as zombo.com.
"He said he'd never even heard of Twitter until he saw someone mention it on YouTube. "
Anyone have an article or some ideas on how this could be done? Is limiting attempts the simplest way?
Even if you do limits, aren't these session-based? I'm guessing a cracker isn't going to respect sessions.
1 - LastLoginAttemptedDateTime
2 - LastLoginAttemptedIPAddress
3 - LastSuccessfulLoginDateTime
4 - LastSuccessfulLoginIPAddress
5 - MustChagePasswordAtNextLogin - a boolean flag to indicate they must change their password. You'll set that flag when they're recovering a password, or you've emailed them a temporary password.
6 - UnsuccessfulLoginCount - some number that your logic will use to determine how long they must wait, or if they sit in the penalty box.
7 - AccountLocked - boolean flag, some pointy haired bosses will not permit accounts to be locked out, like mine. And mine refuses to allow passwords to be one-way hashes (his words: we must be able to email the user the password they use). Depending on the security you need, the user of a locked account either has to phone up an unhelp desk, or show up in person.
9 - UserAgreementDateTime - see #8
Along with a LoginTransaction table that captures attempts - both successful and not to log in, with usernames, date/time, IPaddress. This table should locked down so that a hacker can't delete entries, entries can be added, but not deleted nor changed. You'll do that with triggers ("instead of" triggers for sql server folks).
Perhaps your business logic says that a user can have 3 attempts in a 5 minute window (with no lockouts).
Your code would do something like...user has made 3rd bad attempts, set LastLoginAttemptedDateTime = Now, set UnsuccessfulLoginCount = 3.
Now the user tries to log in 1 minute later...If LastLoginAttemptedDateTime + 5_minutes < Now then log the attempt, LastLoginAttemptedDateTime = Now, reject login attempt EndIf.
If they log in successfully, log that event, set UnsuccessfulLoginCount = 0, set LastSuccessfulLoginDateTime and LastSuccessfulLoginIPAddress to the appropriate values.
Small user sets, such as the Twitter admin accounts, would not be large enough to be successful with a horizontal attack. Provided, of course, that every user has a minimum password complexity, which they did not. Even without complexity requirements, the list of simple words is still prohibitively large in most cases.
That said, if you have even one user among millions with the password "qwerty", he is certainly at risk. However, once you are at a scale prone to this kind of attack, a more sophisticated rate limiting scheme is probably required even for regular web requests.
Specifically, Fail2Ban follows auth logs for various services, and when it finds clients exceeding per-service configured limits, it adds IPTables rules that ban the offending IP address for a configurable amount of time.
Fail2Ban is packaged in many distributions, including Debian and Ubuntu, and can be compiled on just about any system. I personally use it exclusively to thwart brute force attacks on SSH, SMTP/Postfix, IMAP/Dovecot, and HTTP/Apache.
It should be trivial to add a new set of filter/jail rules for any web application that can log bad authentication attempts to a file, and then you have instant "protection" from most brute force attacks.
I've noticed sometimes the tech world feels like a bubble where our sense of what's important in the "real world" gets warped.
Maybe staffers should have used a secondary password to get administrative rights.
Or maybe they should have been using an entirely different account.
If you must let admin accounts use the main website, then they should have a whitelist of IP addresses that they may log in from - and those IP addresses should map to the internal company IP addresses.
Otherwise, if you absolutely positively MUST have admin accounts use the same website, and allow them access from outside the company, then you need to have a second factor authentication device like a SecurID token.
We all make mistakes, doesn't seem terrible honestly.