Can Snowden be targeted using the Adobe breach? | Hacker News Reader

Can Snowden be targeted using the Adobe breach?

7habitsofhighlyeffectivehackers.blogspot.com

229 pointsmafuyu91 comments

Mildly off topic but:

I've never been a fan of password hints, but I'll admit it had never occurred to me that they could be used this way. This is yet another reason to use an algorithm like bcrypt that will generate different hashes for the same password.

I'm also amazed people put such obvious password hints, and some even had their exact password as the hint.

A basic salted hash would prevent this sort of thing (not saying that bcrypt/etc. aren't worth using).

As to people using obvious password hints, it depends how much you care about the account - I don't use hints anywhere, but there's plenty of accounts I have where I really wouldn't care if anyone logged into it, so if I was someone who needed hints, then sure why not?

A basic salt could be just a fixed string being used. That would not prevent this. The salt would need to vary per hash.

The obvious solution is to salt it with something that is unique to that account: The internal account id, a string randomized at account creation or something like that.

An identical password for two different accounts should never encrypt to the same string.

The salt should always be random. If it's based on some account information it's possible that the salt can be regenerated if that account information would become available, in a DB dump like this for example.

If they had used different salts for every account, and that salt was published in this dump it would have been much more difficult to find identical passwords compared to the current situation.

I'm not sure how you can keep the salt random and secret, and still use it when users log in?

Salts aren't secret. The point of salting a password is to prevent the password (like "alskdjfalsdf") from always hashing to the same result (like "j9p+HwtWWT86aMjgZFLzYg=="). That prevents rainbow table attacks (among others) and it doesn't require the salt be secret.

Right. But the parent comment was replying to a comment suggesting that a user id (or other account information) shouldn't be used as it's not random.

I can't see why a user id could not be used as a salt though.

"I can't see why a user id could not be used as a salt though" thats exactly how people break crypto implementations, it seems ok but you dont really know. Don't just invent your own way, use the standard one.

If lots of sites all use user ids as a salt and all count up from 1 then a much weaker version of this attack applies: you can identify all the people who have both the same password and the same user id.

If this were common, someone constructing a lookup table for password hashes could include ones salted with the first N user ids. A N-times bigger table isn't something you'd be excited about as a cracker, but might still be practical.

If your user ids are randomly assigned this should be pretty much the same as generating a random salt. Still, the extra storage of a salt is going to be small compared to whatever else you're storing per-user, so better to do the safe thing and go with what's standard.

The salt is typically stored in the password db, alongside the salted hash.

If Adobe has taken that approach, the intruders would have all the salts, but they would not be able to do this attack of seeing how many people use the same password.

However, Snowden's silly password hint would still have given the game away. If that is in fact him.

Yes, it should be random but the salt is public information.

Exactly because you need it to calculate the hash and compare it.

If it's random, you need to store it, and it becomes just as available on a leak. The salt still works though, because it makes all hashes different. You need to attack each password individually rather than tackling them all with a rainbow table or something. The approach from this article also stops working. What you use as a salt is fairly irrelevant as far as I can tell.

If you want to get more security on top of that out of your salt, the only thing I can think is to add some security by obscurity on top: If it doesn't matter which field in the DB you use, just pick an unlikely one and keep secret which one it is. Might be id, email, favourite pet, or something else. Just don't forget to update the hash when the user changes that field.

This is a common misconception, but a "global salt" isn't actually a salt. Not sure what a "basic salt" is though.

> A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database.

http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Ah, I did not know that. And I wrote some password hashing with a global salt myself. So I stand by my comment with "one laughing and one crying eye". I thought salts were mostly against precomputed rainbow tables for specific hash functions, but of course if my hashes are valuable enough, a global salt makes cracking them easier than if I used a random/unique one per hash.

This is why programmers should stop trying to write their own password systems.

To be exact, programmers should stop using their own password systems (unless - well, let's not go there :).

Writing them is actually an excellent exercise, and humbling one too. Especially if you show your code to some skilled hacker / security expert.

From what I understand rainbow tables are not really used anymore -- they were useful when it took longer to calculate hashes, but nowadays you just need a decent graphics card to calculate a few billion hashes (MD5 or SHA1) PER SECOND.

Per-hash salts don't really slow that down at all, unfortunately.

Short-version: don't use the hash algorithms that are designed to be fast for protecting sensitive data; use something solid with a work factor instead.

Pepper is the more common term I've seen for a global salt - although I've never seen it implemented independently of a salt.

Isn't there value in having a long global salt to make bruteforcing harder in case the database but not the server code is compromised, though?

Think about it like this: Using a SHA256 + global salt is nothing different from using SHA256 with a different set of constants/initial values.

True, but if the global salt is secret, it'll at least make it slightly harder for the attacker to figure out the password.

For example, if the password is "a" and an unique salt is available in the database, it'll be trivial to brute force. If the password function is something like this, however: sha256("longsalt" + password + salt) the attacker will first have to figure out longsalt which can be slow if it's long.

Or am I completely mistaken?

But if hackers can break in and steal your database, they'll probably also be able to steal the global salt.

The recent MongoHQ breach is a counter example.

If you can steal the password hash database, stealing the shared "salt" is usually going to be trivial. Second, lots of hash functions are vulnerable to length extension attacks, so even if extracting the shared secret directly is hard, you can probably exploit the system to see what an empty password hashes to and then use that as a basis for brute-forcing the rest.

In other words: there is a reason why security experts and cryptographers recommend the password storage mechanisms they do.

I see, that makes sense. Thanks for explaining!

Amazingly, these aren't even password hashes.. they're encrypted versions of the password. Ars wrote an article on this yesterday [1]. Basically if anyone has the encryption key, they'd be able to decrypt ALL passwords in the list.

[1] http://arstechnica.com/security/2013/11/how-an-epic-blunder-...

Actually you maybe don't even need the key. I don't know what algorithm Adobe used to encrypt these passwords, but for most standard ones it holds that if you have two encrypted messages A' and B' corresponding to plain texts A and B, then B = A ^ A' ^ B'. You really only need to find one password of length N to be able to decrypt all passwords with length <= N.

Edit: Of course I mean two messages encrypted with the same key and initialisation vector. Do not reuse IVs kids, you'll get hurt.

That's true of stream ciphers, and if they reuse a nonce.

It looks like they used 3DES which is for all intents and purposes here, immune to a this kind of attack.

EDIT: If they use 3DES in a CTR mode then it could be vulnerable to this, but looking at the base64ed texts in the blog posts, they are multiples of 8 meaning it is almost certainly in a block cipher mode. Would be interesting to see if you can find any block similarities if they used ECB.

This is really neat. Adobe stated the hashes are 3DES/ECB.

So, say I have a two block password with '6aMjgZFLzYg' as the second block... when I just search for that block I see alot of hints that point to '123456789' as a password, implying the plaintext for that block is simply '9'. So now I believe the password is 9 characters long and ends with '9'.

lol; "should have used a salt" is one of the most hilarious HN memes.

My point wasn't that using a salt is good practice, just that Adobe's method was so bad that even a salt+hash would have been better.

Same - I like how he solved this 'problem'

This is also why shouldn't answer "secret questions" about yourself. These can be aggregated and gleaned from other sites.

Exactly how Palin's mail was "hacked", dog's name off of a wikipedia page.

That's why I use dd if=/dev/random bs=1 count=16 | base64 to rename my dog every 182 days. He gets a bit confused at first, but adjusts quickly enough.

> I'm also amazed people put such obvious password hints, and some even had their exact password as the hint.

This password protects something I doubt many people consider something that needs to be very secure. Why, therefore, should they use a complex password, or even feel the need to have a password at all? The risks associated with someone "hacking" your Adobe.com account are going to mostly seem like problems for Adobe, not problems for the user (and even the problems for Adobe are fairly dubious). Meanwhile, it is something you are pretty much never going to log in to.

It's like having a filing cabinet at your office that contains nothing but blank paper for the copy machine requiring a ten digit passcode. As the employee assigned a passcode for this cabinet, you are not going to consider the paper very valuable and you are hardly ever going to need to get into the cabinet to get that paper... why would you /not/ end up scrawling your passcode onto a post-it note somewhere (potentially even hiding it near the cabinet).

To get people to care about security you need to get them to care about the information being secured. In this case, I can't imagine most people would understand that anything in this account is valuable. Even to a more-trained-than-normal eye, it isn't 100% clear to me: you can read my tech support history (which might tell you more about myself or my work) and you can get my saved billing address (it does not save actual account information). My address (not everyone's, just mine) is already public record.

Really, the biggest concern is just that someone is going to change the e-mail address on my account and lock me out of it, preventing me from downloading licenses. I doubt your average normal user is going to even realize that changing the e-mail address on their account is possible, however (given the ways in which developers tend to use e-mail addresses and usernames interchangeably, I don't even blame them: this is a confusing concept and not every site provides the same functionality anyway).

Adobe do cloud photo storage, I believe keyed off the same account. That could be highly sensitive data.

People may have created their account and password for low value stuff and then started storing photos.

Your general point is of course correct.

Your filing cabinet example is spot on.

If the cabinet for storing blank paper that I don't care about (and it's my cabinet, not something entrusted to me for safeguarding) requires a passcode, then I'd both set the passcode to '0000000' or '123456', and write it on a post-it note right there.

Similarly, if some website or forum that I don't care about (and don't fear if someone or everyone accesses my account) starts for me to require an account+password that I don't want - then I'd both set the password to something trivial ('password' ?) and ensure that my browser stores it so I don't have to. In an ideal world, I wouldn't have that account/password at all - most of accounts listed in my browser password-list are accounts where some site forces me to keep a password that I don't want to 'keep an account', do 'personalization', etc.

For example, I have a (free) account on Spotify. Is there any good reason why I should have a secure password there? Is there any good reason why I shouldn't tweet that password to everyone, other that Spotify itself might dislike it?

They could've prevented this with using a salt, but instead of using a salt they make it even worse by not hashing but using encryption.

Basically if some one got the key they could get the passwords to everything including the FBI Agents and then they could possibly hack their emails.

In the screenshot, no one is using the exact password as their reminder, presumably because it isn't allowed. The reminders include 12345, 1234567, 123456789, 654321 and 1to6. The author concludes that the password is 123456.

Hints are really bad idea. I used to add that feature, but after seeing what people enter there I've removed it from all projects. Even without someone dumping your DB, people are usually too descriptive or they use some data they think is private, but that is actually easy to get with a little research and social engineering. I remember one guy's hint was: "The best car ever", and you could easily find that he posted a tones of pictures of his new BMW on Facebook... of course, the password was bmwrulez, it took me like 10 minutes to figure it out without any cracker app...

This is an interesting attack that uses other people's password hints to match a hashed password. However, it seems unlikely that the Edward Snowden would use such a weak password to protect any resource that he considered sensitive.

Please use a randomly generated password that is as long and complex as the site you're using will allow, stored in a password safe.

I don't trust third parties to securely store my passwords. The problem with randomly generated passwords it that they are hard (impossible?) to memorize. Password squares help there, because they allow you to visually memorize the password by using a path inside a random character grid.

I recently created a website that generates a random 'password square'. It should display nicely on latest browsers (which support flexbox). You can optionally supply a seed if you want to reuse the same path but have it yield a different password.

https://caurea.org/passwd/ https://caurea.org/passwd/#seed

The website is intentially barebones, to allow you to print it out and store offline.

> It should display nicely on latest browsers (which support flexbox)

So after years of telling people "Don't use table tags for layout", web devs have finally got that message... and they've started using layout tags for tables instead :(

In no way is that a table. It's a grid.

If you're memorizing a lot of passwords, you're doing it wrong. Use a password manager and memorize one, that no sites ever see. (In practice you'll probably want to memorize another one or two for important accounts and a login password.)

I tried to address that in the first sentence.

No decent password manager will expose your passwords to a third party. If syncing is supported, only passwords encrypted with your master password are sent over the network. AFAIK, that's how all the popular ones work.

FWIW, I use "pass", which is a short bash script that's a thin wrapper around gpg. If you can't trust that, I'm not sure how you can use a computer.

http://zx2c4.com/projects/password-store/

Btw, your password square generator isn't using a secure source of random numbers, which makes me highly doubtful.

> No decent password manager will expose your passwords to a third party.

Unless you are verifying the source and compiling yourself, your password manager IS a third party.

> FWIW, I use "pass", which is a short bash script that's a thin wrapper around gpg. If you can't trust that, I'm not sure how you can use a computer.

Sure, I probably trust GPG and the devs behind it. But unless you are downloading from them directly and verifying binaries, or building yourself from their source (and comparing source), you aren't really just trusting them, you're trusting the people that are distributing GPG to you. If the provider is a well respected linux distro, I probably trust it, but it's quite a bit less trust than the GPG devs themselves get. There's a lot more hands involved there and many more places for someone to inject some nefarious code, or just plain screw up[1].

I guess the real point is that "decent" in "decent password manager", or any security product for that matter, has higher bar than in many other industries, but this many not be common knowledge.

Edit: For that matter, I guess the only reason I trust GPG at all is that enough decentralized volunteers will look at it that coercing them all into keeping silent (or silencing them in another manner) about any backdoor they find is probably impossible (or at least requires enough effort as to make it unfeasible).

[1]: https://www.schneier.com/blog/archives/2008/05/random_number...

I agree with everything you said, but you're looking too closely at just the last link in a long chain. Yes, it's important to trust your password manager. I base that trust on my inspection of the short bash script and on the reputation of GPG and the Ubuntu distribution system. But 95% of the passwords stored in there are being pasted into chrome, which is a gigantically complex piece of code with hundreds of developers. They're passing through the selection buffer of Xorg, which is also quite a beast with many contributors over time. And of course I have to trust the Linux kernel! Not to mention the hardware it's all running on, which I'm sure has many critical parts manufactured in a country that harbors and probably sponsors people hacking into US companies and infrastructure.

Looking at the whole picture, using something like LastPass or 1Password in place of bash+gpg is only marginally less secure, and since non-techies are more likely to actually use them than some console-based thing, encouraging their use is a net win for security. Saying "you shouldn't trust a password manager that you haven't inspected line-by-line" is ultimately counter-productive. The people that have the most to gain from password managers can't even read code, and certainly couldn't spot a hidden side-channel.

Using a password manager? You're doing it wrong.

Manage your passwords like this: change them frequently. Remember them. Never write them anywhere you don't intend to use them.

You don't have to blindly trust a third party.

I have a KeePass which can generate random passwords. I trust that because it's open source, so I could look at what they're doing--and build it myself--if I wanted.

I store the db file in Dropbox, but I don't trust them either: my file is encrypted with both a unique password and a second key file which I've taken pains to only ever transmit by copying on removable media.

I'm guessing Snowden probably wouldn't use a hotmail account for anything sensitive.

I've been using PwdHash[0] for a few years now. It is basically a system for generating a password using your input hashed and salted with the domain name of the site. This takes the security of the password itself out of the hands of the site and allows for some password reuse. There are also browser extensions available which make it easy to use.

0: https://www.pwdhash.com

It strikes me that this only grows the length of your typed in password by one bit: did they use PwdHash? Y/N. The other components of the salt, namely the site details, are implicit.

It doesn't make your password for any particular site any harder to guess. It does avoid reuse, without needing to sync or otherwise remember N distinct passwords, which is worthwhile.

Reuse is the main reason why theft of password dbs (as distinct from just compromise of the site) is a problem for the user.

The question that the blog writer didn't ask himself is: How many people are called Edward Snowden?

He did, but didn’t write about it.

Lessons:

a) Don't have an email address with your real name in it.

b) Have several different active email addresses.

c) Never reuse passwords.

