Comments

wiredog • November 12, 2013 1:14 PM

Apparently FaceBook has been warning users who reused the same email and password on both sites to change their passwords. This thread at Krebs On Security describes how they know.

gawaine • November 12, 2013 1:17 PM

Really?

The same guys who put a guy in federal prison for pointing out that they used XOR with a fixed key to protect files?

I’m shocked.

Anura • November 12, 2013 1:39 PM

I think the takeaway is this.

1) You need to use a function like PBKDF2, Bcrypt, or Scrypt, with a decent salt, and I would say at least 100,000 iterations to secure your passwords; assume your database will be stolen.

2) Password hints are horrible

3) A decent password policy is essential, and ideally you would use a blacklist taken from RockYou or another major leak.

4) Secret keys do help, although you probably shouldn’t rely on them as if your database is compromised, your key may be compromised (goto 1). Oh, and don’t store your key in the database with what you are encrypting. I want to say this is obvious, but I’ve seen it done before.

On top of all of this, I think we need to teach creating passphrases in public schools; there is no substitute for creating strong passwords (well, okay, there are alternatives to passwords and multi factor authentication, but that’s besides the point!).

I’ve also been toying with the idea of checking dictionaries to make sure the password isn’t in the form Word || Number, but I’m not so sure that would be too frustrating.

Adam Baker • November 12, 2013 2:12 PM

I reckon the big take away from this should be that people won’t choose strong passwords for low value sites. The consequence of this is that when sites change what type of data they hold (such as Adobe changing from just logging registration data to being a cloud service) they should force a password reset

atk • November 12, 2013 2:15 PM

@Anura: why would you make those particular recommendations? where are your studies to say that’s enough? and for what level of security is this enough?

Garfield • November 12, 2013 2:36 PM

Another takeaway from this is that “trust The Math” is a bit useless when it is not solely up to The Math to protect us.

The Math is only half of the equation. The other half is the implementation.

If the implementation is ridiculous or has some logic issues then The Math that we are trusting becomes more akin to an abstract philosophical concept: a nice idea perhaps but one that is not used.

Ryan Ries • November 12, 2013 2:39 PM

@Anura I agree with you all except for maybe the password dictionaries… I think if we use long passwords (or phrases) with complex rules (capitals, special characters, etc.) you can still achieve decent security even with dictionary words. In my mind, the problem with forbidding dictionary words is that you’ve now inconvenienced the users so much by requiring such un-rememberable passwords, that many of them will turn to storing the passwords in an insecure manner, such as on a sticky note underneath their mouse pad.

Man in Black • November 12, 2013 2:43 PM

@Anura @Ryan – this leads to a Security Axiom. The ultimate point of failure is always the user. Your average user doesn’t even begin to imagine the need for security, so they are making their password as easy to remember as possible.

Brian M. • November 12, 2013 2:50 PM

@Anura:
On top of all of this, I think we need to teach creating passphrases in public schools;

Did you read the ArsTechnica article, How the Bible and YouTube are fueling the next frontier of password cracking? Those dictionaries include everything in Wikipedia and the first 15,000 books of Project Gutenberg. Correct battery horse staple is no longer a secure pass phrase. Neither is substituting leet-speak into the phrase, as the cracking setups already do that as part of the combinations.

For a graphic example of passphrase weakness, consider the string “Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn1” (minus the quotes). With a length of 51 and a 95-character set containing upper- and lowercase letters, numbers, and special characters, its entropy is 284.9 bits. The total number of combinations required to brute-force crack it would be 9551, making such a technique impossible on any sort of computer known to exist today. What’s more, the string isn’t found in any language dictionary. No wonder password strength meters like this one use words such as “overkill” to describe it.

But as Ars recently reported, Chrysanthou had no trouble cracking the SHA1 hash that corresponded to the string for one simple reason. This is a fictional occult phrase from the H. P. Lovecraft short story “The Call of Cthulhu,” and it was contained in this Wikipedia entry.

Ya know, that’s one of the down sides of the Internet and error-correcting modem protocols: line noise generated instant passwords for you. They weren’t memorable, but they were secure.

Edward Pwnden • November 12, 2013 2:55 PM

Via http://7habitsofhighlyeffectivehackers.blogspot.co.uk/2013/11/can-someone-be-targeted-using-adobe.html:

