Nope. They had the (unsalted) hashes of the passwords in that single list. The hashes of the multiple people were the same, therefore the input string they were calculated from (the password) was the same. So the password hints were possible to use together.
Salting helps a lot here. A simplest way is to calculate the hash not from the password itself but from the combination of username+password. (Another approach is using some random string added to the password file in cleartext.) That ensures that even users with the same password have different hashes, and that no password-hash list is likely to have the combination (caveat: system accounts like ârootâ, âadminâ, etc⌠where the username is known and common will likely weaken this claim).
Would having accounts to these services before a breach help? If you know what your password is, can you use that and the hash value to figure out other peopleâs passwords from their hash value? Or at least narrow it down to a reasonable number.
You can use your password to generate its hash (there are multiple algorithms in use, the most common are MD5, SHA1 and SHA256). It works only one way - ideally there is no other way to get the input from the output, other than trying all the input permutations until you hit the gold. (In reality, you can calculate hashes for the most common inputs and have a lookup table. Which is what is happening here.)
A low-cost way for this may be âself-saltingâ - using the service name as part of the password, e.g. instead of password123 use adobecompassword123 for one place, googlecompassword123 for another, etc.; if your cleartext password gets compromised, all your services where you used it are as the approach is rather obvious - but if a hash leaks, as it happened with the Adobe thing, you stay secure.
What do you mean by having an account to âthese servicesâ? If you mean the password-hash reversing, nope, would likely not help at all.
[quote=âshaddack, post:22, topic:41223â]
They had the (unsalted) hashes of the passwords in that single list. The hashes of the multiple people were the same, therefore the input string they were calculated from (the password) was the same. So the password hints were possible to use together.
[/quote] Okay, I get that much⌠but I still donât understand how they knew Ton had an Adobe username, or which username was his. Were the usernames unencrypted, and/or did they get his username from the phoneâs metadata? How was the phoneâs metadata used in all of this? Apologies for what are probably ignorant questions.
I donât know how they knew his username. My hypothesis is that they either knew he logged in there from a URL (browser history, aka phone metadata), or they had the list on hand and took a look just in case. Most people share the same username across services and it is usually stored in plaintext as it is considered a public(ish) information.
Well I meant that if the people trying to figure out his Amazon password already had (presumably several) accounts with amazon before the hashâs were compromised. With the knowledge of their own passwords AND the hashes that went with them could they then figure out the algorithm and variables used to hash the passwords and therefore work back from the hashesâŚEspecially since with multiple previously existing accounts you could have a variety of identical and slightly different passwordsâŚIf identical passwords have the same hash numbers with different account names, than the account name is NOT used to vary the hash numbers. Presumably several passwords that are different by one character would narrow down the possible algorithms used to generate them.
If you get two or more identical hashes in a password file, for different accounts, it is a strong indication of per-user salting not used.
Hash functions are specifically designed to resist differential cryptoanalysis, so feeding them with bit-by-bit different inputs should not give the attacker enough information to weaken the hash. Even a very slight difference will produce an entirely different hash; the function is iterative and the differences spread and propagate with every round.
Example, with MD5 (and it works the same with other functions too):
password0 -> 305e4f55ce823e111a46a9d500bcb86c
password1 -> 7c6a180b36896a0a8c02787eeafb0e4c
Note that inputs differ by a single bit; â0â is 0x30, â1â is 0x31 in hex (or, 48 and 49 in decadic). (I didnât use â1â and â2â as then the step is flipping two bits, not one. I wanted just one to underline the point.)
Finding inputs that yield hashes with a given number of trailing zeroes is even used as a âproof of workâ in Bitcoin mining. Without very very advanced math unknown even to the cryptographic community and hopefully impossible (hi, NSA!), or a side-channel attack (think keyloggers or shoulder-surfing), it is pretty much impossible to recover the input just from the output.
Just donât lie too creatively⌠I always mess things up whenever I try to be clever by using an alternate answer that I know I will remember because it is so obvious to me.
I was using one (like this) until a few weeks ago, when I finally succumbed and got an iPhone (albeit an old 4). Iâm not sure my previous phone was that dumb: it did have some kind of web browser, but I never used it since I didnât have a data plan. But it only had number keys.
And I bought that one because I dropped and broke an even dumber one, and it had already been discontinued.
But what happened to me exposes vital security flaws in several customer service systems, most notably Appleâs and Amazonâs. Apple tech support gave the hackers access to my iCloud account. Amazon tech support gave them the ability to see a piece of information â a partial credit card number â that Apple used to release information. In short, the very four digits that Amazon considers unimportant enough to display in the clear on the web are precisely the same ones that Apple considers secure enough to perform identity verification.
Funny what parts of a number are considered important... Needed my mortgage account number the other day. My bank's online service only gives the last four digits of the account - the last annual credit-check-report that I had run gave all the digits but the last four - so, between the two, I had what I needed...
I canât believe that Apple would accept just four digits of a CC# as an ID verification (perhaps they only had access to the same four numbers?).
Self salting isnât cometely crazy, especially if you salt with say âgoogleâ and the username/bday/whatever. The problem is that general purpose hashing like SHA are too quick. ASICs are affordable enough to brute force virtually any fast hashing algorithm.
Bcrypt solves part if the problem (slowing things down), but it is only a part of the solution. I could go on, but I have a suspicion you already know and agree with what Iâd say.
Check out Keepass2Android (Assuming youâre on Android and using KeePass.) It provides a quick unlock feature that allows you to unlock the password store with (by default) the last 3 characters of your password, and it also provides a custom keyboard that bypasses the clipboard and makes things both simpler and more secure. Thereâs also a plugin for KeePass called Readable Passphrase Generator which adds support for XKCD 936 style passwords. Add in KeeOTP and youâve got two-factor authentication covered (also supported in the Android app above.)
I make sure all my passwords are complete gibberish, and no two password recovery answers are the same. Since I donât know any of this info, I write it down as unencrypted plain text files in a directory called âdont_look_hereâ.
