A question about password security

[Khedrac]

My brother asked me this one and I was somewhat surprised when I realised that I had no idea of the answer...

Why as strong passwords considered necessary these days?

Some context:
In the early days of computers passwords were usually stored in their encrypted form in a ublically accessible file. This meant that to do a "dictionary attack" one simply fed each word in the dictionary inot the password algorithm and then compared it to all of the encrypted passwords in the file. If it matched you had cracked a password and could look up which user it was.
These days password files are usually hidden so users cannot see them which rules that style of attack out.
Brute force attacks are when one tries thouands of passwords until one finds one that works, but these need to be formatted as login attempts - so username + password.
Modern systems usually enforce the automatica locking of accounts after too many wrong passwords - either for a given period of time (e.g. 20 minutes) or until a reset is performed - and this prevents brute force attacks.
So, given that one cannot try loads of incorrect logins to an account in the hope of finding a valid password, and seeing as one cannot check loads of possible passwords against the encrypted list of passwords, why do passwords need to be strong? Particularly website passwords.

The only thing I can think of as a possibility is that since the website has to send the password encrypted (so that the password cannot be intercepted in clear) hackers can get the encrypted password, which re-opens the door to dictionary attacks, just against the single password rather than the whole file of passwords. The fact that the web page has to encrypt the password on the host machine also means that the encryption algorithm has to be available on th web page and hterefore is accessible to hackers.
Am I close?

[Keltest]

In part at least, the intent is to get people to generate different passwords. People will have a tendency to use one or two medium strength passwords for most websites they need an account to use, and if one of those random small ones gets hacked and the password-email combos get leaked or stolen, then they may be able to go from, say, your random small time game mod website account to your Steam account, or god forbid even your bank account. By having a requirement of a password with XYZ different symbols and combinations and such, and with different websites having different strengths, it means you at least cant just literally copy paste it and might actually add a little personalization to each site.

[crayzz]

Under normal operations, there's people who work on the server you're accessing, who do have access to the list of hashed passwords, and who could try a dictionary attack. This maybe doesn't matter much for your GitP password but it matters a lot for your banking information.

The list of hashed passwords also gets leaked like, all the time (see HaveIBeenPwned; checking my usual email address, the hash of my password to Chegg was leaked in 2018). In the best case scenario you'll be notified immediately, but realistically you don't even know it happened, and if you do you probably didn't find out until weeks after, giving hackers plenty of time to break a lot of passwords and get access to your account. Dictionary attacks are also very effective, there's a text file called rockyou.txt you can download; it's (currently, I believe it's being updated yearly) ~130 megabytes of plaintext passwords people actually have used. Using that as your dictionary can break most un-secure, and even a lot of nominally secure passwords, pretty quickly.

This all becomes much, much worse if you're reusing passwords, or even variations of passwords, since once they have your password tied to your email address/username they can try that combination on any online service they can think of, so suddenly your GitP password getting hacked does actually threaten your bank account.

All of the above are the basic reasons why it's generally recommended to 1) use 2FA and 2) use a password manager if at all possible.

The only thing I can think of as a possibility is that since the website has to send the password encrypted (so that the password cannot be intercepted in clear) hackers can get the encrypted password, which re-opens the door to dictionary attacks, just against the single password rather than the whole file of passwords.

Websites generally do not do this for the exact reason you describe: it opens them up to brute force attacks without needing any kind of special access to the server. If you find out a website is sending out hashed passwords to users trying to connect, definitely change your password for that site and stop using it.

[Rynjin]

The point of security is not to make something impenetrable, it's to make something more of a pain than it's worth.

Making a strong password is the bare minimum a user can do to contribute to their own account security.

Activating Two-Factor Authentication is even better because in the event your password is cracked (and it will be), it's more of an annoyance than anything else.

[Radar]

In part at least, the intent is to get people to generate different passwords. People will have a tendency to use one or two medium strength passwords for most websites they need an account to use, and if one of those random small ones gets hacked and the password-email combos get leaked or stolen, then they may be able to go from, say, your random small time game mod website account to your Steam account, or god forbid even your bank account. By having a requirement of a password with XYZ different symbols and combinations and such, and with different websites having different strengths, it means you at least cant just literally copy paste it and might actually add a little personalization to each site.

The thing is though, that requirement to use special characters and so on typically will make people even more inclined to use a single password for everything as complicated passwords are more difficult to remember.