Let’s use this same method to see if we can target an individual account in the Adobe dump. Funny enough, there’s an entry for an account edwardsnowden@******mail.com.
6**58***-|–|-edwardsnowden@******mail.com-|-B***************CatHBw==-|-|–

Now let’s see if any other people in the dump have the exact same password hash as this account, and if so then how many.
[jdustin@localhost passwords]$ grep B***************CatHBw== cred | wc -l
207

Okay, let’s grab those 207 the lines containing all accounts who used that same password, cut out just their password hints, and then sort them by how often that hint is in the list:
[jdustin@localhost passwords]$ grep B***************CatHBw== cred | cut -d”|” -f5 | sort | uniq -c | sort -nr | head -n50

So, Metal? 74W on the table of elements? The usual Tung?
“tungsten” perhaps? Your guess is as good as mine. 🙂

https://mega.co.nz/#!5I0SxKoa!YhUuEBhK8083dS0XJy-njDXpnrlAgSvZdy6syxj7rIA

Anura • November 12, 2013 2:59 PM

@atk

I never said it is enough. The goal is to minimize the amount of passwords compromised; fully defending against compromise of passwords when attackers have access to your servers is impossible (if your software can check if passwords are valid, and the attacker has access to all the code and data, then he can check if passwords are valid).

Salt + key stretching are best practice to increase cost of a dictionary/brute force attack and prevent use of precomputation attacks (e.g. rainbow tables). I recommend 100,000 as it’s a good balance between significantly increasing the cost and not being ridiculous.

As for password hints and secret keys, you can see that the former made many passwords easier to crack whereas the latter is why they haven’t been cracked in their entirety. However, reversable encryption is bad because had their encryption key been stolen (which if you have access to the database, there is a good chance you have access to the key) then they would have had no protection whatsoever.

If you want good information on password policy (including blacklisting):

http://reusablesec.blogspot.com/2010/10/new-paper-on-password-security-metrics.html

None of this is a substitute for education about strong passphrases, but educating everyone is a lot more difficult than key stretching and a half-way decent password policy.

@Ryan Ries

I could go either way, TBH. Writing down passwords is less than ideal, but the quesiton is what your threat is. At an office, that can be pretty bad, for a home user, your main threat isn’t someone coming in to break into steal passwords, it’s someone remote.

@Brian M

That’s n interesting article. I like nonsense passphrases, personally (e.g. “When I was a boy, I witnessed Shakespeare being mauled by a pack of 17 rabid mollusks.” or the first letter of every word, as Schneier has suggested in the past WIwabIwSbmbapo17rm).

fajensen • November 12, 2013 3:31 PM

Why bother? Sites like Adobe or whatever do not deserve a proper password so I just use the same one all over the internet. Normally “bug-me-not” serves the purpose of avoiding to give “them” any usable information.

Besides, I like plausible deniability.

Fiona Morrigan • November 12, 2013 4:08 PM

@perl

only 24 chars? I prefer to use at least 70. But yeah, this is basically the only way to be sure.

Other than local network logins, I don’t see the use of password managers with pseudo-random strings like the being inconvenient.

Alex • November 12, 2013 4:45 PM

Does anybody know why things like PwdHash never come up in these discussions? What is the weakness of using such a tool for additional protection of adding your own level of hashing to an easily reproducible “master” password, that is easy or you to remember and is never stored anywhere?

ion ion • November 12, 2013 4:57 PM

fajensen: adobe doesn’t deserve a download. too big and lazy. but how about third world future mr. pulizer, today only with a mobile phone camera? they feel they need adobe as the ticket to the heavens. so they register to hear about the next discount in licensing. myself i was pushed by a large hardware manufacturer. they’re cheap enough not to develop any software for their products. and epub support is crap on linux. as for their android phones, the do not care if the next idiot is going to play cops and robbers via tor while receiving updates from google. the manufacturer cares if people buy. and they buy. so i had to generate an account on adobe.com to activate my 100 space credits reader. today i remembered about that account and took the opportunity to check their help desk. when the guy on the other side understood i don’t want to change my password or my username offered to register my phone number too, so i could get a free phone call «in order to delete your account». than he, or she, needed to send an email on the registered address, which doesn’t exist anymore. so i said thank you and good bye.

