Last week, in retaliation against the heavy-handed response to planned protests against the BART metro system in California, the hacktivist group Anonymous hacked into several BART servers. They leaked part of a database of users from myBART, a website which provides frequent BART riders with email updates about activities near BART stations. An interesting aspect of the leak is that 1,346 of the 2,002 accounts seem to have randomly-generated passwords-a rare opportunity to study this approach to password security.
Examining archived versions of the myBART website confirms that, from its launch in 2001 until at least 2006, users were not allowed to select their own passwords, receiving a random password by email after signing up. Assigning users random passwords is very unusual on the web-in our 2010 survey we observed this at only 1 out of 150 sites. Indeed, myBART underwent a 2008 redesign and now users may choose any password they wish. Unfortunately, myBART still emails passwords in the clear if they are forgotten, requiring them to store passwords un-hashed in their database.
The data leaked by Anonymous appears to contain only accounts created during the era of randomly-assigned passwords (only about 2,000 of an estimated 50,000 were leaked). They represent a contiguous range of sequential user IDs, and the proportion of random passwords doesn’t change significantly for higher user ID numbers (presumably created later). We can conclude that about two thirds of users have kept their randomly-assigned password, and the other third actively changed it to something else.
It’s possible that more users would change at a more frequently-used site. myBART accounts mainly served to manage mailing list preferences, and it’s likely that some users rarely or never logged in. Past research indicates that users don’t like random passwords for commonly-used accounts, and are much more likely to write them down. In the myBART case, they were effectively written down for users, in that they received the password via email.
Still, it’s encouraging that at least some users accepted the randomly-assigned passwords. The format used (2 digits plus up to 8 lower-case characters) theoretically requires 44 bits of work to guess. The developers appear to have used some library (not the common tools pwgen or gpw) to generate easier-to-remember strings, as the distribution of letters is highly-non-random, but the min-entropy is still about 19 bits, which is sufficient to prevent online attacks. Even weak random passwords like these are much more resistant to guessing attacks than most user-chosen passwords.
Perhaps more importantly, by using random passwords, myBART prevented itself from leaking (most of) its users’ passwords which may have been re-used at other sites. Considering their failure to hash passwords, it’s not clear security was the main motivation for assigning random passwords at myBART. Yet this may actually be a good paradigm to investigate further. Given the ease of webmail searching and the increasing availability of browser password caches, randomly-assigned passwords recorded in one’s webmail may actually be a good approach for low-security, infrequently accessed web accounts.
An extension might be non-recurrent tokens: there is no static password, merely a (semi-)persistent browser cookie. To login on a new machine, you need to request a new password-like token which is emailed to you. After being used once, the token is no longer valid . This means that interception of the cleartext token has limited value (after activation it’s useless, before activation the user should notice). The main threat comes from takeover of the email account concerned, but that’s a gaping vulnerability in most password reset systems.
This is a great idea and should be used more.
“”Past research indicates … and are much more likely to write them down.””
Isn’t a good thing? Complex and written down is better than simple and not written down.
Nice piece! I have two observations. First, you wrote “Unfortunately, myBART still emails passwords in the clear if they are forgotten, requiring them to store passwords un-hashed in their database.” The requirement to send passwords in the clear does not prevent hashed storage, for example, if a client forgets a password, then the server can simply generate a new one. Secondly, as highlighted by “Hello”, a complex written down password can provide better security, but this is dependent upon the attacker model (in particular, is your desk secure); following from your comment that “Past research indicates … and are much more likely to write them down,” I wonder if users are moving towards encrypted password databases — such as Schneier’s Password Safe — to manage large numbers of passwords? (I suspect not. But it is a nice thought.)
I would be surprised if even a single one of these 1,346 users actually memorized their random password.
The reason I bring this up is that in practice, random-password-in-email means having to check your email every time you want to log in. Therefore it would be equally convenient — and more secure — to instead design the system to send an authentication token to your email every time you want to log in, and expire it after say 30 minutes. This gets rid of passwords altogether. What do you think?
In my ideal world these infrequently-accessed sites that you don’t care about would just start accepting OpenID already, but that’s probably not going to happen any time soon.
Oops, I should have read the other comments before posting.
Good comments, thanks everybody. I would agree with Arvind that probably nobody ever memorized these random passwords, so this was basically an email-based authentication scheme for most of the users. I should have made the point originally that email-based authentication (as most password systems fall back to) is an old idea (Simson Garfinkel wrote it up in 2003 and the concept is surely older). There have been some other proposals, like for smarter browsers which automatically fetch and parse an authentication email and log the browser in, or Ben Adida’s BeamAuth to cache the initial credential in a bookmark using the hash tag.
The BART system has two key advantages though: one, it just works with browsers that remember passwords, so in the common case users won’t have to back to their email. That’s a key advantage over sending out a new login token each time (though at some security cost). Second, users have the choice with a random-initial password to change it if they really don’t want the hassle of checking their email. Since one third of users chose to do this, from the web site’s perspective you’d be crazy to exclude them and possibly lose traffic. Of course you could have users choose traditional passwords even if you rolled out one of the alternatives, but BART’s setup enabled that with no extra implementation.
Obviously there are many ways to improve on what BART did, but it may be an interesting very low-cost, low user-training approach.
“it just works with browsers that remember passwords, so in the common case users won’t have to back to their email”
Totally missed that. Thanks for pointing out.
Not sure why using randomly-generated passwords would be “encouraging.” As this incident illustrates, The threat models heavily favor alternate attack vectors – both random passwords and user-selected ones were equally compromised here. And rainbow tables negate the value wrt hashed password tables.
At this stage, either a “not guessable in 5 attempts” password is good enough, else you need to move to alternate forms of authentication. (IMO, passphrases just don’t seem practical for deployment, though I reserve the right to change my mind here ;-)).
Pete Lindstrom
If the email account in question has stronger protections for it (e.g. proper 2 factor authentication) then this strategy would seem like a very good one to me, at least for this sort of site.
Pete – the difference between the randomly generated and the user selected ones is that the user selected ones may well have given away the password to their main email accounts too. The random ones haven’t lost anything else. If they were hashed and salted properly though then then rainbow tables would be a moot point.
@Pete: What rainbow tables can be used to crack SHA256 protected accounts?
That’s 256 bits of entropy, meaning you need a rainbow table of 1,16*10^77 entries. That’s a number this large:
115 792 089 200 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
(If I counted correctly. And don’t you even bother claiming that’s anywhere near possible to break. Even if you can divide it by a thousand to take possible security flaws into account, all those possible variations can’t be tested in a reasonable amount of time.)
You can even go with SHA512 for additional security.
Also, a rainbow table like that would take MANY petabytes!
A properly salted password database combined with high quality passwords is enough.
@Hello: “Complex and written down is better than simple and not written down.”
Simple for who, though?
http://xkcd.com/936/ is obligatory here.
@Natanael: “What rainbow tables can be used to crack SHA256 protected accounts?”
I’ve never understood why people use SHA or other speed hashes instead of bcrypt for passwords. bcrypt was designed specifically to defeat the brute force/rainbow table approach.
@Natanael L:
The size of the hash has very little to do with the difficulty of constructing a rainbow table. It is the entropy of the /input/ that counts. If a password is likely to come from a dictionary of 350,000 words, then a SHA256 rainbow table for that attack would be only twice the size of an MD5 table (and both would be quite small.)
You are correct about salting, though: as soon as a non-trivial amount of random salt is added, the input entropy is easily made large enough to make a rainbow table completely impossible with current technology.
However rainbow tables are not the only way to attack a hashed password (they are just the most efficient method for mass attacks.) As Stephen points out, even large amounts of salt offer no protection against a dedicated brute force search on /one/ target hash.
In that case, the best defence is that the password should itself have high enough entropy to rule out brute-forcing; but the system designer can give the poor end user some help by making his hash function as slow as is practicable. Slowing down a typical hash by a factor of around 100,000 times still gives acceptable response times to interactive users, but makes a brute force attack 100,000 times slower (roughly equivalent to making every password 16.6 bits stronger.)
The real WTF with myBART’s security design seems to be that it required passwords at all — one of 50 zillion sites that demand passwords from users simply because it’s the done thing. They served no purpose at myBART; the only operation that required authentication was registering or de-registering an email address, which only requires proof that you control that address.
Fortunately, myBART seems to have realised this; their FAQ on the intrusion says they are redesigning the site to run without any logins. Well done, myBART!!
Right on Roger! we don’t NEED an account on every bleeding website. Amazon I frequent often enough to want an account, all of those other once a year christmas shopping sites, no thanks
Maybe what’s needed is some White hat viruses releasing that can infect peoples computers, viral keyloggers etc which once they’ve found what their are looking for alert the user that they have been compromised.For example the virus might tell the user that having flash enabled or javascript represents a security risk.