XKCD had an interesting comment on this. Basically, requiring longer passwords even without special symbols could lead to better security and they could be much easier to remember. For sensitive stuff though, 2FA all the way.

[Grey_Wolf_c]

Basically, requiring longer passwords even without special symbols could lead to better security and they could be much easier to remember. For sensitive stuff though, 2FA all the way.

There is no need to chose between those. The current gold standard for security is both "multi word" passwords AND some form of two factor authentication (such as, but not limited to, sending you a one-time use text code when logging in).

Re: OP, you are missing one crucial vector of attack: chance of password duplication. If you don't use a scrambled set of letters, instead using a simpler password, even one that might not be in any dictionary, if that password is non-unique (i.e. someone else also decided to use it as their password), then if the encrypted list of passwords ever is leaked (like they said above, a fairly common occurrence) then the hackers know that figuring out that password is a twofer: one cracked password gives them access to two accounts, immediately making it a more tasty objective (obviously, if it is just two it will still not be as interesting as "password" and "12345", but you get the idea). Because they have the encrypted result, the defence of stopping logging attempts after 3 doesn't even work: they just set up their on login system in their own server, and just dictionary/common password list/brute-force it until the output matches the encrypted passwords in the list.

This, btw, remains a concern even with multi-word passwords. Yes, the fact that you are using multiple words makes it less likely it'll be the same words as someone else... but let's be honest, most people won't pick four completely random words, just like we don't pick completely random letters. We need to remember the damn thing, so some semblance of meaning will be there. Or, in many cases, much semblance. I'd imagine, for example, that often the random words will be lyrics (and I shudder to think how often it will be "correct horse battery staple").

