patrick.net

richwicks says

My first reaction to reading that is "you don't know what the fuck you're talking about".

But you're right. I was certain that Apache's dialogue box accepted a hashed password that was generated on the client. It doesn't, the password is sent in the clear - I just checked.

There's other auth methods commonly used, and some of them also send a plain text password. For example, the method used by this very site is by far the most popular method in use on the web - and it just uses a basic html form which submits the username and password as plain text.

richwicks says

Apache's dialogue box

Apache is just an http webserver, and can be used in many different ways to support logins. It doesnt have its own dialogue box - thats the web browser making an "http authentication" box in response to seeing an http header in the the webserver response. Historically, the most common type of "http authentication" is "basic http authentication", which is probably what you tested, as it sends the credentials to the server as plain text.

There's also "http digest authentication", which uses hashing to avoid replay attacks, as well as to prevent transmitting the password as plain text. But nobody really uses it anymore. Digest was popular before ssl became ubiquitous, and people used it because the easy alternatives (basic auth or html forms) transmit the password as plain text, which is horrible when not using ssl. But now that everyone DOES use ssl, most sites have rolled their own login mechanism via an html form as patrick did, and some sites still use http basic, especially for REST apis.

The big problem with digest auth, which is a form of hashing on the client thats done using a 1-time-use salt, is that the server needs to know the actual password, or something equivalent to the actual password. Storing the password hashed and salted on the server wont work with digest auth. well, technically they do store it hashed and salted, but the problem is this hash ends up functioning like a password if an attacker can get it - so its "equivalent" to storing a password in most regards. I already mentioned that you would need to use one of those 3 scenarios I laid out to accomplish client side hashing with a 1 time use salt, and digest auth is an implementation of that which chose one of those 3.

btw in my previous post I stated I thought #3 was possible and would work well, but I take that back. It would work, but I feel the stored hash would function as a password, if disclosed, just like w/ digest auth.

So ya, most sites are sending the username and password as plain text with SSL/TLS, or some use more elaborate stuff like SSO/OAuth. They could use digest, but it's probably a step backwards at this point. Due to SSL, it's already tough to read the password in transit between the browser to the webserver, so sending a hash, while beneficial, is probably not a large benefit. I don't think its worth the cost of storing unhashed passwords (or something equivalent to a pw) on the server in order to make use of digest.

Industry and especially enterprises are quickly moving towards oauth, as one of its many benefits is that the user doesnt need to type credentials into the web site - the users browser is redirected to the origin identity provider website, and they login there, then they get redirected back to the specific web site, and are then logged in without ever sharing a password with that individual site. Of course the origin identity provider receives a password, but its better that 1 site with a focus on doing secure logins gets the password, than many sites. There's lots of pros and cons to using something like oauth. A nice oauth + SSO benefit is it makes 2fa less painfull - you can 2fa into the identity provider 1 time per day, and then all the other websites just share your login session without necessarily requiring you to 2fa again for each site.

NuttBoxer says

Hircus says

How could you identify passwords in logfiles with certainty, so as to "sanitize" the logfile?

Dude, this is literally a CISA requirement. Had to test this for a former employer, and had to implement it to keep sensitive creds from showing up in our test logs. That you would even say this tells me you don't have the experience to weigh in here.

First it was strawman arguments.

Now its ad hominem. You try to discredit me instead of debating my point (because you cant identify passwords in logfiles with certainty).

Hircus says

First it was strawman arguments.

Now its ad hominem. You try to discredit me instead of debating my point (because you cant identify passwords in logfiles with certainty).

Just because you don't understand the argument, doesn't make it invalid or insulting. It just means you're in over your head, so maybe try a little humility. Masking creds is so common, rather than asking me for my personal experience, you can easily find a hundred examples online. But yes, I did mask sensitive creds, and I will again. Logs are programmed to detail specific data events, they're not random dumps of meaningless combinations of words. All you have to do is know the pattern that precedes the string you want to obfuscate.

But I think I'm wasting my time explaining this, as you don't give a fuck. You're too busy being arrogant.

porkchopexpress says

I live and breath cybersecurity. It's my job.

@porkchopexpress

Ah - found you. Besides OpenSSL, what do you suggest for a crypto library? I'm looking for AES256 and ECC public/private keypairs. I'm playing with the NaCL library:

https://libsodium.gitbook.io/doc/?source=patrick.net

