> > Message: 2 > Date: Sat, 08 Oct 2011 10:51:26 -0400 > From: Sean Dague <[email protected]> > To: [email protected] > Subject: Re: [mhvlug] File encryption > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/08/2011 09:59 AM, Kristoffer Walker wrote: >> Anyone know of a Unix-y kind of file encryption tool that will allow >> me to encrypt, store, and un-encrypt/read back a file? Preferably, it >> would be great if I could stream the un-encrypted data from the >> encrypted file into another program running in memory rather than >> write it to disk in an intermediary step. >> >> My use case is to store DB admin credentials on remote web servers, >> without writing them into application source code, storing them in the >> database, or writing them in config files. I could stream credentials >> to remote servers through an SSH session, but multiple admins need to >> have this capability, and I don't want to hand out secret credentials >> to a dozen people who need the capability to re-deploy or re-start the >> remote applications which need these secret credentials. If all >> credentials were stored in a remote file, we could just have 2 or 3 >> people from our inner circle of trust who would keep the key to that >> file, and make sure they are never on the same airplane together :-) >> >> For example, locally, on the GUI I really like KeePassX for this >> purpose. I've also looked into EncFS which mounts an encrypted volume, >> but that seems heavy handed, and I'm always afraid of leaving the >> encrypted volume mounted if my deployment script fails before >> un-mounting it. > > I think you could probably get what you are asking for out of gpg on the > command line. > > But any time I hear about shared secrets on remote machines, I get > twitchy, because shared secrets always get spread further than you > expect, and one breach, breaches all. Is there not a way to just bless > those user accounts with more privs? sudo can be quite granular, > including forcing only certain parameters to be used on certain > commands. Then if you have to oust someone, it's just about revoking > their account, vs. having to change the master password and securely get > it to everyone in the new ingroup. > > -Sean >
Thanks Sean; I hadn't thought of sudoers. Many of the secrets this web app needs are API keys and username/password combinations for RESTful services on the public Internet which could be written to or read by anyone with an internet connection. I'm restless about leaving the credentials to these services sitting on any machine in plain text. Maybe I can figure out some sort of combination of sudoers and gpg that will be good enough without creating "one key to rule them all". _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Oct 5 - Distributed & Centralized Authentication Systems Nov 2 - POV-Ray and The Relativity Train Dec 7 - Chef