Now, there is a technique to counter the danger of different users with the same password called salting (that I won't explain) that needs to be implemented server-side but, like 2FA, is nowhere near commonly enough used. So until it is, if it ever is, you really want to use a password that minimizes the chances someone else also has it. If the service allows you to make a password 50 characters long, then go for multiple words. But if it limits you to 16, then random letters is second best.

Grey Wolf

[Jimorian]

Highly recommend the series of videos by Computerphile on the subject of passwords and internet security in general. I think he even mentions the XKCD method in one of them.



Quick shortcut to finding most of the rest: https://www.youtube.com/results?sear...phile+password

[Chronos]

Security that works when everything works right is no security at all. Yeah, the encrypted password file is supposed to be hidden from users. Supposed to be. Leaks happen.

And yeah, length is the most important thing about passwords. If you take two passwords, and one is drawn randomly from the set of all possible characters a standard keyboard can produce, and the other one is drawn randomly from nothing but digits, but the second password is twice as long as the first, the second one is more secure.

Actually, let me amend that: Length is the second most important thing. The most important thing is randomness, which a lot of people seem completely incapable of grasping. They'll say things like "I create random passwords by drawing a square on the keyboard", or "I use the XKCD method, but choose words that make a sentence, so they're easier to remember". Those aren't random, and attackers know that people do things like that, so that's on the list of what they'll try.

You want to know how I created my bank password? I'll tell you exactly how I did it. I rolled two six-sided dice to generate a number from 1 to 36, mapped to the alphabet and the 10 digits, and then I flipped a coin to either press or not press Shift. Then I repeated that as many times as the maximum length the password would allow. Even with telling you my exact method for generating that password, you're never going to be able to crack that.

[Khedrac]

Thank-you to everyone who has replied to this question.

A few points - I do use a password vault and what I hope are pretty strong passwords for those that cannot be in the vault (i.e. passwords for work). I also get irritated by websites that don't tell you the maximum password length is 15 when I try and enter a 29-charaacter pasword but just report an error somewhere.

However, if the main point behind long complex paswords is because password files do get hacked at which point you need something that is hard to brute-force (as well as unique - that's a given), how safe are password vaults? What happens when they are the site that gets hacked?

[veti]

XKCD had an interesting comment on this. Basically, requiring longer passwords even without special symbols could lead to better security and they could be much easier to remember. For sensitive stuff though, 2FA all the way.

There's a problem with the XKCD method: it doesn't scale. That is to say, it's fine as long as only a handful of people use it, but if lots of people do it, it becomes no better than dictionary words.

Most English speakers have something between 2000 and 5000 words in their active vocabulary, i.e. the words that will come easily to them. If you choose 4 of these at random, that's a dictionary of (5000^4 =) 6.25e14 possible passwords. Compare that with characters chosen at random from the approximately 100 that can be typed on a standard (US) keyboard, and it's easier to guess than a mere 8 characters.

The reason it might work now is because it's such a small user set that it's probably not worth the dictionary attacker's time. But if everyone starts using it, that would quickly change.

I use passwordsgenerator.net

[Keltest]

There's a problem with the XKCD method: it doesn't scale. That is to say, it's fine as long as only a handful of people use it, but if lots of people do it, it becomes no better than dictionary words.

Most English speakers have something between 2000 and 5000 words in their active vocabulary, i.e. the words that will come easily to them. If you choose 4 of these at random, that's a dictionary of (5000^4 =) 6.25e14 possible passwords. Compare that with characters chosen at random from the approximately 100 that can be typed on a standard (US) keyboard, and it's easier to guess than a mere 8 characters.

The reason it might work now is because it's such a small user set that it's probably not worth the dictionary attacker's time. But if everyone starts using it, that would quickly change.

I use passwordsgenerator.net

I mean thats a fair argument, but it kind of misses the point of having a password in the first place in that somebody needs to have legitimate access to the account, and many people cant memorize a randomly generated string of letters, numbers and symbols. The weakest point of any door is always going to be the keyhole, and no matter what you do, you wont be able to protect against somebody who stole your key. Password strength isnt intended to protect against that.

[Bohandas]

Most English speakers have something between 2000 and 5000 words in their active vocabulary, i.e. the words that will come easily to them. If you choose 4 of these at random, that's a dictionary of (5000^4 =) 6.25e14 possible passwords. Compare that with characters chosen at random from the approximately 100 that can be typed on a standard (US) keyboard, and it's easier to guess than a mere 8 characters.

The problem is that that's dependent on choosing characters at random; which I would wager is very rare. Who would deliberately choose a password that's impossible to memorize for a day to day application, rather than just changing the letter "l" to a "1" or something in the password they were going to use anyway

You want to know how I created my bank password? I'll tell you exactly how I did it. I rolled two six-sided dice to generate a number from 1 to 36, mapped to the alphabet and the 10 digits, and then I flipped a coin to either press or not press Shift. Then I repeated that as many times as the maximum length the password would allow. Even with telling you my exact method for generating that password, you're never going to be able to crack that.

But then what do you do if you need to access your bank account?

Also, I can tell you that your password doesn't contain the characters g k m q s w 2 or 4, as you're clearly multiplying the two dice together to generate those numbers and those characters occupy prime number positions that are higher than six

EDIT:
Or the missing numerals might be 3 and 5 if you put the zero at the end to stand for ten rather than at the beginning to stand for itself

[veti]

Also, I can tell you that your password doesn't contain the characters g k m q s w 2 or 4, as you're clearly multiplying the two dice together to generate those numbers and those characters occupy prime number positions that are higher than six.

Umm... If I were using 2d6 like that, I would calculate the total as (1d6 - 1)*6 + 1d6, which gives a full and even coverage.

As for choosing characters at random, there are utilities for that. And memorising the resultant string isn't that hard. Write it down at first, and when you've typed it a few times you'll be able to tuck the paper version away somewhere safe. (Mind you, it's a lot easier with shorter passwords. 12 characters take way longer to memorise than 8.)

[Misereor]

Modern systems usually enforce the automatica locking of accounts after too many wrong passwords - either for a given period of time (e.g. 20 minutes) or until a reset is performed - and this prevents brute force attacks.

<snip>
Am I close?

Somewhat, but not quite.
The thing is that most systems have a reset timer for the "3 failed passwords" function for user convenience. Therefore, if someone runs a script that attempts to log in only every 5-10 minutes, it can run for months without getting discovered. Such scripts will commonly also use VPN providers to jump between IP adresses to lessen the likelyhood of basic Intrusion Prevention Systems detecting them. Thus short passwords that never expire greatly heighten the chance of getting your users compromised. Also, web-mail portals are a popular target, because they are publically visible for everyone unless a mail relay service is used. Furthermore many, if not most, organizations tend to match their User Pincipal Names with e-mail adresses, thus removing half the complexity of the username/password combination guesswork.

Current NIST practice for end users is to use long, semi-random pass phrases without complexity requirements, which are never changed unless there is suspicion of malicious activity.
This is partially a technical thing and very much an end-user psychology thing. After many years of insisting on various complexity requirements, they finally realized that too much complexity only leads to people finding workarounds like sticky-notes or changing a single character when resetting their passwords, and that this actually generates greater risk than what is achieved by complexity requirements. Also, when people use upper and lower case letters, special characters, etc., they tend to be so predictable that it doesn't really add much security (please slap yourself if your password has a single upper case letter as the first character and adds an exclamation mark at the end).
On the tech side salting (adding random characters) is recommended, but is not a standard industry feature yet.

A modern pass phrase might be something like: "Yes, they deserved to die, and I hope they burn in Hell!"
(Commas and capital letters only recommended for sticklers for spelling and punctuation. More exclamation marks may also be added for the genuine Samuel L. Jackson experience!!)

[kyoryu]

I think that ultimately when talking about security you have to talk about what vulnerabilities you're defending against.

Getting someone's password by repeated attempts at a web page is ludicrously unlikely as an attack vector - for even the simplest password schema (one common word), that's 5000 attempts max. If you assume 3 tries per 20 minutes, that's 9 per hour, or about 200 per day. That's still the better part of a month - unless you're a significant official, nobody really cares about you in particular enough to do that. Any reasonable strategy (xkcd passwords, passphrases, random line noise, even obfuscated dictionary words) is going to increase that amount to a ridiculous length.

If someone wants your account info, they are probably going to engage in social engineering of some sort, including phishing. The most likely way to get someone's password is to get them to give it to you in one way or another. Either they'll pose as someone else, try to get you to click on a link and ask for your password, or even check the garbage near your work to see if they can find sticky notes with passwords.

NEVER EVER EVER GIVE ANYONE YOUR PASSWORD. THERE IS NO VALID REASON FOR ANYONE TO HAVE YOUR PASSWORD.
THE ONLY POSSIBLE EXCEPTION IS IF YOU KNOW THEM PERSONALLY, THERE IS NO BUSINESS CASE FOR IT, EVER. ALWAYS BE CAREFUL OF LINKS YOU CLICK ON THAT THEN ASK FOR A PASSWORD. ALWAYS ALWAYS ALWAYS.

So let's talk entropy. xkcd passwords and 8 random keyboard characters are both good. Longer strings are of course better. The 8 random character solution has about 20x the possibilities of the xkcd passwords, so it's better, but not HUGELY.

Realistically, what will happen is someone will get a hold of a password dump from a compromised site, which will include logins and encrypted passwords, and hopefully salt values.

What they will then do is generate hashes for all sorts of random things until they get a match. Once they get a match, they now have two things:

Salting is just the process of adding a short string to the end of your password to further vary the resulting hash - so if your password is "password", a site might add "abcd" to the end, and compute the hash of "passwordabcd". Other users would get different salt, so another user with "password" might have the salt "efgh", making their hash the one for "passwordefgh". Since a single, unsalted breach could result in a large data set that can result in known password->hash values, that can make other compromised sites very vulnerable. The salt basically means that each unique use of that password (site/user combination) will end up with a different hash value, unless they end up with the same salt, which is highly unlikely.

So, if the site uses unsalted hashes, what the hacker will do is:

1) compare the compromised hashes with a list of known password->hash combinations. This will take seconds.
2) Run random inputs into the hash function and look for matches against the password list. This can take a long time, but given common schemas, you can get a lot of hits fairly quickly. "Capitalize the first letter and add an exclamation mark" is so common that it really isn't any better than a blank password. The key here is they don't have to target you in particular, they can run against the entire list and just look for matches.

