Password length is by far the most important factor to brute force attacks. Which, I presume, is most people's concerns because if we're talking about weak hashes or plain-text storage, you're kind of fucked anyways. You can have your cake and eat it too.
Take, for example, some convoluted piece of shit password like `1Liek2Progr4m35423\!#@`. First off, most people won't remember that without using a password manager or copying it from your super-secret text file in your encrypted folder.
Sure, there will be a few people that chime in saying, "Hey, I can remember complicated, crazy passwords". Okay. Can you do it when the service forces you to rotate passwords, e.g. AD? Most users can't. Trust me. They can't.
So, what now?
Just make really long passwords. Instead of `fC29ap5w78r3IJ`, make it something you will remember. For example: `$omeb4s1ePr3fix I like to cheat on my wife with the secretary I hate her so much`. The entropy of the second password, due to its length, is much better than the former.
Now, if we're talking about services don't let you have an obscenely long password, that's... a service problem. While the implications are real, we're talking about "how to make really good passwords". I feel like this has been answered, but people are insistent on some arcane notion of using some complex string of characters -- as if the computer gives a fuck. Not everything is a straight dictionary attack, and the computer doesn't give a fuck if your password has words in it or not insofar as it's not just one or two words. It's not going to break a 42 character-long sentence that much faster because it has WORDS in it.
And, there's no way somebody should be able to be trying to guess your password that many times without getting locked out. Unless we're talking about somebody hacking into the server itself, dumping out the hashes, and trying to break it that way. Even in that worst-case scenario, assuming they have done their due diligence with salts/bcrypt/etc, a 42-character length password should take them somewhere in the vicinity of for fucking ever.
EDIT: The benefit comes from the prefix and the sentences. It pretty much deters both kinds of common algorithms even if you reuse the prefix.
There's only one downside. If you generate your password based on a phrase and add the service name to that, it could be easily guessed in other services.
If you use RedBananasFlyReallyHighAmazon for Amazon and RedBananasFlyReallyHighPayPal for PayPal (which, by the way, doesn't work, as PayPal for whatever reason blocks the word PayPal), one could guess the password from the other service, if one gets compromised.
Ultimately, you can only hope for the service to store the password hashed and salted, but in reality, that is not always the case or there's some novice programmer trying something out and all passwords are logged in plaintext somewhere else, while the database stores them hashed and salted.
But generally, I prefer this approach, as it provides a lengthy password, different for every service and easy to remember.
Well, in general, I'd suggest something related to the service rather than the service itself. Computer algorithms generally aren't intuitive in the same way computers are.
Paypal -> $pr3f1x29# elh oh el I liek money u gieve
Steve Gibson calls this concept the "password haystack". The idea is that the clever hacker will do something like the following:
1) Try known common passwords: "password1", "monkey", etc.
2) Try dictionary words, maybe with leetspeek substitutions, maybe with a single digit on the end
3) Try likely guesses based on what they know about you (if anything)
4) Brute force.
Assuming your password isn't dumb enough for 1-3, you just have to put your needle in a HUGE haystack. If your password is ":$have:$fun:$cracking$:THIS1", brute forcing your password requires trying every combination of upper and lower case, numbers and special characters up to 28 characters.
At one hundred trillion guesses per second, that would take "76.43 million trillion trillion centuries".
> we're talking about "how to make really good passwords". I feel like this has been answered
But that's not what we're talking about. As you say, that's been answered. But in the real world the answer doesn't work well, and whether or not it's a service problem it's a real problem.
You could implement your own dictionary (in ELvish!) if you wanted. But, I just make them up. You can re-use the prefix as it's only purpose is to screw up "whole word" algorithms.
NO. NO. NO.
Password length is by far the most important factor to brute force attacks. Which, I presume, is most people's concerns because if we're talking about weak hashes or plain-text storage, you're kind of fucked anyways. You can have your cake and eat it too.
Take, for example, some convoluted piece of shit password like `1Liek2Progr4m35423\!#@`. First off, most people won't remember that without using a password manager or copying it from your super-secret text file in your encrypted folder.
Sure, there will be a few people that chime in saying, "Hey, I can remember complicated, crazy passwords". Okay. Can you do it when the service forces you to rotate passwords, e.g. AD? Most users can't. Trust me. They can't.
So, what now?
Just make really long passwords. Instead of `fC29ap5w78r3IJ`, make it something you will remember. For example: `$omeb4s1ePr3fix I like to cheat on my wife with the secretary I hate her so much`. The entropy of the second password, due to its length, is much better than the former.
Now, if we're talking about services don't let you have an obscenely long password, that's... a service problem. While the implications are real, we're talking about "how to make really good passwords". I feel like this has been answered, but people are insistent on some arcane notion of using some complex string of characters -- as if the computer gives a fuck. Not everything is a straight dictionary attack, and the computer doesn't give a fuck if your password has words in it or not insofar as it's not just one or two words. It's not going to break a 42 character-long sentence that much faster because it has WORDS in it.
And, there's no way somebody should be able to be trying to guess your password that many times without getting locked out. Unless we're talking about somebody hacking into the server itself, dumping out the hashes, and trying to break it that way. Even in that worst-case scenario, assuming they have done their due diligence with salts/bcrypt/etc, a 42-character length password should take them somewhere in the vicinity of for fucking ever.
EDIT: The benefit comes from the prefix and the sentences. It pretty much deters both kinds of common algorithms even if you reuse the prefix.