this is how they get the large database.

fiona: 70 chars?!? most online services are capped somewhere between 16 and 32. over the years i had the peasure of doing business with servers that did such a thing without telling. so put a 70 char password, anything beginning with the first 16 works. does that hint something?

Anura • November 12, 2013 5:08 PM

@ion ion

What’s fun is when they set the max length field of the textbox when you set the password, but not when you go to log in, so it’s something like 12 characters, but you type in a 20 character password without noticing. Until you realize this, you have to keep resetting your password every time you want to log in.

Greg A • November 12, 2013 5:32 PM

facebook say they have just warned the users whose password have been trivially guessed. They could do much better:

Privately disclose their password hash function and salt for all users whose email address was in the adobe dump.
This could be to adobe or to a trusted 3rd party.

adobe or 3rd party decrypts the passwords of all affected users and hashes according to facebook provide algorithm.

they might then apply an additional hash to add a little security

send results privately back to facebook

facebook now know everyone who password was the same on both sites, and therefore at risk of being decrypted in the (near) future.

  • neither facebook nor adobe get to see the plain text passwords of users on the other’s system
  • finds all matches

Tim Bradshaw • November 12, 2013 6:24 PM

No one has mentioned this: if the passwords were encrypted, there’s a key, and that key can’t be changed in the stolen data. If someone knows, or could find out, that key it is probably worth quite a lot to people who might be interested in it: the sort of people who might be willing to be a bit unscrupulous in getting hold of it (’how many fingers is the key worth?’). I am glad I don’t work for Adobe right now, and I hope they are giving good advice to the people who work for thrm.

Me • November 12, 2013 6:45 PM

Adam Baker.

Thanks for giving me a laugh. Every website thinks their website is a high value site, even if it has nothing but cat pictures. At this point in time if the website makes the password more than word+number I simply stop using that website. I do not have time for password BS.

99% of the time a hacker steals my password my response is to yawn. There isn’t anything I have worth protecting on most sites. Let them have my account; I do not care. I’ll just create a new one.

Dirk Praet • November 12, 2013 7:44 PM

I propose Adobe compensates all affected users with

  1. A free copy or upgrade of an Adobe product of their choosing (not a trial) for not using salted hashes.
  2. A second one for lack of clarity in its breach notification.
  3. A third one for setting a new record with 150 million accounts implicated.

Nothing is ever going to change as long as even the big boys refuse to take their security seriously by not complying with simple industry standard best practices. I find it hard to accept that internet facing services are not properly audited for this sort of stuff or that nothing was done with the results of such an audit. I hope they get slapped with numerous lawsuits from folks that had their accounts, personal information or credit card data abused as a result of this MFU.

Baron • November 12, 2013 7:52 PM

What’s so bad about losing passwords? What’s really bad is if the passwords were made public, or exposed, or leaked — rather than being lost.

Hypp0critter • November 12, 2013 9:12 PM

Why would you even store passwords at all in any kind of reversible encryption? Hash them. Basic security. When the user logs in, hash that password, match the hash that is stored. Might want to hash the answer to those secret questions too. Can’t hash the questions themselves, but you could at least encrypt those.
This is not really all that advanced. Adobe should know better.

Alex • November 12, 2013 10:29 PM

@Tim Bradshaw

Assuming that someone doesn’t just figure the key out, considering that there is a good sample size of passwords that were already “recovered” using the plain text “password hint” data included in the leak.

paranoia destroys ya • November 12, 2013 10:50 PM

Adobe concerned about security?
Why would we expect anything different from a company that puts out new versions of their software without addressing vulnerabilities from the previous version?
It took them 10 years to have fully Mac OSX compatible programs (not utilizing the transitional Rosetta software). When they did it had a feature for creating content on tablets 2 weeks after the iPad came out.

Clive Robinson • November 12, 2013 11:12 PM

As I’ve said before in general humans have a memory issue and cann’t remember a four digit pin let alone a telephone number without lots of re-use.

So they use other methods to generate / remember passwords. And for obvious reasons the method remains constant across services whilst the password may not.

For instance people have suggested in the past a “master” string with a service related string concatenated so if for instance you used the following,

    WhyJohnycann’tencryptAdobe1