But I'm running into an issue that the public/private keypairs it generates for different things (Diffie–Hellman versus digital signatures for example) I have to generate a completely new keypair rather than being able to reuse them. Got another library to suggest?

NuttBoxer says

Just because you don't understand the argument, doesn't make it invalid or insulting. It just means you're in over your head, so maybe try a little humility. Masking creds is so common, rather than asking me for my personal experience, you can easily find a hundred examples online. But yes, I did mask sensitive creds, and I will again. Logs are programmed to detail specific data events, they're not random dumps of meaningless combinations of words. All you have to do is know the pattern that precedes the string you want to obfuscate.

-You said the policy of rotating passwords was useless.
-I cited one of many examples where the policy is useful (when your password is disclosed, maybe accidentally). If you understand logic, a single useful example invalidates the "useless" claim. Plus, there's much more than just one example - you just dont understand them.

-I even cited an example how this could happen (pw accidentally ends up in arbitrary logfile). Not that I needed to cite a specific example, because citing the general category of password disclosure is sufficient to invalidate your "it is useless" argument.
-You said logfile sanitation would be a better defense than pw rotation.

The problem with that is you kinda need the "logfile sanitation" method to work for all possible log formats (or at least most popular formats in actual use) in order for that argument to even have a *chance*, because the pw rotation policy surely works for all logfile formats, and it also helps defend against many other password disclosure scenarios besides "passwords in logfiles".

I even gave an example of how a password can end up in a url, which of course means it will end up in an a webserver access logfile. A typical web server access log will log the url and query string. So if the pw ends up in a url, it will be in the logfile. Query string parameters are expected to be in the logfile, and the parameter names and values are quite varied from log entry to log entry, and so are their orders. You will not know which params and values are be expected (unless this is a trivial application), nor will you know where a password could be. Typical nginx webserver access log entry:

66.249.65.159 - - [06/Nov/2014:19:10:38 +0600] "GET /news/foo.html?param1=val1&Param2=val2&p=I_AM_A_PASSWORD&Param4=val4 HTTP/1.1" 404 177 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

To "identify passwords in logfiles with certainty" means your sanitization method should always work, and not miss passwords sometimes (and ideally, not strip out false positives either). Log formats are so varied, and you cannot rely on the password being in a certain parameter name, nor could you depend on just "stripping out strings that look like passwords" because some passwords are indistinguishable from other strings that are expected to be present. If you miss some passwords, then you are not identifying them withcertainty- you are missing some.

NuttBoxer says

But I think I'm wasting my time explaining this, as you don't give a fuck. You're too busy being arrogant.

Oh, the irony of you saying that. You've been schooled over and over again, resorting to subterfuge to try "be right" about something. And you still keep grasping onto your faulty positions, such as your odd "2fa is 100% useless" bleat.

That chart is useless and not true in most cases. Passwords are not hacked instantly or in a time, it's tries!
And any decent security system should detect the wrong password has been put in wrong after short amount of tries. 3 to 5 tops!
If a security depends on the users doing their job for them, by coming up with passwords they can't remember and will likely forget, then they just write them down to make the job for Boris the Russian hacker's job easier. Sasha his Russian girlfriend cleans your office on Tuesdays the Thursdays, she looks under every keyboard and takes pictures of every post it note with a password on it. That is how Boris hacks computers "Instantly".

Tenpoundbass says

And any decent security system should detect the wrong password has been put in wrong after short amount of tries. 3 to 5 tops!

The assumption you must ALWAYS make is that the attacker has the encrypted password file and the algorithms for it.

That's worst case - you always plan for worst case.

richwicks says

The assumption you must ALWAYS make is that the attacker has the encrypted password file and the algorithms for it.

That's worst case - you always plan for worst case.

To my knowledge not one single major Enterprise hack, or malware, trojan or encryption has been performed because a hacker cracked or guessed the admin password or of some rando user. It's most always from someone in the enterprise opening a spoof or phishing email.
The whole change your password just adds more complexity that gives the "Security" contractors job security. The amount of energy over hassling users over passwords and the lost productivity over it, cost the Enterprise more than they gain.

H@rvey123 is just as good of a password, as some crazy complex password with numbers and characters that has to be over 12 characters. With proper protocols and policies in place, how weak the password is, should be irrelevant as long as it isn't a stupid password like abc123 or password123. After the 3rd try your account should be locked. Period!

St@pWith1! these kinds of passwords.

IdLikeToBeUnderTheSea! instead. In an Octopus' Garden easy.

