Hacker News Reader

Comment by kspacewalk2 | Hacker News Reader

Due to the nature of my job and the age of some of my coworkers, I am sometimes casually given passwords on a piece of paper. Out of a sample size of conservatively 20, I have never even once (!) seen a special character other than !. It just doesn't happen. Password rules and a requirement to change your password every X months are pure security mirage and just create frustration in people who often struggle to generate even one secure password in their entire lifetime.

(Yes I evangelize password managers around here. So far I've converted 2-3 people. They are the important people with shit people might want to steal on their computers/accounts, so I'm happy with this.)

View on HN

> Password rules and a requirement to change your password every X months are pure security mirage and just create frustration in people who often struggle to generate even one secure password in their entire lifetime.

Every place I've ever seen or heard about with a "change every X months" system, everyone just uses a (often shared!) formula to come up with variations that satisfy the is-this-too-close-to-your-last-X-passwords checker, based on the date or whatever.

I got up to P@ssW0rd12 at one job.

I was working my way to it, when IT rolled out a new policy of "cannot share more than 2 consecutive characters with a previous password" or something like it, included in an email along the lines of "an audit has found this new policy applies to you".

Dicks.

And that's how you ensure everyone writes their password on a sticky note.

Eh, a sticky note is pretty darn secure for the kinds of attacks you care about. If your attack vector is someone breaking into your office the security game changes completely.

Yeah they either need a keycard or some tailgating to get to the bottom of my keyboard at which point they could just take the damn laptop and shuck the drive into an external enclosure and get everything that way, so nbd in my opinion.

> shuck the drive into an external enclosure and get everything that way

Disk encryption (ie, BitLocker) is supposed to prevent that from working.

> If your attack vector is someone breaking into your office the security game changes completely.

There are at least two other important attack vectors against "sticky notes": accidental sharing through photographs and/or online meeting cameras, and visitors memorizing visible passwords. Both are defeated by hiding the sticky note below the keyboard, but my guess is that most people leave it visible on the monitor bezel.

I leave a post it on my monitor with a wrong password as a decoy.

If that policy is enforceable, someone would have to be storing passwords in plaintext, or the hashing algorithm is too weak.

IT shouldn't be able to tell anything about plaintext password similarity beyond equals or not-equals.

I had a similar concern. Or maybe it was a company wide email and that language was in there just because.

Of course, our company-wide email was down for 2-3 months a couple years ago due to a ransomware infection, so our IT isn't stellar. So who knows!

Ad-hoc, this is correct.

But at the time of the password change, no, assuming password changing requires you to enter your current password as well.

If just with previous password, then yeah, that's fine, but more then likely they are saying with the previous N passwords, which would require storing the previous N passwords in some kind of plain text or easily reversible form. Even if those old passwords are useless at that point (which might not be the case for something like a laptop that hasn't talked to the domain controller and learned that the password has been updated or something), it's still dangerous (what if they used that password on a vendor's site, or on their own banking login...)

The password-change form should be using a password field, and that should not be allowing any code or scripts to grab the plaintext stored in it.

If the code that compares your current password to the new password can read the plaintext of your passwords, so too could a malicious program.

Using HTML input type="password" alone is not sufficient protection. The same steps that protect password changes from malicious attackers must necessarily protect them enforcement of bad IT security policy.

The check is done server-side.

At the time of a password change, the server still has your old password hash stored, and in the process of changing it, you are sending both your old password and new password. The server can verify both that your new password and old password differ enough while also verifying that the old password you sent it is valid.

Doesn't that imply that the are saving your previous passwords in plain text somewhere instead of saving hashes of them? How is this more secure?

This would be my guess too. Alternatively, maybe they save hashes of all substrings of length > 2 and check all hashed substrings of the new password against them.

(Which - in my limited understanding of infosec - would be only marginally better than plaintext, but I can be wrong.)

Yeah, having hashes of substrings of a password would help a LOT when brute forcing. If I have a 10 char pass, and I'm storing 1 hash of the full pass + 9 hashes of the 2-char substrings, I can now brute force all those 2-char hashes and then fit them together in the few valid ways they could go together (assuming there is more than 1) until I find the final hash. Salts wouldn't matter.

Usually, when you change your password, you have to enter your old password. With both plaintexts, the check is trivial.

It also means it should be possible to bypass that by changing the password twice or by "forgetting" your old password.

Another possibility is that they simply lie to you and the rule that is actually checked is much more permissive. I've often seen requirements that are not actually checked

Sounds like we have similar roles. I've never gotten them on paper, but multiple times a month I get emails along the lines of "My account doesn't work. My password is Banana1. Please fix". Every time I reset every single password they have (at least 4 hours of work for them) and inform them not to share passwords. Still, I've had users do it multiple times.

I finally got all of our admin/root passwords into a password manager with sharing among job functions and our CTO as backup to ensure some level of continuity. After losing passwords to multiple production systems after someone leaving the company it was still a battle.

Congrats on getting them to use a password manager, now everyone can see all of their password by typing in the master password they stuck to the side of the screen.

I'm only half-joking sadly, people just don't understand why password exist in the first place, so they comply maliciously.

I'm sure people do that, but the fact that they only have one password to remember, and (hopefully) don't have to rotate it would hopefully deter them

Requirements for uppercase letters, numbers, and special characters mean I stick an "A1!" at the end of my otherwise strong and memorable password. I'm sure I'm not the only one.

Yeah, at least there's a good work-around for the numbers/symbols requirement. What's more annoying is when sites have a low maximum length so you _have_ to use special characters to get good entropy, or when they have other bizarre requirements like "can't contain more than 3 of the same character".

Todays computers can brute force passwords of their maximum length in a few hours.

I suppose someone somewhere has a maximum length that is hard to brute force, but I've never seen it.

What max length? Once a password reaches 128 bits of entropy the key space is unfathomably large. You could have a password of length 1 with 10^100 possible values, and it could take a VERY long time to crack. In short, it has nothing to do with length, it has to do with bits of entropy, and there are still very real limits to what even the most powerful computers can brute force. Several years back, it was stated by Peerio that an 81-bit password would cost a billion dollars to crack. It becomes less feasible and more expensive from there.

8 character, upper lower case, ten numbers, and about fifteen special symbols. About 6 bits per character. Most limits are 8 characters, so around 40 bits. More or less depending on the exact rules used.

That assumes true random passwords, most attackers can make some educated guesses and cut the problem space, but that isn't a true brute force.

You would be correct. Mine is "#1". I use compound english words whose meaning is non-sensical in a conversation but easy to remember.

Frequent password rotation causes increases of passwords on post-its stuck to the monitor.

In most cases I would take a strong password stuck to the monitor than a dictionary password on an internet exposed system.

But yeah, frequent password rotation is still bad.

Fair point. If your passwords are compromised because they were stuck to the monitor, that means physical security was breached and the copied passwords are now the least of your concerns.

Reply on news.ycombinator.com