patrick.net

TheyCallMeTheWalrus and PurpleHazeAllInMyEyes are great passwords. Especially if you pop in some punctuation symbols somewhere.

Consider phrases/poetry phrases/scenes also:

TwasBryllygAndTheSlythyToves
YouDidntGambleAndSpendAllThatFuckinMoneyYouFuckinDegenerateYou
CountEveryBlueberryInTheMuffin

Tenpoundbass says

My point is the more complex they make passwords, then the lazier the user will be to have that impossible password handy, and the easier it will be for the baddies to retrieve it for the users actions of storing it on a sticky note, or pasting the password from a file on their computer.

Websites can read your clipboard data (although, modern browsers do prompt the user to approve the site reading their clipboard data, but this approval is done only a single time and is then remembered. Many users instinctively click "ok" to all prompts to make the "fussy computer" behave). So a user who copy pastes a password, and then doesn't copy another value into their clipboard to overwrite their password, is at risk of disclosing it to other sites for as long as it remains in their clipboard. Many users copy paste passwords regardless of pw complexity, though.

This is a terrific example of password disclosure, and why a strong password alone does not well protect a user.

2FA saves the day here.

@patrick I recall some years back we discussed your "bbcode" implementation. I recall finding xss holes in it, and recommended doing string replacements in a loop until no further changes/replacements were detected. Not sure if you ever addresses that code, but if not, I bet you still have xss holes.

One thing I would strongly recommend is developing a restrictive "CSP policy", where you disable browser and scripting features you dont want. For example, by telling the browser you will never use inline js via

<script>code</script>

or

<a onclick="...code..."></a>

you can easily and robustly thwart most xss vectors and sinks. CSP can potentially be very powerful against xss if you dont mind writing your code in certain ways, such as putting all js in .js files. CSP can support allowing you to use inline script tags safely if you tag each with a random-per-page-load nonce, or tagged with a checksum of the code contents.

You can also tell it which domains it is allowed to load scripts from (do not ever grant it to load code from a CDN, which I know you wouldnt do anyway due to the tracking/trust issue, but all CDNs host exploitable js code, which can be used to escalate executable code and get around your CSP restrictions because you greenlighted the code from that domain).

Read up on it, its very powerful.

Hircus says

It's true, you can make a very strong password with just lowercase. But that's not the point - the policy is used because SOME users will create weak passwords if the system lets them type it in

Or as you just said, fuck the special characters and just make the minimum length requirement longer.

My current work password is the second half of the companies name with a capital first letter, followed by 1@. An admittedly shitty password that wouldn't be very hard to guess, and that's on purpose, because they require 2FA to access the companies password manager. Now if I could open the password manager first, I'd use that to randomly generate every password I have to setup. But because they put it behind a bunch of red tape, I barely use it at all. And because I'm forced to change it every three months, and it can't be re-used for at least n cycles, I'm going to keep picking incredibly similar, easy to guess passwords so I don't have to worry about forgetting them.

Texbook example of corporate bullshit.

Hircus says

CSP can potentially be very powerful against xss if you dont mind writing your code in certain ways, such as putting all js in .js files.

Yes, I remember that CSP header thing, and I do have my .js in a separate file right now, but it's a pain in the ass in development, because you have to load the new js file somehow each time you change it, and the html that the js acts on is separated, so the connection between the two is not obvious. And I just don't like having multiple files.

So security and programmer convenience are a bit opposed in this case.

I do try to filter out all script tags from user input, but maybe that's not enough.

Maybe I'm missing an angle, but if you sanitize all user input, not sure you still need a separate JS file.