News for hackers. Stuff that matters.
Re:Practical Linux Hardening Guide by torvolt on Thursday January 24, 2019 @07:16PM (#18994380)
I always felt like increasing security has some cost on convenience.
Re:Practical Linux Hardening Guide by fyjvd90 on Thursday January 24, 2019 @07:39PM (#18994471)
It does, but there’s also what I call stupid security that doesn’t really add any measurable improvement, but does decrease productivity. Users out smart these systems all the time (e.g. forced password changes where you can’t use the last 10 passwords, users just change their password 11 times so they can continue to use a password that’s been configured on their devices. It’s stupid then to force changes like that when there are much better ways like mfa)

Smart security allows users to do what they need to do efficiently and safely.

Re:Practical Linux Hardening Guide by llama052 on Thursday January 24, 2019 @07:44PM (#18994501)
Yeah I can't stand the forced password changes where you can't use the last X passwords, or passwords that expire every 30 days. A lot of times it's security compliance entities that push this down to companies, for instance PCI, etc all require those. I think even the new NIST standards address these practices, but the compliance entities are slow and far from pragmatic.
Re:Practical Linux Hardening Guide by mises on Thursday January 24, 2019 @07:54PM (#18994560)
Yep. I can tell you that currently, leading practice involves such measures. I don't agree, but CIS, which is essentially the current gold standard, says so. People who get paid to do this often don't bother griping about it, because they are being paid to harden to a standard and that standard is what it is.

This unfortunately leaves a disconnect between the people who harden (who might actually hear about issues), and the people who write. Even if the writers do hear, it won't be implemented until the next revision.

Re:Practical Linux Hardening Guide by fyjvd90 on Thursday January 24, 2019 @10:34PM (#18995338)
Yeah PCI or FedRAMP have this 10 char password requirement, which of course no one can remember a 10 char password. So companies just make the password a pattern with some variations, effectively reducing the complexity to a tenth of a random 8 char password and the people who know the pattern leave the company so it’s effectively public. So much for math.
Re:Practical Linux Hardening Guide by techslave on Thursday January 24, 2019 @08:05PM (#18994621)
yes but the rule does enhance security.

the password rules force you to choose [heuristically] guessable passwords, therefore they must be changed every 90 days. simple!

Re:Practical Linux Hardening Guide by xorgar831 on Thursday January 24, 2019 @11:22PM (#18995541)
It doesn't if users are working around it.
Re:Practical Linux Hardening Guide by cwyers on Thursday January 24, 2019 @11:34PM (#18995586)
Right. The first rule of password security: if you have a large enough user base, the odds of a user writing down a password increase, and as passwords become sufficiently difficult to remember, the odds approach 100% at some point that _some_ people are writing down passwords. No amount of defense in depth can protect the "I have a Post-It note under my keyboard" problem, if people can get into your building.
Re:Practical Linux Hardening Guide by shaftoe on Friday January 25, 2019 @05:29AM (#18996922)
We've handled this by mandating password manager use and pushing length requirements to absurd levels to where it truly is easier to just use the manager, which has two factor.
Re:Practical Linux Hardening Guide by bigiain on Thursday January 24, 2019 @09:02PM (#18994919)
Often, but not always.

ssh keys instead of passwords are a good example of better security and more convenience (for the most common use cases).

It'd be nice if more "security improvements" came with ways to make them convenience improvements too...

Re:Practical Linux Hardening Guide by gerdesj on Thursday January 24, 2019 @09:08PM (#18994948)
Absolutely, but I prefer not to leave 22/tcp open to the world. If I do leave it open it is only from a restricted IP set, otherwise it is behind a VPN, probably OpenVPN.
Re:Practical Linux Hardening Guide by closeparen on Thursday January 24, 2019 @11:15PM (#18995520)
Is OpenVPN a safer attack surface compared to OpenSSH?
Re:Practical Linux Hardening Guide by romeisendcoming on Monday January 28, 2019 @01:16PM (#19019675)
Sure, especially when you VPN into a sacrificial subnet and need MFA to continue elsewhere into locked down application domains. OTOH I would leave ssh listening on a non-descript high port with MFA (key and OTP) enabled. No use worrying too much about that.
Re:Practical Linux Hardening Guide by amdavidson on Friday January 25, 2019 @03:31PM (#19002209)
Is OpenSSH safer when used in addition to OpenVPN?

Probably.

Re:Practical Linux Hardening Guide by aaronmdjones on Friday January 25, 2019 @10:27AM (#18998727)
I doubt it.
Re:Practical Linux Hardening Guide by dragonwriter on Thursday January 24, 2019 @07:52PM (#18994547)
Usability is a component of security because of human factors; if your “secure” process or system is not convenient for use, people will in practice find ways to work around it instead of using it as intended, which will defeat security.
Re:Practical Linux Hardening Guide by geofft on Thursday January 24, 2019 @07:35PM (#18994458)
It shifts convenience. It's less convenient for me to have to unlock my door when I get home, but it's more convenient to not carry all my valuables with me during the day. And I really like that tradeoff.

Good security measures are like this. Add sandboxes so you can let users do what they want. Add authentication so people know who they're talking to. Support security keys so people don't have to worry ad much about being phished. And so forth.