We were habituated to Hrd2ReCl but LandmineHasTakenMySight Or HerNameWasLolaSheWasAShowgirl Or ShineOnYouCrazyDiamond is sure easier to remember and faster to type and better.

AmericanKulak says

St@pWith1! these kinds of passwords.

IdLikeToBeUnderTheSea! instead. In an Octopus' Garden easy.

We were habituated to Hrd2ReCl but LandmineHasTakenMySight Or HerNameWasLolaSheWasAShowgirl Or ShineOnYouCrazyDiamond is sure easier to remember and faster to type and better.

I'd caution you with phrases that are well known.

EatAnAppleOrABear

That's never been written before, and will never be written again.

AmericanKulak says

ShineOnYouCrazyDiamond is sure easier to remember and faster to type and better.

Except for the Ahole IT managers that demand a Strong password. Using so many special characters and numbers.

The worse is autogenerated passwords and you don't have easy access to change it.
bm9XjoK#3nMG0cV0
This was a real password I had to use at one time. Which I always copied and pasted into the password box. I bet that's easy to capture for a hacker, than figuring out the complex password.

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.

richwicks says

porkchopexpress says

I live and breath cybersecurity. It's my job.

@porkchopexpress

Ah - found you. Besides OpenSSL, what do you suggest for a crypto library? I'm looking for AES256 and ECC public/private keypairs. I'm playing with the NaCL library:

https://libsodium.gitbook.io/doc/?source=patrick.net

But I'm running into an issue that the public/private keypairs it generates for different things (Diffie–Hellman versus digital signatures for example) I have to generate a completely new keypair rather than being able to reuse them. Got another library to suggest?

This isn’t my deep area of expertise, but what implementation language are you using?

Libgcrypt or crypto++ could be other options

Tenpoundbass says

The worse is autogenerated passwords and you don't have easy access to change it.
bm9XjoK#3nMG0cV0
This was a real password I had to use at one time. Which I always copied and pasted into the password box. I bet that's easy to capture for a hacker, than figuring out the complex password.

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.

Agreed. Long passphrases for ones you have to remember such as a vault or network password, but random generated at least 16 (I do 20) characters in a password manager for everything else because you won’t have to remember them. If the target system uses a good hash algo, they’ll never get cracked.

@porkchopexpress If you have security advice for patrick.net, please let me know.

Please poke around and tell me if you can break in in any way.

I once saw a study about pass phrases, where 5 out of 20 people chose the same passphrase, and most all chose a common meme or catchphrase.
Because "LetsGoBrandon" is easier to remember than "BaloneyBlanketGearMuch" or some random joining of words they never put together before, and probably wont remember if they don't write it down.

porkchopexpress says

This isn’t my deep area of expertise, but what implementation language are you using?

Libgcrypt or crypto++ could be other options

I'm using C. Libsodium MIGHT be OK to use. It's a little strange as a library, but it's very simple to use. If I can just get a public/private keypair for both signatures AND doing Diffie Hellman I'm set. One thing I like about the library is that it's not GPL, it's not BSD, it's "free". The Tox IM protocol uses it.

Tox has severe problems with it though:

1) It's awful on data transfers. It's SO SLOW, and 1/2 the time, the file gets cancelled.
2) You cannot log into two devices on the same account at the same time.
3) Both users have to be online at the same time to send a message (not so bad really)
4) Video and Audio are built into the library
5) If I have a friend's ID, I cannot give it to a 3rd party so they can add them to their list
6) TERRIBLE API to code.

There's some genius ideas in it:

1) No need for a server - good and bad, in that it really sort of does, but just to connect the users.
2) P2P and E2E communication.
3) Complete IP address independence.

Patrick says

@porkchopexpress If you have security advice for patrick.net, please let me know.

Please poke around and tell me if you can break in in any way.

I just did a light scan and nothing too concerning showed up.


You also have some missing security headers:
Content-Security-Policy
X-Frame-Options
X-XSS-Protection
X-Content-Type-Options
Referrer-Policy
Strict-Transport-Security

You do expose some information such as Nginx 1.18.10 and JQuery 1.11.2, which a hacker could leverage but I'm not that worried about it.

Thanks @porkchopexpress

I plan to remove jquery anyway, but will make a note of the headers and hide the server name and version.

Tenpoundbass says

That chart is useless and not true in most cases. Passwords are not hacked instantly or in a time, it's tries!

