Sophos Cloud Optix
An allegedly Egyptian hacker going by the name ViruS_HimA has allegedly hacked into Adobe.
According to himself, he’s made off with a largish database of personally identifiable information.
ViruS_HimA, who also goes by the name adam in his email address, has leaked what he says is a subset of the stolen data, aimed at giving some credibility to his claims.
The leak includes 644 database entries, supposedly split between Adobe, .mil and .gov email addresses.
I have Hacked into one of Adobe servers, Gained full access to it, Dumped the Database, It contains over 150,000 Emails, Passwords with full data for a lot of Adobe customers and partners including Emails and Passwords for "Adobe Employees", "US Military", "USAF", "Google", "Nasa", ".Edu" and many many more companies around the world!
In his leaked sample, Hima/Adam let a few non-US identities slip out. The occasional email addresses from countries as far apart as Argentina, Australia, New Zealand and the UK remind us of the global nature of the data he claims to have stolen.
Here’s a sample of his sample:
The leaked data could, of course, be from another source, or a mash-up from previous leaks, or even artifically generated.
Adobe hasn’t published anything official on its blogs yet, but is reported to be looking into the issue; we’re unlikely to know whether the company really was breached or not until it finishes its investigation.
[Update at 2012-11-15T12:41Z. Adobe has confirmed the breach. The company says it was hacked via its Connectusers forum. The Connect service itself was not breached. Affected users, it seems, have had their passwords reset for safety.]
In the meantime, if the data is real (whether it comes from Adobe or anywhere else), there are three giant problems with it.
NO SALT
Firstly, the passwords in the list are hashed, but without any salt. A salt is random content mixed with the password before hashing, so that repeated passwords do not cause repeated hashes.
You simply must use salted hashes, to stop crackers using a simple precomputed dictionary to crack your passwords super-fast.
NO ITERATION
Secondly, the hashes consist of a single iteration of MD5 applied directly to the password.
You simply must use many iterations of your chosen hash, to slow down crackers by making brute-force attacks harder by a factor as big as the number of iterations.
By the way, avoid MD5. It is known to have cryptographic flaws that entirely undermine its promise of security. In any new code, you may as well use the most recent officially-blessed hashing algorithm: SHA-3.
NO COMPLEXITY
Thirdly, as you’ve probably guessed, close to half of the passwords can be cracked in an hour or so with little effort.
You simply must use complex and non-obvious passwords, to prevent crackers from easily guessing what you chose.
Cracking this latest password list yields up the words breeze and connect (Adobe product names) four times each. Other repeated passwords include the what-were-they-thinking-of choices 123456, letmein and welcome.
A few users tried to mix it up a bit: c0ffee introduced a numeric character and Hello! included both upper case and punctuation. But modern password crackers don’t even break their stride to figure out that sort of permutation.
Even more robust efforts like Skan123$, ilbgw2g, lrwj4elj and th3tr12l don’t cut the mustard. Eight characters and predictable patterns are no match for automated cracking tools.
So, however Hima/Adam came by his data, take this as yet another password-protection lesson.
SALT. This confounds dictionary attacks.
ITERATE. This confounds brute force attacks.
COMPLICATE. This confounds guessing attacks.
To learn more about managing, choosing and policing passwords in your organisation, why not listen to our popular Techknow podcast on this very topic?
(If you prefer to listen offline, you can download the podcast for later.)
PS. Feeling a sense of déjà vu? Perhaps the Philips breach is why. Or LinkedIn. No? Maybe it’s the TechRadar incident. Or Mozilla.
"In any new code, you may as well use the most recent officially-blessed hashing algorithm: SHA-3."
Please, I beg you, for the love of God, do NOT follow this advice. SHA-3 is just as bad as SHA-2, SHA-1, or even MD5 for password storage. The correct advice is to use an algorithm specifically designed for password storage, such as bcrypt, scrypt, PBKDF2, or any of the modern crypt(3) algorithms.
I think you are confusing key derivation functions (KDFs), like PBKDF2, with cryptographic hashes, like SHA-3. Generally speaking, you need one of the latter *as a core part* of one of the former.
The point is that for a salted, iterated system for password storage, such as PBKDF2, you nevertheless need some sort of pseudorandom stream to munge the password and the salt into a storable form that is resilient to dictionary and brute force attacks. And for that purpose, you usually use a cryptographic hash. Like SHA-1, or – if you follow my advice – SHA-3. (WPA2, as an example, uses SHA-1 at the heart of its PBKDF2 implementation.)
In short, we are both correct – you for suggesting a good KDF (the salting and iteration part, loosely speaking), and me for suggesting a good, and officially recognised, hash (the entropy-mix-in part, loosely speaking.)
I heard that if you put a _ in your password, that hacker programs can't read it, so won't be able to use your passwords anyways. I want to know if that's true or not…
That is false.
If you can put a "_" in your password, what would stop a cracker or a cracking program doing so too?
If someone had asked me if "lrwj4elj" was a good password I'd have said it's OK. Is it just because it's 8 characters or is there a pattern in there I can't see?
keyspace is only 36^8. an HD7970 can blow through that keyspace in 4m30s as raw-md5.
Eight chars just isn't enough these days, even with randomly chosen letters and digits.
But there is indeed a pattern here – you can't see it because I obfuscated the username and email address.
What you need to know is that three of the letters in the eight (treating "4" as a variant of "a" and ignoring upper case and punctuation) are the user's initials, so the cracking software wasn't choosing from 36^8 possibilities at this point.
It was, I assume, trying all five-letter combos (36^5 variations) with three fixed letters added at one of six positions. That's about 1/8000th of the search space of the all-letters-and-numbers combo list…very do-able.
Would 8 characters be sufficient for a salted hash? Or is 8 characters just never going to be good enough ever again because of hardware speeds?
I can remember an 8 character password. I can sort of remember a 12 character password.
Honestly, I normally just remember one 30+ character pass phrase for KeePass and store all the others in there.
I agree with the fact that SHA3 (or any other SHA) isn't appropriate for password hashing.
As for the password "lrwj4elj", it's better than a lot of passwords sonce it shouldn't appear in most (if not all) password lists, but it wouldn't last very long against a brute force attack since it's only 8 characters long.
Well, for password hashing, you need *some* sort of hash algorithm (or a cryptographically equivalent, non-linear, pseudorandom, entropy-injecting, mixing-mincing-shredding-liquidising one-way function).
So if you aren't willing to use SHA-3 for that, [a] what would you use instead, and [b] why?
Bcrypt, for example, uses the Blowfish symmetric cipher algorithm internally. Scrypt (if I understand correctly) uses the SHA-256 algorithm, Salsa/20 and AES.
Or are you just saying, "don't rely on a simplistic solution such as N straight iterations of SHA-3 applied to salt+password?" If so I agree.
"SALT. This confounds dictionary attacks."
Salts do not confound dictionary attacks. Salts defeat time-memory tradeoff attacks, and slow down all other attacks by a multiple of however many unique salts there are.
What you seem to be describing is a shared secret, not a salt. Shared secrets are to be viewed as security through obscurity. If an attacker has sufficient privileges to dump a password database, he likely also has the privileges to view the shared secret. And once a shared secret is known, it's burned — it no longer provide any obscurity for the entire password database.
"ITERATE. This confounds brute force attacks."
Key stretching doesn't confound anything. It simply slows things down. And it slows down all attacks, not just brute force.
Salts most certainly do confound dictionary attacks, at least for my dictionary definition of "confound" (in the sense of going outside someone's expectations or comfort zone to a place where it is hard for them to follow), simply by making a precomputed dictionary more complex by a multiple of however many unique salts there are.
(If you read a bit further up in the article you'll see that I do say – albeit very briefly – what I mean by a salt, and why you would use it. I think it's reasonably clear there that I don't mean "shared secret". If I had meant to say "shared secret", I'd have written "shared secret.")
And you are perfectly correct that iteration "simply slows things down," nothing more, and for all sorts of attack. But this is the only sort of additional protection against brute force. You can make guessing harder by being tricky. You can confound, oops, sorry, you can, ahhh, defeat time-memory tradeoffs in precomputed dictionary attacks with salts. But "making it take longer" is your only defence against brute force – assuming the attack can be mounted offline, as in this case.
I think we actually agree – and I suspect that's actually fairly clear from my text – but that you would prefer me to have avoided the admittedly slightly archaic – and perhaps not entirely suitable-for-science – word "confound". I accept that critique.
However, confound is a groovy word, and you are permitted to make a metaphorical leap and think, "Confound their politics! Frustrate their knavish tricks!" when you see it.
Note that lines 5 and 6 of the sample have identical hashes (!) => we can see immediately that there is no salt (and the two users concerned immediately know each other's password …).
In the 644 leaked entries, there were only 632 different hashes. (As I mentioned, "connect" and "breeze" were repeated four times each.)
(The password of the two users in this example is so insecure and commonly chosen that it's deliberately placed near the top of the average cracking dictionary. Finding it took a fraction of a second. As you say, I only had to find it once, for a twofold result – another handy speedup.)
It just goes to show if a hacker wants your info then one way or another he will get hold of it. It seems to me the best Idea is get away from the internet. Just don't use it. Or make your passwords so so long and as complicated as possible.
Length will beat complicated passwords any day as they tend to be easier to remember. Changing 'a's for '4's and 'i's for '1's will impede a dictionary attack but doesn't affect a determined bruteforce attack as much as super long passwords.
A long password should defeat most attempts anyway. Salt effectively turns a raindbow table (precomputed hash table) into a dictionary attack, most tables if dictionary based are going up to ~16chars. If you look up the what most cracking tools target you can pick something outside of that and you should be relatively* safe.
Long passwords aren't enough on their own, of course. They do need sufficient complexity (or at least entropy) *as well*.
If you use a "correcthorsebatterystaple" approach, for instance, you get long passwords, but you pick – or at least are prone to pick – each of the four words from a list of just 1000 memorable terms, you are back to only one million million alternatives, or a bit below 2^40.
That's only half as big a keyspace as you get from an eight-character password chosen truly randomly from [a-z0-9] (1/200th the keyspace if you use [a-zA-Z0-9]).
I think you're underestimating the number of words in the "character set" of the average person. From wikipedia on Vocabulary Development: "By age 6, they have approximately 2,600 words of expressive vocabulary and 20,000-24,000 words of receptive vocabulary."
Even in "correct horse battery staple" , only the word "horse" makes the top 1000 most common english words list.
And I think you're misoverestimating the expected contribution that each of those words in that expressive vocabulary might have when you're thinking up correcthorsebatterystaple style passwords. (FWIW, Wikipedia's article on *Vocabulary* suggests, alternatively, that a six-year-old will have learned 1500 words – a far cry from, and perhaps more realistic than, your figure of 2600 to 24000 known words for a child of six)
That's why I was fairly careful to write "if you … are prone to pick … from a list of 1000 memorable words," rather than to estimate the size of your vocabulary.
Not just the average, but *every*, fluent reader of English has a literal password character set of well over 64 choices [A-Za-z0-9 and punctuation]. But there simply isn't 6 bits (2^6 = 64) of entropy per character in the average – or even in the best 5% – of human-chosen passwords. Lower-case "e" (or "3" if you are 31337) is going to turn up a lot more than "Q", and a whole lot more than "^".
Same, I suspect, with full words as your pasword "character set".
Here's an experiment you can try. Ask an average adult to say, out aloud, 1000 words, all different (no prompting and no feedback from you). Betcha the first 30 come out a heckofalotlot faster than the last 30, or even the second 30. And I betcha don't have to wait long until they first repeat a word, even if they try really hard…
Obligatory xkcd reference.
For the record, SHA-3 hasn't even been release yet. Nobody can use it yet. The algorithm has been chosen, but things like digest size have yet to be chosen.
So 9 characters isn't enough? What is then? 13 character passwords? Granted IT people will be okay, but how can you tell the masses to start doing that consistently?
It needn't be that hard.
You could use agglomerations of several words. The famous one is XKCD's "correcthorsebatterystaple" (so don't use that one 🙂 or "industrialzymurgyoverlandmountain".
You could use a phrase and abbreviate it, such as mapping "Will the USS Enterprise reach the next planet or has Kirk had it?" to:
WilltheUSSErtNp0rhKhi?
Or you could use a password manager program that creates randomized passwords automatically. Then you need only one ueberpassword to protect the password maanager's database.
Thanks for the update. I had some recent password changes I needed to make and your method helps streamline the thinking process for a long password.
Seems that home users should have a checker for password strength as well as some sort of intrusion detection since most all home security software has some hole in it. There also should be a way to “audit” or “certify” the websites that store our private information. Oh yeah, and a pony too!