Anyone viewing the decrypted password from the file might guess your Google Email password is,

    WhyJohnycann’tencryptGoogle1

Now if as may be likely the attackers have the file encryption key from downloading not just this encrypted password file but from source code then such “methods” become known to the attackers.

But even if the attackers did not get the encryption key we now know from the Ed Snowden revelations that the NSA would almost certainly have hoovered up the password file as it went by on the network.

I’m also guessing that for legal reasons the NSA would not treat passwords as protected “content” but some form of unprotected “meta-data” and thus regard finding the passwords and “methods” as a worthwhile activity…

So whilst “simple passwords” are fairly obviously in danger do not make the mistake of thinking your “method” won’t be found out the chances are quite likely that it has…

So please remember for your own sake that “human memorable passwords and non crypto methods” are well well beyond their shelf life.

Wintermute • November 12, 2013 11:54 PM

Yes, and I had to change most of my favorite passwords. I will always despise Adobe to the next power for this.

Skeptical • November 13, 2013 1:14 AM

“Those dictionaries include everything in Wikipedia and the first 15,000 books of Project Gutenberg. Correct battery horse staple is no longer a secure pass phrase.”

I don’t think so. Looking at each word as an indivisible unit, a random choice of four words yields n^4 combinations where n is the number of words in your dictionary. That’s over 500,000 ^ 4 = 6.25 x 10^22 possible combinations for a large dictionary like the Oxford English Dictionary. You’re not beating that by brute force anytime soon, no matter how big your word list.

The real problem is getting people to choose words at random. People suck at making random selections, so you can’t leave the choice up to the user. That’s where something like Diceware comes in, where a small dictionary coupled with a set of 6-sided dice is enough to generate strong passphrases given at least five words.

Albert • November 13, 2013 2:35 AM

I compared this dump to other popular dumps, and because of the strange way Adobe stored their passwords (on the backup system, which was what leaked) fewer plaintexts have been recovered than usual. In a normal dump 50% of the passwords are recovered within hours and after a week 70-80% or more. In the Adobe dump a much lower percentage has been recovered since they used encryption (3DES in ECB mode) instead of hashing, and the encryption key has not been recovered. It is unlikely the key can be broken (but it might leak). On the downside, if the key is leaked all passwords will be recovered immediately. That would lead to a gigantic wordlist, even bigger than the notorious “rockyou” list.

Mike the goat • November 13, 2013 2:51 AM

Clive: I must admit that I use a pretty simple system where I have a secret to which I append the name of the site and run through a hash to give me a unique password for every site and I don’t need to maintain an actual password list that could be compromised. Almost every system (including my android phone – I just use the terminal emulator) has the necessary tools for me to do this, so it is a trade off between security and convenience.

I won’t give the exact details of which hash and how I format my secret and sitename but consider something like:

echo “mysecret sitename”|sha1sum|base64|cut -c1-20

Yeah, there are a number of issues with doing it this way but I feel that at least I mitigate having to remember all passwords, reuse passwords (very bad), or keep a list of passwords – even encrypted I am not comfortable with this especially when travelling to countries with mandatory key disclosure at customs.

Clive Robinson • November 13, 2013 3:23 AM

@ Skeptical,

Whilst the “correct horse battery staple” method if done correctly might still be secure, “correct horse battery staple” is most definatly not and would be in the dictionaries of password cracking software (which I think is the point Bruce was making, by including it with a list of common literature.

@ Albert,

With no rainbow table or equivalent available or likely to be without a key then the recovered plaintext will remain low and based on “hint guessing”. Unless another source is made available, for instance some people with both popular passwords and EMail addresses could be socialy engineered, or having gone through the pain of changing there passwords might decide to “release” their password to to make Adobe feel more pain…

I must admit that if I was in the list and found my password was “popular” I might be tempted –as I’m sure some people might be– to try it on somebody elses account such as their email…

From a “strength per bit of input” encryption is going to be stronger than a hash provided the key remains unknown, and also faster than the use of hashes.

If Adobe had simply XORed the users password with a salt of some kind (such as the ID number) prior to encrypting the content of the file would have been very much different and even with the hints would have still been much much harder to guess…

There are a whole host of other very simple and quick things they could have done but they did not, which makes me wonder why…

Rob • November 13, 2013 3:29 AM

Another interesting discussion.

As an aside to the issue of choosing passwords, I am increasingly annoyed by sites – and the ones I am thinking about are banks, so non-trivial usage – that ask for selected characters from your password. E.g. what are the 2nd, 5th and 9th characters of your password. And you get 3 attempts before you have to do something really annoying like phone the helpline, where they will again ask for selected characters.

This really discourages using human-unfriendly passwords and almost forces the user (well me anyway) to write down the password so I can count my way through it. Damn – I even have to do that for relatively simple, everyday words never mind the “h^6Dee£2j3xG?;-)cc” passwords that I try to use for important sites. So then I have a written plaintext password lying about that I have to remember to shred.