d) Only Use passwords that are a random string of alphanumeric characters.

e) Never use a hint that actually means anything.

I find it hard to believe that the real Snowden would use a single dictionary word as a password.

Regarding your last point, and as pure conjecture, it depends on how old the password is. When I was a student signing up for trial software etc. I often thought such things like "No one will ever guess 'offspring' as my password, that band is so obscure!"

Young me was much less paranoid than old me.

It's also possible that he only used a simple password for sites that don't matter - like Adobe - but used a stronger password for his e-mail, bank, etc.

On the other front, these passwords are all encrypted (not hashed) using 3DES in EBC mode.

Something encrypted with by (single) DES could be broken within 7 days about 2 years ago by some bespoke hardware.

If Adobe have been using the same key for each part of the triple DES key then you can assume that bespoke hardware of several years ago could get the key within 3 weeks (3DES being ~3 times the work of single DES). With advances in technology this is probably down to less than a week.

Let's just hope that they used a full 168-bit key, rather than repeating the single 56-bit key, and that it never gets leaked.

Using the same key 3 times would be equivalent to using 1 key and performing 1 encrypt operation.

It is almost certainly not the case that adobe is using the same key for all 3 operations. It's probably more effort to do anyways

Ah yes, I was getting the various Keying options mixed up in my head:-

