On 2012 Jun 25, at 05:00 , Trey Darley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, y'all - > > Do auditors ever ask you how you manage privileged access for generic shared > accounts (root, Windows Domain Admin, etc)? If the answer is "yes", read on. > > I made a tool that solves the "root password in an envelope in a safe" > problem. It's called credmgr. It's still a bit rough around the edges but it > works nicely. > > credmgr [0]: > > - generates a random password in memory (of configurable length and > complexity) > > - generates hashes (salted, of course!) from that cleartext password (still > in memory) in any hash format passlib supports, including BCrypt, PBKDF2, > and SHA-512 - plus many [1] more. > > - shards the cleartext using shamir sharing [2] so that the cleartext is > recoverable by joining back together a configurable fraction of the shards > > - emails these shards to their respective shard-holders (encrypted to the > shard-holder's individual gpg pubkey) along with contact details for the > other shard holders and instructions for how to reassemble the cleartext > > - outputs all the requested password hash formats for deployment > > I looked around and didn't see another tool like this but Murphy's Law says > I've just tried to build a better mousetrap. Anyway, I thought some of y'all > could use such a thing. Curious to hear feedback...
I do audit response, trying to guess what the auditors will demand as a big part of my job today, so please don't take this personally, more as identifying areas auditors may need addressed. You need to ensure you are maintaining at least four old passwords. Password changes may not be done for one reason or another when a new one is issued. Nothing is worse than a root password management system that you can't use to get the root password. What guarantee do you have that the hashes are actually deployed rather than just leaving the root password on some insecure value? Even if it is just a "Yes, I updated the root password and validated it" signoff for each system with a person's name who did the work, something would need to be in place to ensure it is the actual password. Password age will be key. There should be some framework (either political or software) to ensure the password never actually gets beyond the maximum age as defined by your organization. What about people leaving the organization? The obvious answer with your software is in such an event, issue a new password, but it is something that needs to be kept in mind. Password change events aren't just the fixed schedule of age. An auditor will likely have a hard time with even encrypted email. It's a reflex thing. If you use this with the intention of presenting to an auditor, have an answer ready. Outside your software, but be sure you have clearly defined properties on who has access to that password. You could manage it from the encryption keys, but have something to say that yes, this person is authorized. Written before first cup of tea, so take this for mainly worth the electrons allocated to send and display this. ---- "The speed of communications is wondrous to behold. It is also true that speed can multiply the distribution of information that we know to be untrue." Edward R Murrow (1964) Mark McCullough [email protected] _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