Seems you've never heard of the re-authentication attack for wifi. I force all your devices off, then grab your WPA key when you log back in. From there I just run a dictionary against that key until I find a match, then I have your password. It's been a while since I took that security class, so apologies if some of my terms are the most accurate.

NuttBoxer says

Tenpoundbass says

That chart is useless and not true in most cases. Passwords are not hacked instantly or in a time, it's tries!

Seems you've never heard of the re-authentication attack for wifi. I force all your devices off, then grab your WPA key when you log back in.

Isn't the key sent over on AES after it key exchange is determined by Diffie - Hellman? I mean, we've had this shit around a LONG TIME as part of web page TLS security. I know RSA calculation is pretty expensive computationally, but ECC isn't.

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.

That's why companies need to have password manager subscriptions. Make it stupid simple for the users to create and save complex passwords without having to ever write them down or memorize them.

NuttBoxer says

That's why companies need to have password manager subscriptions. Make it stupid simple for the users to create and save complex passwords without having to ever write them down or memorize them/

@NuttBoxer

I have a patent idea that would work though, that wouldn't do that, and would be pretty damned secure. Would require some hardware, but it would be cheap and fairly easy to make.

I think one theme I keep seeing here is people assuming a hacker always targets a specific individual. Unless they are a high profile target, this never happens, and no one on patnet meets that criteria. What they will do get a list of users, setup a bot farm, and run a dictionary against every user in the list. The shorter the password, the less combinations they have to iterate through before getting to one that works. I honestly don't see any hackers targeting this site, except for government. And while you might not think that's a big deal, look at the attack on freedom of speech the last few years. Then look fascist regimes of the past or present. It's a big deal.

And yes, as pointed out, SW exploits and phishing attacks, and social engineering are the most common types of attacks. But the stronger your security practices are overall, the less chance you'll ever be targeted or compromised, including password length. I mean, as much as it's gotten poo-poo'd here, with justifiable examples, I've never ever heard a security person in personal conversation, conference, class, etc, say password length doesn't matter.

NuttBoxer says

What they will do get a list of users, setup a bot farm, and run a dictionary against every user in the list.

How does that work when after three tries the account is locked out?

HeadSet says

How does that work when after three tries the account is locked out?

THat's what I keep wanting to know.
I think this is just bullshit the Indian IT cabal that has America's computer infrastructure hostage with inept idiots running those IT shops. Like to spread to cover their incompetence and to support their failed IT best practices.

They want us to believe that hackers hack networks like you would see in 80's and 90's movies where the bad guy hackers would hack defense computer systems to steal the nuclear launch codes. Using a program that parses a long password list and tries every combination. That image is ingrained in our minds so we just take it for face value when they say bullshit like this.

Systems are compromised due to the impossible passwords and the constant password changing, dragging every computer user through stupid unnecessary steps because one of the network guys was looking at porn or downloading binaries and caught a nasty Trojan, or the Receptionist opened a phishing email.
Which would reflect very bad on the IT management for not having the network locked down that people could browse unsavory sites, or malware email could get through their mail filters. And you'll never prevent network intrusion when your users are forced to write their password down so they will remember it.
And changing your passwords at any weird time interval does absolutely dick all but create more opportunity to compromise your password.
The only time you should need to change your password is if you have reason to believe your password has been compromised or the password list has been breached.

FWIW I am using the exact same password I created for my very first Windows 95 machine and used to sign up for AOL in 1996.
It has never been compromised.

Tenpoundbass says

FWIW I am using the exact same password I created for my very first Windows 95 machine and used to sign up for AOL in 1996.
It has never been compromised.

AOL probably recorded the password in the clear, meaning it was compromised, however a password is pretty worthless with a Windows 95 machine - you can't do a remote login on it.

I've been using Linux as my main OS since Slackware 0.99 - 120 floppy disks, back in I think 1993. That can be compromised. I don't even use a recognizable username on my machine, much less a common password, and "root" is disabled by default. I don't even use a standard port. Try to crack my machine:

samoyed.dynu.net
or
75.31.75.102

I'm just pointing out that security is 99.999% not getting a phishing attack. You cannot attack my machine even if you go through all the CERT advisories.

HeadSet says

How does that work when after three tries the account is locked out?

Maybe not the best example, but the point is, the attack will be much broader than a single user, and weak password requirements mean less guesses before getting a match.

Tenpoundbass says