Clive Robinson • November 13, 2013 3:40 AM

@ Mike the Goat,

There is a very important difference between what you do and the “human brain” method, and that’s the crypto of the hash you do.

Because you are –I’m assuming [1]– the only person who looks at the plain text it’s not obvious to a person looking at the hashed version that it has any structure. Further if the did try and look it up via rainbow tables the chances are it would not be in there.

[1] I’m assuming no CarrierIQ type malware or other user on your system to do a ps etc and see your command line, or history file for root to look through.

Israel • November 13, 2013 3:59 AM

@Mike the goat: “travelling to countries with mandatory key disclosure”

If you enter Israel, you will be asked to log in to you e-mail account. Typing your secret shell line in front of them.

Winter • November 13, 2013 4:27 AM

A rule of thumb:

If Google can find it, the password is less than 54 bits strong

More specific:
The Internet contain some 10^19 bytes, in total. That is less than 2^70 bytes (less than 70 bits). Google indexes around 10^15 bytes (~54 bits and growing). If your password can be found on the Internet, it is less than 70 bits strong. If Google has it, it is even less than 54 bit strong.

Autolykos • November 13, 2013 5:09 AM

@Winter: But is it really a good idea to type a password you’re about to use for something sensitive into Google?

Mike the goat • November 13, 2013 5:14 AM

Israel: I have a throw away account that I use for such situations (and yes I have been detained for a “thorough vetting” on one occasion which included a look at my cell, a request for my email account password and even an X ray). I usually take an old android handset on trips to unenlightened countries, which I do a factory reset on and setup the throw away gmail account on. I generally swap my laptop’s HDD out and put in a clean one before leaving. I clone my stock windows 7 image onto it, which includes the manufacturer recovery partition (it was actually the drive the laptop shipped with originally, I immediately swapped it out with an SSD. I also don’t use Windows) as well. When in country I can connect to the internet, download whatever tools I need. Before leaving I press the recovery hotkey on boot and select the “erase and reinstall windows” option. The great thing is the tool does a block level erase of all but the recovery partition (obviously) so I don’t need any other tools. Sure, it’s not as good as using the drive’s firmware to do a secure erase but nonetheless it is an easy way for me to travel without too much trouble nor do I leave company confidential data for customs/TSA goons to look at.

Mike the goat • November 13, 2013 5:29 AM

Clive: I’ve done similar things for quite a few years and it is quite an effective strategy. My “secret” is quite long and is not English or natural language. There are a few sites (2 exactly) that have very simple password policy and won’t allow any characters other than alpha and 0-9. For these I omit the base64 with the understanding that the entropy in a hex password of the same fixed length (20 chars) is substantially less.

Unfortunately passwords remain the weak link on the Internet. I recently helped a smallish company migrate to two factor authentication and it was a roaring success. We got a hold of some hybrid smart cards (standard pkcs smart card with additional mifare style NFC module inside) and with the aid of an ID card printer they doubled as employee ID cards.

So they got a great solution – photo identification, building access control and authentication for their workstations. It took a bit of mucking around to get it all working but when finally implemented it worked a treat. We even got these gemplus smart card readers that slotted into the PC card slot of their laptops to provide the road warriors with the same benefits. Very cool, and augments the weak outdated “password”

Winter • November 13, 2013 5:36 AM

“@Winter: But is it really a good idea to type a password you’re about to use for something sensitive into Google?”

Anything entered on a web page, Google included, has become insecure as a passphrase. You will have to guess whether Google can find it 😉

stine • November 13, 2013 7:07 AM

