1

I'm writing up advice for selecting a master password for a password manager, and I'm wondering if there is available data about the likelihood of different attacks that result in a cracked password. I'm interested in data relevant to what a user is able to control with the password itself (so, something like phishing isn't on my radar as much since the vulnerability is the user rather than the string of characters themselves).

So, for a secure password, I'm thinking I'll recommend, in descending order of importance:

  • length (brute force)
  • uniqueness (reverse brute force, matching username/password of hacked Site A to secure Site B)
  • impersonality (guessing based on knowable personal details)
  • ease of memorization (indirectly relevant; the first three make a password hard to remember, so you have to decide if you're gonna sacrifice those to remember better or if you're gonna write it down and risk the paper getting stolen)

I have length at the top because 1) research generally cites it as the best and easiest way to make a password safer and 2) in my experience, attacks seems to be en masse/random more than they are targeted for an average end user.

I know there are a ton of caveats; the threat model for a high-level politician's email is different than a teenager's Facebook. Maybe you trust your safe more than your memory. But is there relevant data that answers this question on a high level?

EDIT to rephrase the question:

If I must make a tradeoff in my password strength somewhere (as in, in order to make my password easier to remember, I will either make it shorter or use my birthdate instead of random numbers), which attack should be treated as more likely for the average user of a mainstream web application?

  • Looks like you are asking two questions: how to create a secure password (and for this you need "entropy", that is, is must be random and look random enough). Then you are asking how passwords are usually guessed in attacks. I'd like to see some statistics on this too. My personal opinion is that the usual vectors are: very weak passwords (like "12345"), or insecure ways of resetting passwords (secret questions like "what's your favorite color"), or database leaks (hashes that will then be bruteforced offline). – reed Oct 8 '18 at 23:10
  • @reed I think I have a good handle on how to create a secure password, but I think that, if I must make a tradeoff somewhere (as in, I could make it shorter to remember it better, or I could use my graduation date instead of random numbers to remember it better), which attack should be treated as more plausible? – Brendan Oct 8 '18 at 23:58
  • 1
    It depends on who your attacker is. If your attacker has an intimate knowledge of you, then don't use personal info even if it's easier. If the attacker is randomly attacking everyone then it's probably fine. There is NO best password policy. It depends on your threat model, and what your users are willing to put up with before they start writing stuff down on sticky notes. Also, this question must have been asked before. Did you search for similar questions? – Daisetsu Oct 9 '18 at 0:29
1

I think the question in the title is better answered as: neither. The attacks against mainstream web applications are in my experience automated against flaws in the web applications and not on the passwords themselves. My company experiences attacks daily for Wordpress, Joomla, and other CMS systems. They are exploiting flaws (mostly SQL injection) to gain access to the entire system.

Attacks against users, I have no data on.

Targeted attacks against users fall into two categories: attacks against all users; and attacks against a specific user.

It makes sense that attacks against all users would as @reed mentioned, would be against the weak passwords or offline hash cracking.

In the case of targeted user attacks, the attacker would be targeting insecure password resets like in the Sarah Palin Yahoo Email hack or using metadata on the user to figure out what is likely for their password.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.