I am no fan of “security through obscurity”. Peer review and open discourse on security have proven essential in development of network protocols and cryptographic algorithms. Regardless, that does not mean I choose to disclose everything. I may disclose protocols and approach, but certain details I choose to remit.
Case in point: if I were Twitter, and wanted to reduce account hijacking by ridding myself of weak passwords which can be easily guessed, I would not disclose my list of weak passwords to the user community. As noted by TechCrunch:
If you’re on Twitter, that means you registered an account with a password that isn’t terribly easy to guess. As you may know, Twitter prevents people from doing just that by indicating that certain passwords such as ‘password’ (cough cough) and ‘123456’ are too obvious to be picked. It just so happens that Twitter has hard-coded all banned passwords on the sign-up page. All you need to do to retrieve the full list of unwelcome passwords is take a look at the source code of that page. Do a simple search for ‘twttr.BANNED_PASSWORDS’ and voila, there they are, all 370 of them.
The common attack vector is to perform a dictionary attack on known accounts. A good dictionary is an important factor for success. It is much easier to create a good dictionary if you know for certain many common passwords will not be present. Making the list easy to discover makes it much easier for someone to tune their dictionary. I applaud Twitter for trying to improve passwords and thereby making them tougher to guess, but targeted attacks just got better as well. Because here’s a list of 370 passwords I don’t have to test.
Reader interactions
11 Replies to “Password Policy Disclosure”
@David – A couple points
-I do not know if Twitter wanted the weak password list to be known or not. I cannot prove one way or another. However, the impression of better security is a PR opportunity, but there was no press release. And every company is looking for new things to market and differentiate themselves. If Twitter wanted the information out they would have communicated it. Even if they did not care one way or another, given the way it was implemented [as you point out], it was assured people would find it. The whole approach seems bass-ackwards.
-Other vendors, especially in web services, have applets, applications and scripts that dynamically test password ‘strength’ and show with simple red-green-yellow indicators, and this is very effective at raising awareness that, well, your password sucks. And don’t get me wrong … there are some sites that I flat-out do not care about that I have intentionally weak passwords on. I get your point.
-In the greater scheme of things, 370 dictionary entries will not make a meaningful change to twitter security and will not slow dictionary attacks that much. I still would not disclose as the extra tries provide additional evidence for monitoring software and other types of threat detection. I still would not have disclosed if for no other reason.
-Adrian
I’m definitely going to disagree here, let me explain. Even had Twitter not said anything around the password exclusion list people would have noticed. At that point someone gets the idea to start keeping track of those passwords Twitter won’t let me use… Some other people throw in a few and now it’s a game / wiki. It doesn’t matter. In the end I see it as a good thing that obvious passwords are being rejected because the person who goes to use “123456” now has to come up with something more robust. We all know password reuse is a common problem so, now, maybe they change all of the other “123456” to the new password of “1234567890”. Is it any better? Yes and no – depending on which new password they chose. But, at some level the person had to comprehend a weakness for at least a few seconds. Maybe that thought actually brings them to thinking about a unique password. In the end this information of top 370 passwords has been out there and really makes brute force attempts no easier going forward. Any Twitter account that’s going to be targeted has already had these obvious passwords flung at it from the brute forcees.
Obviously Twitter doesn’t care if you have that list or it would have been a server side comparison upon submission. They’ve made mistakes and will likely do so again but I’m going to take a guess that they contemplated putting this out there live (and conversely made the account processing model lighter). The list is public no matter how they implement it – so I stand by the idea that it’s still a good thing for end users.
We all love to talk about actual risk consideration being a factor in security decisions, but then we rail on about generic principles.
Twitter is a consumer oriented service that allows users to send brief messages. They aren’t protecting national security. Their goal is to make this process easier. I could easily make a case for them to fully put that list into the public domain, front and center on their account creation page.
@Dan – In a pure brute force attack, where you control the environment, you are exactly correct. 10 seconds would be a ballpark number. In practical terms you do no hammer on one single account on a live web site because you want to avoid detection and you do not want the account to go into lock down. More typical attack is to iterate through accounts with a single login attempt. This way the attack is lost in the background noise of normal login failures, provided the host is not tracking accounts per origination IP. Repeat the list of IDs every few hours. This makes the first couple hundred entries in the dictionary are critical.
I understand any piece of information is valuable to a hack, but don’t see how knowing 370 passwords to exclude makes the game any easier. How long would it take to rule them out using brute force, 10 seconds?
It would be interesting to know just a little more about how the list is created. Might there be a much larger list of banned passwords that the script can’t access – perhaps in another database not accessible by the script? Not that I’m trying to defend them, but they may have made a calculated decision to disclose the worst offenders in an effort to just reduce the workload of the registration server processes.
But, then again, I wouldn’t bet against there being an as yet undiscovered flag or something in the script’s calling sequence that discloses all passwords ever attempted – ;o)
@Chris – Exactly, that for the older accounts, this list of 370 IS the dictionary. As you point out, test the 370 against all accounts over 2 months old. That list of accounts should be easy to identify or deduce by number of tweets or number of followers. I guess I was making an assumption that Twitter would have sent these people a nice note about password safety and possibly even a password reset link to ameliorate the problem. Then again, maybe not.
Adrian,
I think you may have it backwards, actually. I’m sure Twitter has added passwords to their forbidden list since they started accepting user signups, so some of those forbidden passwords will be on the list because a lot of users used them, and Twitter noticed that they were lame. So you can exclude them from accounts created from now forward, but if you’re attacking old accounts, those passwords are probably worth testing *first*.
Chris
Twitter’s banned password disclosure is yet another example of such errors by JavaScript lovers.
I tend to refer to the category as the “Bell Atlantic error”. Shortly before the merger which created Verizon (or added Bell Atlantic to Verizon), Bell Atlantic put up a web page which allowed customers to look up their account information.
All of the information–including things like the “problem customer” flag that the script would not reveal when used as intended–needed by the script came with the script. The password just told the script to reveal it on demand.
So capture the script, and there everything is–including information for non-published numbers. Anyone knowing enough about the account to get the script could learn everything–no password needed.
When this was pointed out, Bell Atlantic reacted quickly–by taking down the link to the page *and leaving the page itself in place*. So everything was still revealed.
Then the merger finalized, and Verizon took the PR hit. Really quite amusing to those of us not in Bell Atlantic territory.
–John
Quite! I was rather surprised when I saw the method by which they chose to implement prohibited passwords. I do believe this was originally implemented with the best of intentions…providing additional security for their user base.
It is an interesting thought exercise in the process of adding “security”, when not done carefully/properly, is not always the best method of reducing risk.