re: Autolykos • November 13, 2013 5:09 AM

If you’re using Firefox, select a couple of words and hit CTRL-C. Now right-click. Notice that one of the options is “Search Google for ‘[words]’.
How do you know that it hasn’t already done so (think Google instant)? A few minutes with Wireshark will demonstrate that Firefox earlier than v24 don’t. All it will take is someone at Mozilla to open a bug report claiming that the word ‘search’ should really have been ‘see’, and that the search should have already been completed by the time you right-click.

Some of my systems say ‘Search Amazon for…’ instead, and I’ve never been able to figure out where that’s coming from (and I’ve been too lazy to download the sourcecode and find it).

Andrew Yeomans • November 13, 2013 7:54 AM

I’m still amazed at the number of wrong lessons being stated in the comments.

As I mention on the Sophos blog, the failure to encrypt the password hints is the key blunder. In fact, no-one is sure the true passwords have been found, unless they tried actively (and illegally) to use them, as there are no reports that any master encryption key has been revealed yet. Whereas in the other examples of password hash breaches, we know for sure that the cracked passwords are correct.

This demonstrates the power of encryption – the passwords have not been cracked – not yet, and maybe never for millennia. Whereas use of other standard hash functions such as PBKDF2 quickly lead to a reasonable proportion of cracked passwords using dictionaries.

This breach also demonstrates the serious weakening of the process caused by using password hints, in that people just give away the answer. Password reset questions (“what is your pet’s name”) are likely to be a bit better (not that I think they are very secure either), as the answer can go through a one-way hash.

Perhaps this case study indicates that it might be a good idea to encrypt your password hashes, so long as you can protect that secret key (i.e. salt the passwords, hash them, then encrypt the result). That way it won’t be possible to simply crack the backup tapes, or wherever the Adobe data was taken from.

And even better, architect the password database system so it is practically impossible to extract passwords or hashes out of it, even by administrators. HSMs do this pretty well for PKI, why not ordinary passwords too?

Dirk Praet • November 13, 2013 8:59 AM

@ Andrew Yeomans

As I mention on the Sophos blog, the failure to encrypt the password hints is the key blunder.

Good point. Let’s add a fourth free product or upgrade to the compensation list for affected users for failing to encrypt the password hints.

Les • November 13, 2013 1:07 PM

This story has the usual takaways.

For users:
Don’t re-use passwords on important sites: bank, email provider, some key vendors, social notworking.
Everything else doesn’t matter. Who cares if you have to create a new Gawker identity?

For devs and admins:
Salting works. It may not make targeted attacks more difficult, but it would make this password file 150 million times more complicated to crack.
Don’t be lazy. If you can encrypt the password field, there’s no reason not to encrypt the password hint. And the backups. And everything else that contains sensitive information.
“IT Security Specialist” is not a real occupation yet. If Adobe and Sony and dozens of other billion-dollar companies can’t do better than this, there’s a big problem in IT Security. How did such an amateurish design get to production? That’s a sign of generations of programmers who only know enough about security to get themselves in trouble, and executives who were gullible enough to hire them.

Mike Amling • November 13, 2013 2:08 PM

@Albert: Good point. If some of the salt of standard salt-and-hash were a secret that didn’t leak when the PW database leaks, then using the database entries to confirm password guesses would be much more difficult.

Hash input is, say, 32-bit per-user salt || 80 bits global secret salt || password; iteration count and space use (e.g., Catena) as ever. If the global secret leaks, too, at least your users are no worse off for it.

Brian M. • November 13, 2013 3:17 PM

@Skeptical:
I don’t think so. Looking at each word as an indivisible unit, a random choice of four words yields n^4 combinations where n is the number of words in your dictionary. That’s over 500,000 ^ 4 = 6.25 x 10^22 possible combinations for a large dictionary like the Oxford English Dictionary. You’re not beating that by brute force anytime soon, no matter how big your word list.

That depends on what’s actually being used, doesn’t it? (obligatory XKCD link) The average person has a vocabulary of less than 100,000 words, and usually uses less than 1,000 per day. The low grade cracking system featured in the article does 30 x 10^9 tries per second. A high-end system would be roasting through quite a few more, dontcha think?

