Interestingly enough, this is one of the critical flaws in the old Enigma machine. Near-miss guesses at the key can produce plaintext that is close to the actual plaintext. Germany worked around this problem by making sure their messages were short enough that you couldn’t perform the lexical analysis needed to take advantage of this.
See also:
In addition to stealing the password hashes, the hackers often get the email addresses and other personally identifiable information. They could cross-reference this information with publicly available information as well as with what was spilled in other breaches to learn your kids’ names, your spouse’s name, your birthdate, answers to security questions, etc. Then they could use common patterns people use to make passwords and simply try them to see if one works.
For example, I’ve seen people use their pet’s name as a password (despite knowing better). Nowadays, users are told to include numbers in their passwords as well, so a lot of people just tack on their birth year because it’s easy to remember. It’s also easy for software to combine your pet’s name with your birth year in various ways to generate possible passwords to try.
Passwords like these would be low-hanging fruit for password crackers. Because the information associated with you can significantly reduce the search space, the overall length is largely irrelevant.
For an easily remembered phrase for older people are things from our childhood as the information is unlikely to be in any sort of database. As example growing up I lived on 3 different streets: Spring, Madison, and Gildersleeve in two different cities. Stringing them together with some characters could yield: Spring+Madison-Gildersleeve.
When instructing users about passwords, the first and most important and mandatory rule is every distinct login must have a distinct password.
Since this often results in many passwords, letting 1Password or a similar application remember most of those passwords is very helpful. If you do choose, for example, 1Password, It would be silly not to use long passwords created by the application just because you do not see the need today.
If you only ever use Safari, which is difficult for door openers and the like, then the recently introduced password creation and remembering is quite useful. The first rule still applies.
As an aside, I try not to use Adobe, Google, iCloud, Microsoft, or other “single login” authentication for external applications as these constitute credential sharing for multiple different targets. See the first rule above.
As long as you make it long…and don’t tell anybody where the numbers or words associated with you are in the pattern…then using something specific to you really doesn’t matter but it’s a hangover from earlier days I guess. I’m not a math expert but my guess is that knowing some numbers or words that might be associated with you the brute force algorithm could be changed to check those things earlier rather than start with your typical brute force attack that runs through all the possibilities of the 95 characters in most password sets (upper and lower case, digits, and special symbols)…and that might possibly reduce the entropy slightly which correlates to a slighter shorter time to crack.
However…that slightly ‘worse’ password is still plenty good if it’s long enough…which is why I said and security folks agree that length is the only thing that matters these days. Even if the bad guy had a quantum computer than was a million times faster than the massive cracking array number of 100 trillion guesses per second or whatever it is…that reduces the time to crack from whatever million trillion centuries to ten thousand million or whatever.
One other consideration might be a site that limits password length to 8 or 10 characters…in that case brute force with some smarts involved that cuts down the time by say a factor of 1,000 might result in a cracking time that isn’t unreasonable.
Single sign-on systems (assuming they’re not completely brain-dead) do not share your password with all the sites that use them.
They typically generate a unique key that they give to each site (effectively a per-site random password), and pass that key to the site when you log on via the SSO service. The SSO screen should be from the SSO provider’s server (either a separate window or an embedded frame) so the site you’re trying to access doesn’t see it.
It’s conceptually no different from using a password manager and is therefore as trustworthy as the company providing the service, just like any other password manager.
An earlier post talked about passwords for sites you don’t really care about…and suggested that using the same password for instagram or to log into a photography forum or whatever that has no financial or personal data in loved is an acceptable alternative. While I don’t do this…my spouse uses a variation on this theory of a ‘low security password for appropriate sites’ despite me trying many, many times to convince her to use unique ones. Everything important has a distinct password but there are sites that require login that just don’t really matter…and one learns to pick your battles…even with a spouse with a masters in business and a medical degree.
I used to do that. Until one of those sites suffered a data breach. I then realized that even without anything financially damaging on any of those sites, someone could use the credentials to impersonate me and post embarrassing things in my name. I don’t think anyone would bother, but I still don’t want to take the risk.
So I then went and changed the password on several dozen sites that were using that same password.
You are correct.
Single sign-on systems only require breaking one access which then allows access to all the sites that use that single sign-on for authentication.
Using Facebook for access control also guarantees loss of privacy.
A SSO provider almost certainly more secure than all the individual sites where one would otherwise be making passwords (or worse, re-using passwords). And while Glenn’s article recommended it, the discussions here haven’t really include two-factor authentication/verification (2FA); using 2FA on an account you use for SSO makes it especially hard for someone else to use your account.
It may depend on the SSO provider but I don’t know if there’s a way to get a list of the sites where you’re using the provider; if an attacker has gotten in to your SSO provider account, they may have to try using it on thousands of sites to find the ones where you’ve used it.
Even with a password manager, it is a bit of a hassle to have to create yet another account for a site. I tend to only use SSO for things like free tiers on Software-as-a-Service sites (e.g. a web app for editing photos), especially ones that I don’t expect to use much.
If someone won’t use a password manager, they’d be better off using SSO with a strong password whenever they can compared to reusing passwords or only varying passwords based on some mnemonic scheme.
to back track a bit … for those of us less savvy on the issues at hand
With regard to brute force attacks (?)
As it pertains to gaining entry into accounts … online,
I presume there are other non-password factors at play that add significantly to
security.
• Log in attempt count triggering freezing and account, (By the way, I think SSA and other gov agencies probably give you 3 to 5 attempts before freezing you out)
I would think a malicious character, with a whole dictionary of pet names, might still have a hard time
accessing a particular account … perhaps the odds of gaining entry to an account randomly has better odds
• two-factor authentication requiring second device
etc
No different from an on-line password manager, which can grant access to everything if your master password is broken.
As with all things, the security depends on how trustworthy the service provider is.
Yeah…I don’t subscribe to that theory myself and make all my passwords complex and put them in 1PW although I do use the words and symbols and numbers approach rather than completely random…but for some it’s an acceptable risk level was all I was saying.
1Password requires two keys to get access - your private key and your vault password. The private key is cached on my devices but that requires the device/account password. All these are very different.