If the site uses salted hashes, it's a lot harder. Basically, the same brute force method occurs, but since even a single password will give different results if combined with a different salt. So now they have to do that entire search space for every user. You being targeted is extremely unlikely.

So, if they do get a match? They have your name and password, or at least a password that generates the same hash (which is effectively the same thing from the system's POV). If it's an unsalted site, they also have a hash for that password that will match on any other unsalted site.

So commonality of schemas only matters if the site isn't salted. Any significant site will have salted passwords.

All of that leads to the following recommendations:

1. Use 2FA. That is the single most effective way to not get hacked. Period. Use it everywhere.

2. Use a password manager, to make it so that you can easily have unique passwords per site/account without having to memorize them. DO NOT USE YOUR PASSWORD MANAGER PASSWORD ANYWHERE ELSE EVER. Password managers typically use godawful random strings of large lengths that are unlikely to show up on any lists, be expensive to find, and in the salted case, they have to target you as well anyway.

3. If you can't use a password manager or refuse to, use a password schema of sufficient complexity. 8+ random characters works. 4+ random dictionary words works. Pass phrases are questionable. Length is king. One of the keys in choosing a schema is how easy it will be to remember. You do not want to write it down (see social engineering and dumpster diving). Dictionary words with minor modifications are barely better than basic dictionary words.

4. If you absolutely can't use a password manager, and can't remember all of the passwords for various things, then I'd recommend a three-ring solution to password reuse.

First ring: Your email. This password is absolutely unique and is the key to anything else, provided you trust your provider. And if you don't, get a different provider.
Second (and possibly third) ring: Trusted, professional websites. Things like your bank, major social media, and other sites that are critical to protect, and are unlikely to be amateur enough to use unsalted passwords. Dividing this into important accounts like FB, and critical accounts like your bank is not a bad idea.
Outer ring: Everything else. This site is a good example of an outer ring site. These are sites that are probably not run by IT departments with cybersecurity divisions, and may have lax security. These are far more likely to be broken into, and far more likely to be easier to get your info off of.

This strategy is basically a "worst case" scenario strategy, and is based on protecting important assets while not requiring additional tech or memorization of long lists of passwords. It's 100% based on risk mitigation - essentially, the outer ring accounts are treated as disposable, and the assumption is that if one gets hacked, they'll all be at risk. Meanwhile, the inner rings are likely more secure as well as smaller in number, so in case of a breach, they'll actually have to hack your password (rather than using found hashes from elsewhere), and you'll have time to change your sites that share the same password. And your inner ring (email) is only used there, so is safe from everything except a hack of that particular service.

[Bohandas]

Current NIST practice for end users is to use long, semi-random pass phrases without complexity requirements, which are never changed unless there is suspicion of malicious activity.
This is partially a technical thing and very much an end-user psychology thing. After many years of insisting on various complexity requirements, they finally realized that too much complexity only leads to people finding workarounds like sticky-notes or changing a single character when resetting their passwords, and that this actually generates greater risk than what is achieved by complexity requirements.

The results of password complexity requirements can actually be pretty well illustrated by one of two classic cartoon gags

The first is the gag where one entrence to a place is heavily secured but there's another entence that isn;t secure at all, like this scene from The Simpsons

The second is the one where a character will lock somethig up so securely that they can't get to it either.

And never anything in between

[Rydiro]

Wall of text with salt.

Who actually stores the salt and the encrypted passwords in the same place?
Isn't protecting the salt actually the way to go?
Do sites make their hashing algorithms public or what?

[crayzz]

Who actually stores the salt and the encrypted passwords in the same place?
Isn't protecting the salt actually the way to go?
Do sites make their hashing algorithms public or what?

AFAIK most sites store their salts and password hashes in the same place together. There isn't really a realistic alternative. All salts do is resist precomputation and stop password collisions between users. It's actually not very difficult to compute the hashes for common passwords, so if the password hash leaks, hackers don't really need to even try cracking the hashed passwords, they can just look the hashes up in a table. But if they've been salted with a long salt, even precomputation becomes infeasible, so they're back to bruteforcing/dictionary attacks. Of course you don't make the salts public, but they are usually stored in plain text in the password database.

There is a separate technique called peppering in which a secret string is appended to the password before hashing, and it is stored separately away from the password database. Peppers aren't usually unique, though. They're also, AFAIK, kind of a hassle since its hard to have a true secret from someone who otherwise has access to your password database.

[kyoryu]

Do sites make their hashing algorithms public or what?

Yes, hashing algorithms are well known, because it's hard to make a secure one. Using a known secure algorithm is much, much safer than using a proprietary one which is almost certainly insecure.

Who actually stores the salt and the encrypted passwords in the same place?
Isn't protecting the salt actually the way to go?

No, because the salt isn't intended to make your password harder to brute force.

Like, if your password is "password" and I know the hash is 1234, then what I need to do as a hacker is to feed possibilities into the hash algorithm until 1234 pops out. If I salt it with "redfish", and then the hash is 5678, then I still need to throw stuff at the algorithm with "redfish" appended until 5678. It's exactly the same difficulty of problem.

Here's the problem that salting solves. Note that "password" is for your info, and wouldn't be actually in the data.

Site 1:

user	passwordhash	(actual password)
[email protected]	1234	"password"
[email protected]	2345	"secret"
[email protected]	1234	"password"
[email protected]	3456	"excellent"
[email protected]	1234	"password"

Site 2:

user	passwordhash	(actual password)
[email protected]	1234	"password"

So, now the hacker gets these dumps. They know the hash, but not the password. So they start running random data at the algorithm. As soon as they get a match for 1234 (by inputting "password") they have now compromised every account on both sites that uses "password" as their password. Which, frankly, is fine because anyone that dumb deserves it.

Let's salt it now. So now, we're not encrypting just the password, but the password plus somehting else

Site 1:

user	passwordhash	salt	(actual password)
[email protected]	5678	"redfish"	"password"
[email protected]	8912	"orangemonkey"	"secret"
[email protected]	7834	"bluebanana"	"password"
[email protected]	8930	"pinkdog"	"excellent"
[email protected]	2389	"yellowbird"	"password"

Site 2:

user	passwordhash	salt	(actual password)
[email protected]	3092	"blackbird"	"password"

So now, they get these. And to get a hash, they have to send a possibility with the salt appended to the algorithm. So even if they determine that "password" + "redfish" hashes to 5678? That gets them no information on any other user. With unsalted passwords, they see that it matches everything else. With salted passwords, the other accounts are still secure, on both sites.

[Rydiro]

Yes, hashing algorithms are well known, because it's hard to make a secure one. Using a known secure algorithm is much, much safer than using a proprietary one which is almost certainly insecure.



No, because the salt isn't intended to make your password harder to brute force.

Like, if your password is "password" and I know the hash is 1234, then what I need to do as a hacker is to feed possibilities into the hash algorithm until 1234 pops out. If I salt it with "redfish", and then the hash is 5678, then I still need to throw stuff at the algorithm with "redfish" appended until 5678. It's exactly the same difficulty of problem.

Here's the problem that salting solves. Note that "password" is for your info, and wouldn't be actually in the data.

Site 1:

user	passwordhash	(actual password)
[email protected]	1234	"password"
[email protected]	2345	"secret"
[email protected]	1234	"password"
[email protected]	3456	"excellent"
[email protected]	1234	"password"

Site 2:

user	passwordhash	(actual password)
[email protected]	1234	"password"

So, now the hacker gets these dumps. They know the hash, but not the password. So they start running random data at the algorithm. As soon as they get a match for 1234 (by inputting "password") they have now compromised every account on both sites that uses "password" as their password. Which, frankly, is fine because anyone that dumb deserves it.

Let's salt it now. So now, we're not encrypting just the password, but the password plus somehting else

Site 1:

user	passwordhash	salt	(actual password)
[email protected]	5678	"redfish"	"password"
[email protected]	8912	"orangemonkey"	"secret"
[email protected]	7834	"bluebanana"	"password"
[email protected]	8930	"pinkdog"	"excellent"
[email protected]	2389	"yellowbird"	"password"

Site 2:

user	passwordhash	salt	(actual password)
[email protected]	3092	"blackbird"	"password"

So now, they get these. And to get a hash, they have to send a possibility with the salt appended to the algorithm. So even if they determine that "password" + "redfish" hashes to 5678? That gets them no information on any other user. With unsalted passwords, they see that it matches everything else. With salted passwords, the other accounts are still secure, on both sites.

But how does the hacker know the salt?

[Misereor]

Getting someone's password by repeated attempts at a web page is ludicrously unlikely as an attack vector - for even the simplest password schema (one common word), that's 5000 attempts max. If you assume 3 tries per 20 minutes, that's 9 per hour, or about 200 per day. That's still the better part of a month - unless you're a significant official, nobody really cares about you in particular enough to do that. Any reasonable strategy (xkcd passwords, passphrases, random line noise, even obfuscated dictionary words) is going to increase that amount to a ridiculous length.

It is quite common, and obviously not targeted at individuals, but rather multiple sites with thousands of users. Trawling, not spear phishing.
Since most small and medium sized businesses don't have any but the most basic security systems or trained personnel, they often only find out if the hacker messes up and accidentally flies over the radar by locking the targeted accounts or something similar. However, that actually happens more often than one would think (script kiddies passing around flawed scripts would be my guess).

[Chronos]

There are two completely different kinds of attacks to look out for, the broad attacks and the targeted attacks. If an attacker is trying to just grab a bunch of Facebook accounts or the like (maybe to turn them into a botfarm, or to ransom a few hundred dollars each), and they don't have a leaked password file, then what they'll do is they'll just try passwords through the login webpage, only a few at a time to get past the "lock after three incorrect" security measures, but they'll try it on every account they can find all at once. They don't care whose account specifically they get; just that they get lots of them. Against this type of attack, writing down your password on a post-it note stuck to your monitor isn't a problem, because the attacker can't see your monitor.

The other kind of attack is when someone's trying to target you, specifically. Maybe this is because they don't like you and want revenge. Maybe this is because you, personally, have access to something valuable. In this case, putting the password on a piece of paper is a vulnerability... but very few people will be targets of this sort of thing.

There's also a case in between: The attackers start by attacking some unimportant site with a broad net, but then, once they break a few of them, they start looking around for other, more valuable, sites that might use the same username and password. If someone cracks my GiantITP password, well, that's annoying, but ultimately no big deal. But if I use the same username and password at my bank (which is probably one of about a dozen major banks in the nation, so even if I've never said which it is, the attackers can just try all of them), then that's a huge problem. The solution to this is to not re-use passwords, or at the least, not re-use passwords on important sites.

[Keltest]

There are two completely different kinds of attacks to look out for, the broad attacks and the targeted attacks. If an attacker is trying to just grab a bunch of Facebook accounts or the like (maybe to turn them into a botfarm, or to ransom a few hundred dollars each), and they don't have a leaked password file, then what they'll do is they'll just try passwords through the login webpage, only a few at a time to get past the "lock after three incorrect" security measures, but they'll try it on every account they can find all at once. They don't care whose account specifically they get; just that they get lots of them. Against this type of attack, writing down your password on a post-it note stuck to your monitor isn't a problem, because the attacker can't see your monitor.

The other kind of attack is when someone's trying to target you, specifically. Maybe this is because they don't like you and want revenge. Maybe this is because you, personally, have access to something valuable. In this case, putting the password on a piece of paper is a vulnerability... but very few people will be targets of this sort of thing.

There's also a case in between: The attackers start by attacking some unimportant site with a broad net, but then, once they break a few of them, they start looking around for other, more valuable, sites that might use the same username and password. If someone cracks my GiantITP password, well, that's annoying, but ultimately no big deal. But if I use the same username and password at my bank (which is probably one of about a dozen major banks in the nation, so even if I've never said which it is, the attackers can just try all of them), then that's a huge problem. The solution to this is to not re-use passwords, or at the least, not re-use passwords on important sites.

I would argue that if somebody is going after you, specifically, the post-it note in a cabinet somewhere is still incredibly secure because A: people wont realize it exists, and B: breaking into my house that they in all probability dont know how to find while getting past any other residents, any actual locks and security systems and, you know, me being there, means that if they somehow gain that access, they are really no longer in any need of a sticky note, they can just hit me with a crowbar until I tell them the password.

[Rydiro]

.... they can just hit me with a crowbar until I tell them the password.

Illustration:
https://xkcd.com/538/

[Whoracle]

me being there, means that if they somehow gain that access, they are really no longer in any need of a sticky note, they can just hit me with a crowbar until I tell them the password.

Relevant XKCD (because of course there is one): https://xkcd.com/538/

As for the topic: Use whatever scheme you like apart from using well-known dictionary passwords, but enable MFA. And not the "Send me a code to my email" either, unless you can at least secure your email with another Factor. Use stuff like FreeOTP (preferred by me because open source), Google Authenticator, Microsoft authenticator or something like a yubikey hardware token if your phone supports NFC. At least for your email account, if you get your 2nd factor via email from some services.

The whole salting/peppering/only hashes are stored in databases is outside of an end-users domain - you have no power over that. And companies quite often skimp on security because security personnel is expensive, and for some unfathomable reason it's not the company that deployed insecure software (or the ones that WROTE insecure software*) that gets blamed when a database dump full of credentials is exfiltrated, but instead such hacks are treated as (literal quote) "akin to natural desasters". NO, YOU CHUCKLEF***S, YOU DEPLOYED CRAP AND SOME ASSH*** WITH A TRIVIAL EXPLOIT JUST WALKED OUT OF THE DOOR WITH MY PERSONAL DATA THAT I ENTRUSTED YOU!

Ahem... sorry. Still, salting/peppering/hashing etc. is not the end-users business. And since you can't trust the companies to keep their stuff secure, you use multiple factors, because sooner or later your password WILL be compromised somehow. If it will be utilized is another topic, but still. Better safe than sorry.

* and refused to release a patch for known vulnerabilities for half a year... yes, I'm looking at you, Oracle with your java vulns, although you're certainly not alone... seriously, most third-rate open source projects measure responses to known vulns in hours or days, but god forbid that the juggernauts that are IBM, Microsoft, Oracle et al. do the same in anything approaching a timely manner. Currently, the widely accepted practice is "90 days from initial information to the vendor, then the bugs get disclosed publicly", and these companies STILL want a longer period... GOD, this tickles my hate bone.

[crayzz]

I would argue that if somebody is going after you, specifically, the post-it note in a cabinet somewhere is still incredibly secure because A: people wont realize it exists, and B: breaking into my house that they in all probability dont know how to find while getting past any other residents, any actual locks and security systems and, you know, me being there, means that if they somehow gain that access, they are really no longer in any need of a sticky note, they can just hit me with a crowbar until I tell them the password.

If a stranger is going after you personally, then maybe, but the issue with interpersonal conflict is that its usually with people who know you pretty well. This becomes a problem if you e.g. get into a fight with your brother-in-law over who owes who money and he gets it into his head that he's just gonna transfer the money from your bank account himself. He doesn't need to break into your house, he's been invited for christmas dinner, and he might well know the sticky note exists if you've been anything less than vigilant in keeping its existence secret.

This maybe sounds like the premise of a bad hallmark christmas movie about learning to forgive and heal the divide between family members, but its not exactly uncommon for e.g. parents to decide their 20 year old child shouldn't be allowed to make their own financial decisions, or for a grandkid to try to take advantage of grandma's pension.

Generally, modern security relies on being secure even when the attacker knows a lot of information about the system and you. They can know the lock types, they can know where the keys are stored, they can know what password manager you're using, they can know what hashing algorithm you're using, etc etc. If you wanna use a sticky note, use a password manager: use a sticky note so secure it doesn't matter if anyone gets their hands on it because they won't be able to read it anyway.

[Bohandas]

There's also the possibility of if you keep your password sheet on your person (because more often than not you're going to be logging in to things far from home, via your smartphone) and then get mugged - or just accidentally drop it. That's a problem with passwords that are too complicated to remember too.

[veti]

There's also the possibility of if you keep your password sheet on your person (because more often than not you're going to be logging in to things far from home, via your smartphone) and then get mugged - or just accidentally drop it. That's a problem with passwords that are too complicated to remember too.

Well yes, but if either of those things happens, you'll probably know about them fairly soon.

Physical security is a well understood, easily intuited problem. We've been thinking about it for thousands of years, ever since our ancestors first came up with the idea of keeping stuff for themselves. It's much, much easier to manage than digital security.

That's why I advocate writing your hard passwords down and keeping them on your person. In your wallet is probably a good choice, unless you get mugged or pickpocketed regularly.

[Chronos]

If you get mugged, then the mugger might know your password, but they won't know your usernames or where your accounts are. They'd have a head start on figuring those things out, but there's not a lot of overlap between the folks who commit muggings and the folks who commit cybercrimes. They might sell your information to someone who does commit cybercrimes, if it occurs to them. So it's a vulnerability, but not a huge one (especially since, when you get mugged, you'll know you need to change your passwords, and can probably do so quicker than the mugger can sell the information and the cybercriminal can finish the attack).

[Khedrac]

The problem with writing passwords down like that is that it can violate terms and conditions even if it is more secure.

A number of years ago I worked for HP (before it started splitting) and someone asked in an open meeting why we still had to change our passwords every 3 months when research showed passwords were less secure that way. Surprisingly we got an answer that made some sort of sense - one of HP's contracts with big a customer required it! So until the contact was updated they couldn't switch off the 3-month password expiry for the main networks.