Point of fact, the OED Second Edition contains about 228,132 words in it. The cracking “dictionary” contains over a billion words and phrases in it. Then you come up against the limits of the web sites themselves. For instance, one of the credit card websites I must use has a password length of only eight characters. (Why? Oh, why??) Eight characters are in rainbow dictionaries, for heaven’s sakes! No cracking required!

Your information is as safe as the weakest link. Sucks, doesn’t it?

Brian M. • November 13, 2013 3:25 PM

@Sleep Now:
How is that secure? Can’t anyone get my password by running the same code?

The code gives a bunch of random characters, each time it is run. Install Perl and run the code, and you’ll see things like:
d (<}Mmi!;Zn_VK0.R$-kgGC
|}#rfL38?v>X`@fGE^uZwJC(
hg0=Ng?D}WdH”,V %|Yae’z’

Now, let’s pretend that a website would actually accept a 24 character password…

Skeptical • November 13, 2013 9:43 PM

@Brian M:

I haven’t read the article citing 30 x 10^9 attempts per second. What’s the method? Where can I find the article?

If it involves a dictionary containing “a billion words and phrases”, you can be sure it’s useless against a passphrase drawn from a possible space of 6.25 x 10^22 randomly chosen four-word phases. Remember, for a method like “correct horse battery staple”, the dictionary is the alphabet, not the target.

In any case, assuming 30 x 10^9 is correct:

A 100,000 word dictionary would give:
10% chance you’ll crack it in 10 years.
50% chance you’ll crack it in 52 years.
100% chance you’ll crack it in 105 years.

A 200,000 word dictionary would give:
10% chance you’ll crack it in 169 years.
50% chance you’ll crack it in 845 years.
100% chance you’ll crack it in 1691 years.

perl • November 14, 2013 11:01 AM

@Mike the goat @Anura

Noes!1! base64 misses 6 tenths of a byte per character compared to using all 95 printable ASCII characters.

@Fiona Morrigan, “only 24 chars?”

No, that is my 60 character password,

perl -le ‘print map { (map {chr} 32..126)[rand 95] } 1..24’

Please don’t tell.

perl • November 14, 2013 11:08 AM

@ Brian M., “let’s pretend that a website would actually accept a 24 character password…”

perl -le ‘print map { (map {chr} 32..126)[rand 95] } 1..16’

Anura • November 14, 2013 11:28 AM

@perl

Yeah, but many sites disallow special characters, and it’s just much nicer mathematically as each character is 6 bits vs (ehh) bits with base95. 24 base64 characters = 18 bytes = 144 bits = probably good enough to prevent guessing. 9 bytes/12 characters/72 bits is probably good enough in practice, actually (although I do come across sites with a 10 character max password length on occassion). Not like round numbers of bits is really that important, but still, it matters to me, dammit.

perl • November 14, 2013 11:29 AM

@Sleep Now, “How is that secure? Can’t anyone get my password by running the same code?”

Only if you’ve used the same seed. Try this over and over:

perl -le ‘srand(1234567890); print map { (map {chr} 32..126)[rand 95] } 1..24’

Also note man perlfunc:

“rand()” is not cryptographically secure. You should not rely on it in
security-sensitive situations. As of this writing, a number of third-party
CPAN modules offer random number generators intended by their authors to be
cryptographically secure, including: Data::Entropy, Crypt::Random,
Math::Random::Secure, and Math::TrulyRandom.

Mike the goat • November 14, 2013 12:53 PM

Perl: yeah aware of that, was using base64 for the reason Anura mentioned – many sites freak out when using plain ASCII characters that aren’t typical – for example quotes both single and double amongst others. Sticking with base64 is “safe” – although you could pipe it into ascii85 if you’d rather 🙂

Brian M. • November 14, 2013 1:07 PM

@Skeptical:
I haven’t read the article citing 30 x 10^9 attempts per second. What’s the method? Where can I find the article?

The article is the Ars Technica link I posted above. I think it’s on page 3, and remarks that it’s an $800 system. There’s plenty of information with a Google search on a “gpu password crack” term.

Yeah, I did the math. A “readable” password generator should first exclude the first N common words, and then use what’s left over. As the OED article stated, all told there’s maybe over 750,000 words in the English language. So where is “correct battery horse staple” in that? It’s in the relatively common group, which is checked first.

