
Twitter Hacker Says Admin Password Was 'Happiness' - lnguyen
http://blog.wired.com/27bstroke6/2009/01/professed-twitt.html
======
staunch
This is why ideally you only make your admin tools available on your private
network, accessible only via VPN. The very minimum is restricting access to
admin functionality to specific IP addresses.

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.

~~~
johns
Limiting attempts is a great way to allow people to remotely execute a DoS on
your admin site. They can keep you out for awhile before you block them. If
your company has a password lockout policy, keep guessing the CEO or CIOs
password constantly for a few days and the policy will be changed pretty
quickly. The other suggestions are good.

~~~
nuclear_eclipse
You don't lockout the account, you lockout the attacking client, typically by
IP address. It still allows the attacked accounts access from non-attacking IP
addresses.

~~~
andrewbadera
and if the attacking client is someone sitting on the corporate internet? way
to block the entire corp from logging in ...

~~~
Alex3917
It seems like the three main strategies are locking the account, blocking the
IP, or forcing a password reset. What if instead, the account login name
automatically got changed after a few missed attempts but the password
remained the same. That would get around the DoS problem and also the
corporate IP / AOL problem.

~~~
johns
I think rate limiting is a better option. If you only allow one log in attempt
per X seconds, it becomes much harder to do a dictionary attack in a
reasonable amount of time.

~~~
maximilian
This to me is the way to do it. You can limit it to something pretty large
like even or 3 tries, wait ten seconds or something. Basically making it
normal speed for a human but waaay slow for a computer is the trick to me. A
dictionary attack has to try tens of thousands of words and combinations to
crack an account.

------
Jasber
___He also realized he hadn't used a proxy to hide his IP address, potentially
making him traceable. He didn't think the intrusion was important draw for
law-enforcement attention, and "didn't think it would make headlines._ __

I don't understand how he thought hi-jacking Obama, Britney and Fox News
twitter accounts wouldn't make headlines.

~~~
alaskamiller
He didn't hijack those accounts; he gave out the credentials in a forum thread
and others jumped on it.

~~~
Jasber
Technically you're correct, but by giving out the credentials in a public
forum he should have known better.

~~~
alaskamiller
DG is an unique place.

------
sanjayparekh
This is again a reason why you shouldn't make accessing internal company
services too easy. Yeah, it can be a pain but once someone figures out a
little piece of the puzzle, they can run amok in your network. In hindsight,
tying customer service methods to employee Twitter accounts was the big
mistake.

~~~
bprater
Sure was a heck of a guess to end up with a staffer.

------
bprater
This does bring up a good tech question -- how do you prevent people from
doing a rapid password attack?

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.

~~~
Tangurena
Presume that you have some sort of table with userIDs and password hashes
(with salt). You should also consider adding some columns like:

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.

8 - UserAgreementID - As you change user agreements, you'll want to keep track
of what agreement the user agreed to, what day and time. This is something
you'll want to log, and if you make substantial changes to the user agreement,
you may want to force them to re-agree to the terms of use. You will also want
to keep every version of the user agreement stashed away in a table somewhere,
in case the lawyers get involved.

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.

~~~
gojomo
And if the attacker doesn't care _which_ userID they compromise, so they
spread their guesses over all userIDs?

~~~
snprbob86
This is a very real concern, however it is significantly less likely for such
a horizontal attack to succeed. I recommend the grand parent post's solution
for startups who aren't yet approaching critical mass and only require
protection from the vertical.

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.

------
axod
"He said he'd never even heard of Twitter until he saw someone mention it on
YouTube."

Classic

~~~
tlrobinson
Unsurprising. Most people have no idea what Twitter is.

I've noticed sometimes the tech world feels like a bubble where our sense of
what's important in the "real world" gets warped.

------
bprater
Again, it brings up the case of why passwords are bad at this level.

Maybe staffers should have used a secondary password to get administrative
rights.

Or maybe they should have been using an entirely different account.

~~~
Tangurena
Admin accounts should not use the main website for access - they should only
have access through an admin website.

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.

------
mynameishere
<http://www.youtube.com/watch?v=qEZxgEgG5Cg#t=1m52s>

------
eli
No, it wasn't. "Happiness" was the password for the account of a user who
happened to be on the support staff.

------
pclark
we're all human, and twitter is very new.

We all make mistakes, doesn't seem terrible honestly.

------
justifyleo
weak

