471–480 of 539 posts
> Consider enforcing automatic screen lock when you walk away The corpo "security" dingbats force this on our work machines via profiles -- can't control how long before the screen locks. Thank goodness for the Amphetamine app. I'm not typing in my password every time I stop to think for two minutes, you can fuck all the way off with that.
The people who need to read these articles are the auditors. Until they change their expectations, the many businesses who have to pass audits are still going to be stuck doing a lot of things that are industry-standard but also very stupid. This is the case even for small businesses in certain fields where security audits are valued. We have at least half a dozen measures in place that we know aren't actually helpfu…
I've been pushing NIST on SOC2 auditors for years. They always accept it once given a link.
Saying "The United States of America National Institute of Standards and Technology says X on page 423 of Special Publication 800-53 revision 5" is a really awesome "We're doing things the RIGHT way".
Earlier quoted context omitted.
There are also systems that keep a history of old passwords just to prevent you from reusing one.
I like the ones that not only keep a history of your old passwords but will reject any password that is similar to any of your 30 previous passwords, which means they're storing either a plaintext or reversibly encrypted list of every password somewhere on the system. Talk about a goldmine for the hacker that dumps that database.
Earlier quoted context omitted.
I belonged to an organization that had password complexity requirements. That's normal and understandable. However one requirement was that no part of my password could contain a three character subsstring that was included in my full name. I won't give my real name here, but sadly it includes some three letter subsequences that are somewhat common in many English words. I can understand a policy that prevents someon…
> Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken. I wonder if some of these constraints are to try to find a way not to pay out on the policy.
To bastardize Douglas Adams: For-profit insurance is a scam; breach insurance, doubly-so.
Earlier quoted context omitted.
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.
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…
Though, if someone gets that far, couldn't they also install a key logger on the users system? At that point - whether it's just password or a password enabled SSH key, anything the user does is all compromised regardless.
Earlier quoted context omitted.
> If the password length is 12 to 15 characters, it will be valid for 180 days > If the password length is 16 to 32 characters, it will be valid for 365 days Madness.
I'm a big fan of "should not include profanity, words of a vulgar nature". It's not unthinkable my password manager comes up with a chain of letters that at one point will include "fuck".
IMHO there are only 2 requirements for a good password: 1. It must be close to impossible for a computer to guess. 2. It must be easy for a human to remember. Virtually all password policies focus exclusively on point #1, with the vast majority just giving cargo cult instructions without really understanding the state of the art. Almost nobody puts any emphasis on point #2, which is arguably more important as it is t…
Earlier quoted context omitted.
There are also systems that keep a history of old passwords just to prevent you from reusing one.
I like the ones that not only keep a history of your old passwords but will reject any password that is similar to any of your 30 previous passwords, which means they're storing either a plaintext or reversibly encrypted list of every password somewhere on the system. Talk about a goldmine for the hacker that dumps that database.
Earlier quoted context omitted.
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…
> 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. Though, if someone gets that far, couldn't they also install a key logger on the users system? At that point - whether it's just password or a password enabled SSH key, anything the user does is all compromised regardless.
There are a ton of situations where that is not the case. They may be using directory traversal from something else to read a key without even necessarily being on the system. They may be on the system at 1am local time, and want to get in and get their job done before the user is even there. They may be on a server somewhere where someone left a key they shouldn't have. The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held. They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger, depending on how the system is set up and how the user accesses it. These are examples and not even remotely a full enumeration of all the possibilities. I won't tell you which ones, but some of these are things I've personally seen attackers take advantage of, so they're not just theory, either.
When you're under personal attack, not just getting popped by some vuln scanner scanning over the entire Internet, the situation becomes very different than a lot of people here on HN are used to. Ever been locked out of a system accidentally, then thought for a moment and strung together three other things to reach back into the system you were locked out of, like "oh yeah, I can push a software update to this automatic deployment system, which will run a bash script that checks the IP address and if it is this system restarts the ssh server, and so after 10 minutes we should be in"? Imagine someone who does that every day, all the time, as their full time job, and then imagine they're on a team of other people who also do it every day as their full time job, then imagine they've gotten a foothold into your system. Which, by the way, they immediately used to put a command-and-control client on your system, loaded with all kinds of exploits, and the ability to push arbitrary code to any number of systems at a time and all the tooling to use that as if they've been developing it for 20 years, which they have. What's the transitive closure of what they could work out how to access? The answer would probably surprise you.
Earlier quoted context omitted.
I like the ones that not only keep a history of your old passwords but will reject any password that is similar to any of your 30 previous passwords, which means they're storing either a plaintext or reversibly encrypted list of every password somewhere on the system. Talk about a goldmine for the hacker that dumps that database.
Something like that could probably be implemented by storing multiple hash of some automatically modified version of the password. For example, if your password is "PassWorD" they can additionally store the hash of the lowercase version of the password. So if you change it from "PassWorD" to "paSswOrd", they will see it has the same lowercase hash than the previous one without knowing it.