Comment by SAI_Peregrinus
2 days ago
Does anyone not add the year & month of the last password change to the end of their password? E.g. PascalCasePassphraseGoesHere2025-06, then at the next required change in (for example) 6 months: PascalCasePassphraseGoesHere2026-01. It almost certainly fits the inane "letter, number, and special character" requirements they probably have, complies with "different from your last X passwords", and is easy to keep track of the change interval. It also adds no security whatsoever! A user could almost certainly get away with Password2025-06, etc.
I once wrote a script to change my password randomly X times and then back to my original password. Worked like a charm.
There are policies to prevent changing the password more than once a day to prevent that. I've encountered it in several places
Fascinating. In other words:
In order to force the user to change their password more frequently (long term), the user is prevented from changing their password too frequently (short term).
I wonder whether the person who added that is actually confident that the benefits outweigh the drawbacks or is that a case of tunnel vision.
There are also systems that keep a history of old passwords just to prevent you from reusing one.
7 replies →
Password changed.
Password changed.
Password changed.
Error at : broken pipe
I’ve personally experienced the password change require that “more than X characters be different than the old password”
Um, that's a really bad sign...
No, you can do it safely. The idea is to have the password renewal process also ask for the previous password.
This means the password changing method doesn't need to store a plaintext password, but still has access to the old plaintext password when changing. It's still not a great idea, but that's because nagging your users will see them choose worse passwords.
1 reply →
To elaborate for the uninitiated, that means they are storing it in plaintext somewhere.
6 replies →
Not if the check is done client-side, so the plain password never leaves you local domain. Of course the check being done client-side means that it isn't difficult to skip if you are inclined to make a smidgin of effort.
1 reply →
I just let the keyring roll a completely new password. For some reason, all of my employers do require this insanity, but not on the one password I have to actually type.
I once had an employer that required us to use passworded SSH, and disallowed SSH keys, because they couldn't enforce that the SSH keys were passphrase protected, so just turned that option off.
They said it was a PCI requirement, or something.
PCI requires multi-factor auth these days, so you’ll likely find now the ssh password will be your password plus a OTP at the end.
6 replies →
This is not as illegitimate as it may sound to you. You may not hear about "getting someone's SSH keys" very often, because we only hear about "vulnerabilities" on places like HN and this isn't a "vulnerability" in any software.
But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems. It's one of the first things an attacker will check for, precisely because it's high likelihood they'll find one and high reward if they do. It's an extremely serious threat that you don't hear about very often, just like you may not hear about "the sudoers file left something open with passwordless access it shouldn't have and the attackers lifted themselves up to root from there" even though it's a major part of many actual incursions. I'm aware of multiple cases in which someone's passwordless SSH key played a part of the process.
So that really is a legitimate problem and turning them off is not security theater but can have a real impact on your security posture. The problem is solved nowadays with adding other auth to the process like proving possession of a physical token as part of the login process.
3 replies →
Whenever I don't have to type it, that's what I do. It's the login (or password manager password) needing this counterproductive crap that gets the "append a date" treatment. It's a 10-word diceware passphrase, only used for that login anyway, it's not getting breached if it's stored in even a remotely secure manner (even an unsalted hash would be safe).
They do it because their IT departments are checklist monkeys with no actual brainpower there, AND/OR they have cybersecurity insurers that mandate it who also have nobody with actual brainpower working there.