That is irrelevant in the face of leaked passwords; what matters most in that situation is that your password is something other than your leaked one.
If the passwords were leaked due to being stored in plain-text, no amount of complexity would protect them, obviously.
Don't use the same password on multiple sites. If your LinkedIn password is leaked, you don't want that same password to grant access to your bank account. That just as important than how strong the password is, if not more.
If some site has suffered a password leak, and you're a user of that site, you must change the password on that site, and also on all other sites where you happened to use the same password. Do it as quickly as possible without worrying how strong the new passwords are. Then change later to stronger ones.
A password's strength is inversely proportional to how often you change it. For instance, if you happen to change a password every week (for the sake of argument---few people likely do), and it takes a month to crack on the best available hardware cluster, then you're probably okay. If you change only once a year, you're much less okay; a surreptitious password breach could happen, and two months of cracking later, the attackers have your password. Meanwhile, you're still months away from changing it, not knowing there had been a breach.
By the time users learn about a breach---if ever---they should assume that their passwords have been cracked, because some unknown amount of time has passed between the actual break and the discovery. The discovery will likely stem from the fact that some of the "lower hanging" passwords have been cracked and accounts start being misused. The site admins can then only guess from various circumstantial information (logs or whatever other breadcrumbs left bind) about when the leak might have occurred.
One assumes LinkedIn does not store plain text passwords anywhere. That would be against best practice for the average PhpBB online forum from the late 90s. It would be criminal negligence from a company like LinkedIn. How strong your password is (and which kind of hashing function the site uses) does influence how long it takes to obtain a plausible plain text password assuming that the exfiltrated data is in the form of a list of salted hashes, which is the most reasonable assumption.
That said, changing passwords everywhere remains the safest course. Since: a) 4 years is a long time to run a password cracker + dictionary, b) there is always the possibility that the passwords were intercepted on server memory before hashing.
Not to mention that someone might get the wrong idea and decide that encryption (or single-round hashing) is good enough.
crypt -- Trapdoor encryption
crypt, crypt_r - password and data encryption
crypt - string encoding function
The crypt() function performs password encryption ...
They have this result: VerticalScope Network (Vbulletin) (939 Websites). Would be nice to know all of those 939 sites.
The only thing one should ever assume with respect to _security_ is that the other party is going to do it wrong unless it's written out for them.
Your email account is the golden key to all other accounts that send "forgot password" links to it.
But what happened was embarrassment, not their life savings being wiped out.
a) There is a nonzero probability that your bank can be socially engineered using information obtained from compromising your email account and anything that trusts it.
b) An email account compromise implicitly means every service that resets/recovers through it has to be rekeyed. The subsequent cleaning of the stables can be messy, lengthy, and itself somewhat risky.
In particular, if you haven't already, enable MFA. If your email provider does not support MFA, change your provider.
This is 2016, we have password managers. Using different passwords for each site shouldn't be any more difficult than if you had not. Even using the built in ones in your browser of choice is better than not using one at all and makes using site specific passwords easy. Chrome even has a built in password generator for you, I assume this is using your operating systems CSPRNG (or BoringSSL's?) although I'm not 100% sure about that.
Keep in mind that these estimates are based on some bogus entropy estimation. If a password hacking guy runs the correct dictionary past the hashes you password generates, it might be as small, well, as the first one tried. For example, run the passphrase Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn1 past the kaspersky bruteforce estimator, you get 10,000 centuries. But this is clearly false, as inicated in http://arstechnica.com/security/2013/08/thereisnofatebutwhat.... They clearly "cracked" this in far less time: "in a matter of minutes".
We were changing domains at the same time, so my new password root is now based on the first three characters of the first 3 lines of the thing, which included some punctuation, then the standard numeral to increment every 90 days.
My password was in plain sight for a couple months before I got around to binning it, which actually makes life a lot easier. Especially when you're not using it often enough for it to be muscle memory - which is the problem my parents face.
As stated by zamalek, the trick to not memorizing many passwords is to use a password manager.
However, most users will not bother, and getting them to use at least decent passwords would be a great step forward. Additionally, you still need a master password for your password manager.
There is a certain degree of trust that non-technical users are asked to do that should leave us with at least a mild level of discomfort.
The same applies verbatim for people trying to roll their own 'clever' encryption schemes.
Sample passwords, not your actual passwords.
If you follow that link, they reinforce that with: "Never enter your real password".
Imagine a relative of yours who is much less computer savvy than you are. What are the chances that the actually enter their real password?
And what value is this check, actually, on a fake password. "Your fake password will take xxx centuries to crack". So how does the non-tech savvy person, who might have a struggle coming up with a real, useful password, then enter one that is similar but not exact and expect a measured response?
So even if they collect "simulated" passwords, password cracking is less about entropy and more about generating dictionaries based on patterns that users are likely to use.
There isn't any value in such a site, and I claim it is less than useful.
Of course there are other ways that a password can be cracked, for example an attacker who breaks into the server can capture it as it is submitted. So it's still worth having a different password for each site.
To put this into perspective:
If you turned every grain of sand on Earth (about eight quintillion) into a computer able to test 1 trillion passwords per second, you'd need about 360 million years to exhaust half the search space and have better than even odds of guessing it.
I use and recommend 1Password. To evaluate a password manager, check this page https://discussions.agilebits.com/discussion/15416/1password... for good questions to ask. For example, what data they can turn over, what their encryption practices are. Key phrase: "There is no data of yours that we keep, so there is nothing to turnover".
This can't be said by all password managers.
I didn't notice an increase in their price--I have one at home and one from work.
Your alphabet, lowercase + uppercase + digits + symbols, has 72 characters. There are 72 ways to pick the first character of your password, 72 ways to pick the second, etc. So there are 72 to the 25th power possible passwords, about 7.5 times 10 to the 46th (about 7 followed by 46 zeroes).
That's fewer possibilities than the number of atoms in the universe and fewer possibilities than the ways you can order a deck of cards, but if a computer can calculate one hash per nanosecond, it'd take about ... well, more millennia than I know the words for. Even if we're talking about a cluster of GPU machines, it's effectively forever. Unless you had some infinite improbability drive (like a quantum computer?) and you guess correctly on the first try.
So what did you use to generate the random password? Did you use your favorite programming language's pseudo-random number generator? Remember, "anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin" (John von Neumann). A bad random number generator might only have 2^32 possibilities.
Let's put that aside. It's unlikely that the hacker knows which random number generator you used. It's much more likely that the company storing your passwords is not storing them securely. Passwords should not be stored, ever. Instead, the company should store a hashcode. The hashing algorithm should be like the butterfly effect -- a tiny change in the password produces an unpredictable difference in the hashcode. Unfortunately, many older hashing algorithms, like MD5, are predictable. A hacker can find an MD5 collision -- not your password, but one that hashes to the same hashcode -- within minutes.
There's more to it, but my advice is NEVER rely on password security by itself. If you care about your security, then use 2-factor authentication or physical security in combination with password protection.
Edit: Am I incorrect? I see there was a downvote. Please educate me.
I even bought a set of casino dice.
pwgen -y 40 1
Generates one password with 40 chars, including special chars (-y).
head -c 24 /dev/urandom | base64
The "PRNG" vs "Real RNG" boogeyman scare is such a load of horseshit.
The whole point of modern PRNGs is that they're good enough computers can't detect patterns. I assure you that you're gaining zero security by using random.org vs openssl rand... and in fact, you're losing massive amounts of security because it's going over the network.
You're right that using an internet service like that to generate passwords is insane, and there is no need for some fancy custom RNG hardware just to generate some keys/passwords.
I wonder if that's actually a risk? At least for people not being individually targeted?
A random Elbonian hacker who gets a dump of 117 million password hashes has (at least) three approaches she can take to make use of it - she can run oclHashcat or JtR using a good wordlist (say, Hashkiller or phpbb) and a reasonable ruleset to tweak them, which'll fairly quickly reveal common, reused, or guessable passwords in hours/days/weeks - or she can set it to enumerate through an entire $howeverymany bit password space, which is guaranteed to find all the passwords but not before the heat death of the universe... Or she could try only the selections out of that random keyspace that a flawed version of FooPasswordSafe is capable of generating. I'm not sure how long the last approach would take, but it'd have to be both a pretty flawed PRNG and a very widely used password safe for it to come anywhere near as useful as approach 1.
(If she's only cracking the hash for the firstname.lastname@example.org record, things are somewhat different to if she's just trying to find _any_ "useable" passwords out of 117 million... And if she _knows_ sbeirwagen uses DudPasswordSafe.exe, it's likely she knows better ways of attempting to acquire your password than hoping to crack it from publicly released credential dumps...)
Why can't people just be nice.
>It would have been impossible to use a brute-force attack or even a combined dictionary to crack a phrase of that length. But because the phrase was contained in this Wikipedia article, it wound up in a word list that allowed Chrysannthou to crack the phrase in a matter of minutes.
The attack described is to find potential passwords on the web or somewhere, compute the hash, see if it matches. Rainbow tables aren't any part of this process.
If he took the word list to run login attempts against a server (or a local endpoint checking the leaked database) it's more of a dictionary attack.
Same result, different ways to get there. If you're able to run your cracker locally against a leaked db, it probably doesn't really matter.
However, from the point of view of someone implementing an authentication system, passwords on their own are broken. There will be a significant fraction of users who re-use their password at a site with minimal-effort security. If you subscribe to the idea that computer professionals have a moral duty to safeguard people's private information entrusted to them, then password-only authentication is just broken.
The solution is to either: spend the money to implement a multiple factor authentication system (with a secure password database and fraud detection) or use a federated identity service. (Even just sending a one-time login code via email is fine). The latter is simple and takes even less effort than implementing a password system from scratch.
There should be fines (at the very least) for having an unsalted password database with more than X number of users.
In a "lost password" mail, of course, that's another thing.
(I'm not being technically correct here, but I'm being practical, and my argument here applies to 99.9999% of all cases)
Of course if you're talking about just a normal plain text static password, then it's obviously wrong to see it in an email.
 "Simple Authentication for the Web" (2007)
Of course, a truly healthy system also wouldn't allow email-only resets, but that's life.
https://haveibeenpwned.com/PwnedWebsites hasn't been updated yet with this yet because the list hasn't leaked entirely.
Also change your password: https://www.linkedin.com/psettings/change-password
Linkedin should probably be the one warning me about this, but I never heard of this before.
Edit: filtered as Spam, nevertheless they should have locked my account.
isUseful :: LinkedInMessage -> Bool
isUseful _ = False
This all happened about 20 minutes ago.
Is it possible for me to check the data link to look my name up.
I'm in the list :( I can't remember what password I was using in 2012, but I changed my password again anyway. At least it was never the password associated with my Gmail login, cause I'm not a derp so I don't use that anywhere but Gmail.
Why don't they invalidate the passwords all at once instead of letting -- someone -- use the potentially compromised passwords again...
"We've recently noticed a potential risk to your LinkedIn account coming from outside LinkedIn."
That's almost as bad as saying "we take security very seriously" after a hack!
How can a risk come from "outside" LinkedIn related to my password? If I haven't leaked my own password, then there should be nothing to fear, and my account should be secure.
Unless of course LINKEDIN ITSELF is compromised, and leaked my password. In that case, the wording about "coming form outside LinkedIn" just smells like BS/spin to me.
They invalidated my password.
My session was intact, but a password reset was required on next login, and they encourage two factor. I did that despite not really wanting linkedin having my phone number...
When you change the password, you can click a box to inactivate all other sessions.
"We've recently noticed a potential risk to your LinkedIn account coming from outside LinkedIn. Just to be safe, you'll need to reset your password the next time you log in."
Why -s? Because it means each password is a complete word, and may easily be double-clicked in a password list (which is nice, because selection is copy in X).
Why 22 characters? Because 22 mixed-case letters and digits are just over 128 bits of entropy.
Say it with me:
pwgen -s 22
Writing them down would probably be even better.
apg -a 0 -n 1 -m 14 -x 14 -M NCL
-n umber of passwords to generate
-m inimum and ma -x imum length
-M specifies what types of characters to use. N = Numbers C = Capital letters L = Lowercase letters. You can also add S for punctuation.
14 chars with numbers letters and caps gets you ~80 bits of entropy, which is the NIST recommended value for passwords.
I store them in 1Password. (Whose password generator I don't like, but is still infinitely better than picking your own passwords in your head.)
I mean, try typing this on your PC or mobile phone: &}n9$r}@pe^q;j2U33Aq8.kTa}Z2^ykQ
And compare it with this one:
And yes, their client saves you somewhat, except that there are plenty of instances in which you resort to copy/pasting passwords. Like on Android where the integration is poor. And on the desktop as well. And guess what, copy/paste is really, really insecure, because apps can be made to listen to clipboard events, so you can have apps that are logging whatever you copy/paste. Oh, and Linux doesn't have 1Password, their old Windows client is getting replaced with a "modern Windows" app, so tough luck.
Creating your own passwords and typing or copy/pasting them in is a broken authentication experience.
This is an area that will get much more attention in coming years as technology finds better ways to authenticate us instead of using secret codes we have to remember.
I've used some sites which had a login cookie, and if you lost it, you just put your email address in and they'd send you a new link, no password needed; much nicer for many things.
People raises eyebrows when they get phishing emails but when it comes purposely from LinkedIn and vouched for by your social and professional circle it could get much more credible and easy to fall.
Logic tells me I've got nothing to worry about, even considering potential password reuse, if they've all changed since then.
"Add an extra layer of security to your account. Add your phone number."
Leaking my email / password is bad enough; I'm not going to give them my phone number for more damages!
(The attack is not very scalable, but easy enough to pull off against individual targets.)
You'd think they would want to advertise 2FA better...
Any time you travel internationally? My phone only has one SIM slot and it's not going to be the $10/MB roaming one from back home.
SMS 2FA is an awful trend.
"The lobby group for Australian telcos has declared that SMS technology should no longer be considered a safe means of verifying the identity of an individual during a banking transaction."
"SMS is not designed to be a secure communications channel and should not be used by banks for electronic funds transfer authentication,"
It makes e.g. Twitter's insistence on SMS 2FA annoying (since their "we've sent you login request to your app" just doesn't work for me, I'm stuck with SMS).
Google Authenticator is great, and I use it anywhere I can. I also take a physical backup of the seeds in a secure (and secret) location, in case I lose my device.
Something needs to change here.
Edit: SHA-1... You'd think a site as big as linkedin would have strong hashing...
"What's also troubling security researchers is that the password database contains entirely unique passwords. It's unclear whether the people who leaked the password file have more passwords that have not surfaced online. The file may, for example, be an attempt to crowd source the hacking of some of the more difficult passwords."
Well Per Thorsheim called that one!
"Motherboard conversed with someone at LeakedSource who claimed that they managed to crack 90 percent of the LinkedIn passwords within three days. Though LinkedIn says it has hashed and salted its stored passwords for several years now"
"There are no experts, only various levels of incompetence" ;)
They didn't move fast enough to get accounts moved over.
This would also explain linkedins initial "confusion" regarding the hack.
I know custhelp used to be particularly insecure right around when this hack happened, as I myself discovered several vulnerabilities back then.
>Also, when you say '"confusion"', do you mean it was feigned?
Partly. From what I recall it took them quite a while to own up to this very easily verifiable hack, which could very well have been because they couldn't figure out why it happened because it didn't actually happen on their systems.
In fact, the hack coincides perfectly with that php-cgi bug being released. Coincidence?
Do NOT do that with your exact password though :)
I'm impressed by the password cracking estimation with the Tianhe-2 Supercomputer. A 10-character password containing uppercase letters, lowercase letters, and numbers, which is estimated at a 4 year crack with a Macbook Pro, takes 31 seconds on the supercomputer.
computers speed factor
ZX Spectrum k: 1300 // 30 guesses per hour (?)
Mac Book Pro (2012) k: 1 // 10 guesses per second (?)
Conficker botnet k: 5e-5 // 20000 guesses per second (?)
Tianhe-2 Supercomputer, k: 3e-7 // 3000000 guesses per second (?)
Passwrdr.crack_time = result['crack_times_seconds']['online_no_throttling_10_per_second'];
Is even the basic ratio/multiplier correct? Supercomputer is 1,000,000x faster than a 2012 MacBook Pro? I tried a few random strings and saw ratios as high as 3,000,000 - why would the ratio change based on the password? Probably because the number is nonsense.
Probably because they may assume a dictionary order of cracking attempts?
More realistically though, Kaspersky just really sucks at password cracking.
Mine easily hits 80Ghash/s on MD5 and around 25Ghash/s on SHA1, a more dedicated setup could easily do 10x that.
$ pip install diceware
$ diceware -n 8 -d ' ' --no-caps
proton hunts blake 31 pope pivot taped plain
I'm assuming (and I may be completely wrong) that some kind of software monitors if the database of customer details is being downloaded. If a download is detected, an alert is issued. Does software like this exist? Or there other measure that guard against these data breaches?
There is some software that can detect an anomaly in the regular pattern of network usage, and possibly even cut the connection, but again, I'm not sure how effective they would be here.
In any case, considering they were using unsalted SHA-1 hashes of the passwords, which was well known to be a poor practice, you should probably assume they had very little protections.
b) There is software (intrusion detection systems/software, or IDS) that does that, but it is rarely present by default. The hows and whys of IDS can be difficult for non-security types to grok, and it can be costly in terms of time, equipment, and money, so it often not encountered.
Yes, I know - don't reuse and use a password manager. But not everyone follows best practice. Knowing which password motifs to absolutely not reuse would be helpful.
If an attacker has sufficient access to read out passwords from RAM, it also has sufficient access to just keylog everything.
To follow your analogy: if somebody physically breaks into your home and places a security camera pointed at your safe(s), it's not really going to matter for the average user whether all the safe combinations are on a single piece of paper.
They're going to get them anyway, because they've compromised the environment and can just watch the footage.
Most attempts will favour "all and now", above "slowly over time".
Back then there were issues. If I remember correctly, there was some nodejs even after this with no bcrypt.
so if some hacker somehow manages to backward engineer a salted-bcrypted-hash of my unique password, he still cant get in without my cell phone
And you just lost my trust Kaspersky, congratulations.