patrick.net

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.