http://en.wikipedia.org/wiki/Triple_DES#Keying_options

[EDIT]

It does seem odd though that the passwords are encrypted and not hashed, but the hints are in plaintext. Why didn't they also encrypt the hints? (Rhetorical, the answer is probably just laziness/incompetence).

Even if you do use bcrypt() or similar for hashing the passwords then encrypting the hints would prevent similar tactics being available from just a dump of the table contents.

Hashing is the correct way but big companies commonly do things wrong. If they had a sqli vulnerability in their site without knowing it's also possible that they didn't even know this database existed.

> ... could get the key within 3 weeks (3DES being ~3 times the work of single DES).

Absolutely not! Trippling the key length does not just triple the strength... Against brute force every extra bit will force you to invest twice the time. Though 3DES only provides an effective security equivalent to 112 bits even with the strongest keying option due to an attack on it (instead of 168 bits). It's still probably infeasible to brute force currently: The factor between brute forcing DES and 3DES is about 2^56=7*10^16 (that's a big number!), not 3 as you seem to believe.

>If Adobe have been using the same key for each part of the triple DES key

Very nice use of password hints.

Userwise salted hashes would defeat this attack though.

> salted hashes would defeat this attack though.

Seriously.

A huge company like Adobe behaving like a beginner in programming?

WTF.

