A bit of a homebrew idea but you could use extlookup in puppet (I am sure there is an equivalent way to do this in chef) to get the hash from a somewhere and the password itself is stored in a locker of some sort. Once the password has been access via the locker there is a "fuse" and when the fuse expires, it changes the hash that is delivered via puppet. With a backup mechanism storing an encrypted bundle somewhere offsite and the key in a safe.
-- cwebber On Nov 1, 2011, at 19:11, "Mathew Snyder" <[email protected]> wrote: > "One use" is probably misleading. We have a requirement by our > contracting agency to expire ALL passwords every 60 days. This > includes service/application accounts and root. We are still working > out how to do this, but it seems that we have found a reasonable > compromise that is more commonly used (at least for root access). That > is to simply change the root password once it has been accessed in > whatever method it is stored (printed on paper and stored in a safe or > an app similar to KeePass, for example). > > We do not allow root login remotely (SSH is our only enabled remote > method). root can only log in via the console. Should anyone try to > simply su to root, its password is required. sudo is not configured > for the target accounts password so each user's password is used for > that. > > Ideally, I would like something that enforces changing the password > once it's been accessed rather than simply marking it as used and an > entirely new entry be made which is what KeePass does with its TANs. > > Individual user accounts are configured to expire using chage which > meets that requirement in a simple manner. However, as we also have no > need to access root directly except in the case of emergency, using > chage sets an unnecessary requirement to log in regularly to every > server just to change the password every 60 days. Hence, the desire > for what I can't think of any other way to describe except as "one > use". > > I'll take a look at that serverfault question first. Thanks, Matt. As > for the two-factor options, while we are required to have one in place > for certain things such as VPN access, we aren't required to have it > for server access and it would simply be too much overhead to deal > with on our little team. Thanks for the suggestion, though. > > -Mathew > > "When you do things right, people won't be sure you've done anything > at all." - God; Futurama > > > > On Tue, Nov 1, 2011 at 9:42 PM, Edward Ned Harvey <[email protected]> > wrote: >>> From: [email protected] [mailto:[email protected]] >>> On Behalf Of Mathew Snyder >>> >>> I'm trying to find a suitable password management application. The >>> primary need is to allow for one-use passwords for root. I installed >> >> How does one implement single-use passwords? There must be some kind of >> application you installed that regularly changes the root pass or something. >> They must have some way of securely communicating to some strictly >> authorized users what their one-time-use password will be this time. How >> does the solution not avail itself naturally through this process? >> >> > _______________________________________________ > Tech mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
