patrick.net

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.