4 ms·
Security. 90 day passwords, with multiple internal sites & servers each needing unique ones? I don't understand why we don't have automated client certificates
by Afforess 10y ago
Security.
90 day passwords, with multiple internal sites & servers each needing unique ones? I don't understand why we don't have automated client certificates and auto-generated ssh keys.
- Artemis2 10y agoAre you referring to one of these? https://github.com/Netflix/bless https://github.com/Netflix/bless http://gravitational.com/teleport http://gravitational.com/teleport https://www.scaleft.com https://www.scaleft.com We have actually developed such a service for internal usage (could not use any of these three because of compliance requirements), it works very well.
- fortyfivan 10y agoI'm from ScaleFT, thanks for the mention. I'd be curious to hear more about what specific compliance requirements we couldn't meet.
- herghost 10y agoThe 90 day password thing is pretty universal in my experience, but to be fair NIST has only very recently changed their recommendation on this so you can understand business' reticence to ease off on it. As for the multiple internal sites and servers thing...well, from a security point of view I totally agree with the requirement for separate passwords but it sounds like you're in need of a proper identity management solution - which isn't really fair to blame security for - it's not usually the security function who are going to implement and own this sort of thing.
- ajford 10y agoI'm SO glad NIST put out that new recommendation. I really hate the whole 90 day thing. Argued for days (friendly argument) with one of my co-workers who was partly responsible for our implementation of the 90 day rule on how it wasn't necessarily better, and often lead to stupid passwords with very dumb/simple patterns. Even with the new NIST rec, I can't get him to back off on it, so sadly we'll be stuck on that for a while.
- user5994461 10y agoIt's only a DRAFT at the moment. It may take a while to be finished.
- herghost 10y agoMaybe 8-10 years ago there was a solution (an AD add-on/schema) I was looking at which set a password change frequency dependent on the password complexity - so a shitty 8 char, lowercase password would be acceptable but might be forced to change every 5 days. Drop a number and something uppercase in there and you might get 15/20 days. Drop a proper password and you might get 90-180 days. I really wish that had taken off (or, more accurately I guess, had a real business case). As an industry we tout one set of rules/principles but then enforce a slightly different version. My main passwords (the ones I have to remember, and not store) are all over 20 characters long and maximally complex and I change them very, very rarely.
- kgilpin 10y agoRotation is a really interesting subject which has true security benefits. Unfortunately manual rotation is a PITA. What works better is to have an automated system rotating the credentials, and then you fetch the credentials as-needed by authenticating with an identity and access management system. For example, in Conjur there is a suite of rotators (https://developer.conjur.net/reference/services/rotation https://developer.conjur.net/reference/services/rotation) for rotating things like SSH keys, database passwords, and cloud credentials. In each case, the rotator changes the credential in the backend (e.g. changes the public key in the authorized_keys file), and then stores the new credential behind an access-controlled and audited API where only you (and other authorized roles) can fetch it. Disclosure: I am CTO of Conjur.
- Corrado 10y agoA bit off topic, but the conjur.net domain seems to be a bit broken. https://conjur.net https://conjur.net doesn't work properly and it threw an SSL/TLS certificate error the first time I visited. Also, it appears as if your main site doesn't redirect to HTTPS. As a security company my first thought is that if you can't handle these simple things I'm not sure I'm ready to talk to you about more complex matters.