Courtesy of Twitter admins and famous users, we get another example of poor passwords leading to a breach:

An 18-year-old hacker with a history of celebrity pranks has admitted to Monday’s hijacking of multiple high-profile Twitter accounts, including President-Elect Barack Obama’s, and the official feed for Fox News.

The hacker, who goes by the handle GMZ, told Threat Level on Tuesday he gained entry to Twitter’s administrative control panel by pointing an automated password-guesser at a popular user’s account. The user turned out to be a member of Twitter’s support staff, who’d chosen the weak password “happiness.”

Cracking the site was easy, because Twitter allowed an unlimited number of rapid-fire log-in attempts.

“I feel it’s another case of administrators not putting forth effort toward one of the most obvious and overused security flaws,” he wrote in an IM interview. “I’m sure they find it difficult to admit it.”

I tend to agree with him. Twitter had not implemented basic authentication controls. My preferred list:

1) Never share or disclose passwords. This is completely unnecessary on modern systems and the only reason it happens is because admins don’t know how to manage access to privileged resources. If the admins request an exception for shared passwords (you have a policy of no password sharing, right?), the solution is to get better admins.

Human nature, followed closely by Phishing, are the obvious failures here. Human nature won’t change, but it remains a significant user and technology issue.

2) Enforce password complexity. This is difficult with public Web sites, I realize, but admins should at least have a policy requirement to do so. You can check this by running a cracker such as John The Ripper against your internal database. It’s quite fast and will produce a reasonable level of confidence in password strength pretty quickly.

3a) Limit login attempts–lock out accounts after a suitable number of attempts–it could actually be pretty high if combined with complexity.
and/or
3b) Monitor logs for brute-force login attempts. But do so automatically, including a reactive control to disable or otherwise block the login attempt. And review the incidents.

Passwords rely on a few simple controls, and can be quite effective if they are all followed. If they are not, however, then you wind up on 27bstroke6.

For all the two-factor fans in the house, I recently had to have some folks fired for performing out-of-band (voice) disclosure of SecureID values to bypass remote access restrictions (I caught them by reviewing access logs after I suspected they were at-risk for misbehavior, btw), so don’t try to hide behind that.

Similarly, Smart Cards, to quote a friend of mine at the Department of Defense, “are only as smart as the General’s picture on the front of it.” People tend to either leave the card in the machine (unifying it with door systems helps with this) or at least store it in their laptop bag if they have a laptop, in which case it’s worse-than-useless in a lost laptop scenario.

Also, strong authentication mechanisms tend to have some sort of graceful degradation built in, which can be an easy branch of the attack tree as well.

The key thing to realize is that no authentication mechanism is a perfect preventative control. You need compensating controls like log analysis to actually have any confidence that your beautiful technology hasn’t been bypassed by some clever people.

One final thought–why was admin functionality incorporated into the user-side of a public Web site in the first place? The best way to manage the risk of an admin account compromise is to avoid it by not having it publicly accessible in the first place!

Run John against the pw database, huh? With what we know so far about this so far, it wouldn’t surprise me if the passwords are stored in the clear!

Has anyone tried signing up as “‘Bobby ;Select pw from users”? :^)

doh! Good point, but not necessarily true in twitter’s case. It’s written in ruby on rails (if my memory and googling serve me well), which has good hashing libraries and lots of example code for implementing hashed passwords, including automated code generators to do so–though I have no idea if twitter uses any of those.

I was thinking of more general guides when dealing with operating system and backend database passwords when I mentioned John, though.