@perl:
Yeah, I know, it’s just that the stupid account is 8 characters, and is limited. (RANT: What is up with the poor security on financial institution web pages??? Did they hire someone’s cat to do the programming? “I can haz gud pazwurdz criptoe.”)

Anura • November 14, 2013 1:31 PM

@Mike the goat

Well, I figure anything less than 256 bits is insufficient for the post-quantum world. You have to assume that the people trying to break your password for news comments or whatnot will have access to quantum supercomputers soon.

Howeve, you could always save yourself code and do md5sum /dev/null

TRX • November 14, 2013 1:39 PM

@BrianM said:

one of the credit card websites I must use has a password length of only eight characters.

site: Enter Password____________________

TRX: ****************
site: PASSWORD ERROR! Password may not be longer than 8 characters or shorter than 3 characters.

TRX: ********
site: PASSWORD ERROR! !@$%^)(*&^ not valid for use in passwords.

TRX: ********
site: PASSWORD ERROR: -_=+ not valid for use in passwords

TRX: ********
site: PASSWORD ERROR: password contains dictionary word

TRX: ********
site: PASSWORD ERROR: password must contain both upper and lower case letters and at least one numeric digit

TRX: ********
site: PASSWORD WARNING: password too easily guessed. Try another password?

TRX: f*** y**
site: PASSWORD ERROR: spaces not allowed in passwords

site: TOO MANY PASSWORD ATTEMPTS. PLEASE CONTACT CUSTOMER SUPPORT. OUR HOURS ARE…

Brian M. • November 14, 2013 2:33 PM

@TRX:

Yep, that’s it!

One company I worked at had, as its programming interview, some code to analyze. It turned out that it was a truly lousy Caesar cypher, which was written by a former employee. The company was afraid to upgrade it to something better, as they didn’t want to take the chance that during an upgrade the account passwords would be lost. Another company stored “encrypted” passwords, which were XORed against the name of one of the company’s owners, who had written the code.

Beware proprietary encryption, as it might as well be plain text.

Scott • November 14, 2013 3:14 PM

My favorite was seeing code with the variable “Base64EncryptedCCNumber” that got stored in the database. Was it encrypted and then encoded in base64? Nope, it was using straight base64 encoding as the “encryption” algorithm.

Skeptical • November 14, 2013 3:48 PM

“The article is the Ars Technica link I posted above. I think it’s on page 3, and remarks that it’s an $800 system.”

OK. It looks like the cited figure of 30 billion attempts per second is for Windows 7 passwords. Although impressive, I doubt it would do as well for something like BCRYPT.

Autolykos • November 15, 2013 6:02 AM

@Brian M: I doubt uncommon words actually make it much better. They are harder to memorize than common words, but there aren’t that many more of them. Just using one more common word might be both easier to memorize and more secure.

Skeptical • November 15, 2013 11:11 AM

@Autolykos,

I suppose the role of uncommon words in this context would be similar to that of special characters in passwords.

Anonymous Coward • November 17, 2013 4:10 PM

Why would you even store passwords at all in any kind of reversible encryption?

My boss refuses to allow them to be hashed. If the user wants their password recovered, it gets mailed to them in plain text. No amount of presenting him with evidence of how bad his decision is can change his mind.

Programmers know better. The problem with these incidents is management. And the only way that these mismanagers will change their ways is for their company to be hacked and for the irresponsible mismanagers to be fired.

How did such an amateurish design get to production?

You can’t change it when management refuses to allow it to be changed. Everyone in our group knows that if the next security “audit” actually looks at the database, we’ve got our work cut out for ourselves. The boss, he has his idea of what the customers want (cue the scene from Office Space where the guy says “I have people skills”), and a Machiavellian talent for keeping corporate away from our office (along with firing people who go around him) and you may have a better idea of what sort of technical inertia/debt is out there.

Beware proprietary encryption, as it might as well be plain text.

Funny you should say that.

one of the credit card websites I must use has a password length of only eight characters

One of the timecard sites I use when contracting through a particular “bodyshop” (one that specializes in government contracting) only allows digits, and exactly 8 of them. Presumably it was for the era when people could use a touchtone phone and before this newfangled internet stuffs.

Leave a comment

All comments are now being held for moderation. For details, see this blog post.

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.