That's the biggest WTF about the whole story.

I understand leaks and breaches happen, but we've had two decades of them and learned a few things that make DB leaks pretty useless.

They're still better than Yahoo!, who had 450K+ plaintext credentials dumped last year.

The best thing about leaking people's databases full of password hashes is teaching people how stupid it is to do it wrong. The worst thing is that most people in charge of this apparently don't read.

> A huge company like Adobe behaving like a beginner in programming? WTF.

You are aware that Flash and Acrobat Reader are the attack vectors for something like 50% of all Windows malware, yeah?

I'm sure you're also aware that, for all Adobe's faults, there's a world of difference between making mistakes writing novel software solutions versus not salting or hashing your passwords.

One type of mistake is inevitable on some level, while the other just should not happen.

"novel software solutions" - you work in Adobe's marketing department, right? ;-)

Adobe's engineering is often pathetic. This is entirely in-line with what I've grown to expect from them.

So this is effectively "crowd-sourcing" a hack - other peoples' collectively bad op-sec used against you...

So Edvard has the same password as 206 other people and you can get there email adresses. It should not be that hard to get the password.

So this proves that at some sites you really shouldn't use a password that it's likely a lot of other people will use as well.

Wasn't that already clear due to the threat of dictionary attacks?

Password hints are simply multi-factor passwords with, when used as intended, really crappy entropy and often crappy back-end handling/storage.