FWIW I am using the exact same password I created for my very first Windows 95 machine and used to sign up for AOL in 1996.
It has never been compromised.

I think most of us agree changing the password isn't as important as picking a good one to start with, and NOT re-using it. The only exceptions I can think of are Wifi, and your bank account. The bank isn't about someone guessing it, it's about a data breach where they scoop you up with everyone else, and you have a real risk of losing something(your next paycheck).

richwicks says

I'm just pointing out that security is 99.999% not getting a phishing attack.

So true. Over 90% of successful cyber attacks involve some sort of social engineering (e.g., phishing) because it works.

NuttBoxer says

HeadSet says

How does that work when after three tries the account is locked out?

Maybe not the best example, but the point is, the attack will be much broader than a single user, and weak password requirements mean less guesses before getting a match.

The assumption has to be worst case scenario.

Assume the encrypted salted hashed password file is available.

Of course a direct attack can be thwarted by adding 1 second between an attempt. Assume they have direct access, that they have bypassed the hardware and have direct access to all files. That's what you're dealing with when you're dealing with an intelligence agency and some traitorous fucking company like Amazon. Don't trust 3rd parties to help you, ANY 3rd party.

richwicks says

I don't even use a recognizable username on my machine, much less a common password, and "root" is disabled by default.

I disabled password logins entirely on my patrick.net machine. The only way in is the ssh key.

I see a lot of arguments like "you dont need to include special characters / numbers/ uppercase / etc to have a strong password" or other such arguments against the common password policies in use. 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, and adding additional password complexity requirements by forcing them to include more character classes results in significantly stronger passwords for these users.

Here's part of a common password policy:

1) "use at least 3 of the following 5 character classes"
-lowercase
-uppercase
-digits
-punctuation
-unicode chars
2) use at least 15 characters

It's difficult to make a bad password while adhering to that policy. And thats a very good thing. Of course it has drawbacks like realistically making most users resort to password managers or files, as the passwords aren't usually easy to remember. Tradeoffs...priorities...how juicy of a target are you...etc...

If an enterprise only had users who only ever created strong passwords, and were well versed on what is and what isn't a strong password, then I dont think you would see these policies used. But even when educated on good passwords, many dont care, and still try to create shit passwords (I once logged every failed change password attempt which did not meet my password complexity requirements, and many of them were horrible. I saw some in the top 10 WORST passwords, like "Password!" "letmein". Every single one of these users completed training and a quiz on password strength within the past year too).

LONG Passwords like SheDrankBearFaceForBreakfast etc... are good if theyre long. English has over 100,000 words although, people never use the rare words in passwords.
Even if we assume the typical password only chooses words from the top 500 english words, the complexity of that 6 word password is approx: 500^6 = 15,625,000,000,000,000 possible passwords, which is pretty good (although, theres other factors I didnt consider that actually weaken it and make it easier to guess - ie this password follows english sentence structure, making it significantly more guessable). But a 3 word one would be 500^3 = 125,000,000 which isnt very good at all.

There's a nice javascript library that I've been using for years, "zxcvbn" made by dropbox, which attempts to calculate a numerical score of the strength of a password. It considers easily guessable stuff like:
- words that are commonly used in passwords,
- common (and thus WEAK) character substitution schemes (like changing "Password" to "P@ssw0rd", and l33t speak are somewhat weak because its so easily predictable and common),
- how users like to add numbers and punctuation only to the end of their passwords ("password" becomes "Password123!"), and only capitalize the first letter.
- keyboard repeats / sequences / runs (aaa 555555 abc xyz 12345 qwerty qaz zxcvbn etc)

It allows me to more easily stop users from creating shit passwords that they think are strong, but actually suck, AND give my users feedback on why their desired password sucks.

Userid lockouts after too many failed login attempts are excellent against brute force attacks, and greatly reduce the need for a strong password as it makes brute force attempts slow down, forcing them to make password guesses very slowly. I use them in my systems, although they dont seem overly common in end user facing systems for non power users from what Ive seen. I suppose few end users understand the concept, and thus it would be very bad for usability. Personally, I coded for over 10 years before I ever encountered the concept of a userid lockout, so I can only imagine the typical user doesnt meet it often either.

Also, many megacorps have such large complicated systems made from monkey patching things together for decades, and things like password lockout are often not straight forward on all integrated pieces, and thus its not used everywhere. A strong password can prevent those pieces from being weak points. And corporate security is all about bringing up the weak points to some minimum.

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.