If you must suffer them, use random values that you note locally and store safely (just like your password). (Or that you don't store at all, simply foregoing ever being able to use the password hints mechanism.)

And, adjust your level of trust in and comfort with the site, accordingly.

So i was one of the millions affected by Adobe's hack.

Should I be worried, when I canceled my credit card immediately and used a spam address to sign up?

The only details the hackers would have on me would be my name, canceled credit card number, email address (spam email address) and answers to secret questions. Is there anything else I should be concerned about?

You should probably assume that they have your password too. Since Adobe encrypted the passwords instead of hashing them, all of these passwords will be known once the encryption key is discovered. Someone could possibly use the method in the article to guess your password as well.

So if you use the same password on any other websites, better change it.

You should probably immediately rename your dog and lobby your home town to change the name of the street where you grew up.

Top 100 using this hack

http://pastebin.com/iDTFARwq

So even if I don't use a password hint, other people who use hints will still give away my password.

Of course this is just an Adobe account. I don't think there's anything of value on there, is there?

Only if you use a password which can be obviously 'hinted at', and that's unlikely to be a very good password in the first place. Except, maybe, if it's a password phrase.

This is a perfectly interesting post, but why target Snowden? Guess it's eye catching

Linkbait scummery.

If you insist on rolling your own password scheme, just have the following:

A unique salt per account (eg the username or some stringb you store alongside the hash)

Key strengthening - run the has some number of times over 1000, preferably prime

Any kind of cryptographic has, I think even md5 would be fine if the above are followed

What happened to the "No change in Title" rule of HN?

Ah yes, the beloved security question.

Reply on news.ycombinator.com