From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BkDu1bbrZbx for ; Fri, 8 Mar 2013 03:28:38 +0100 (CET) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 8 Mar 2013 03:28:38 +0100 (CET) Received: by mail-qe0-f44.google.com with SMTP id x7so730743qeu.17 for ; Thu, 07 Mar 2013 18:28:37 -0800 (PST) Message-ID: <51394CD4.4050605@gmail.com> Date: Thu, 07 Mar 2013 21:28:36 -0500 From: Jeff Diehl MIME-Version: 1.0 References: <5138F84C.30401@gmail.com> <20130307211746.GA6183@tansi.org> In-Reply-To: <20130307211746.GA6183@tansi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] LUKS credential management at an enterprise level List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 3/7/2013 4:17 PM, Arno Wagner wrote: > In principle, any tool that can reasonably interface to > a commandline interface can do this, see the FAQ and > the man-page. > Thanks. I did note that this was an option. > On the other hand, password rotation is a dead-end, and makes the > problem worse, see e.g. > > http://www.schneier.com/blog/archives/2010/11/changing_passwo.html > http://transvasive.com/index.php?option=com_content&id=46 > > The basic problem is that password rotation prevents the use > of good, harder to remember passwords, while at the same > time it does noting to increase security. Once somebody halfway > competent has broken in, they will put in their own backdoor anyways. > In the few instances I am subject to this stupid measure, I have taken > to just attach the number of the month to the password. > I probably should have made clear early on that the machines I am interested in managing are not end-user machines. They are a set of "servers" in a data center. I am looking for "enterprise" features that would allow me to manage LUKS credentials for a group of machines (~50 boxen). These machines are not restarted with any frequency and the LUKS credentials are only ever needed by an authorized system administrator after a reboot. For various compliance reasons outside of my control, password rotation is required. In addition, I occasionally have a need to update/modify LUKS passwords for this group of machines on-demand (e.g. exiting an employee). Managing the machines individually is possible but cumbersome and before creating a "home-grown" solution, I wanted to see if there was something already available. > The one enterprise feature that is important is a recovery > password. For LUKS, this could be enforced either by policy, or > by an adjusted set-up tool. For example, you could mandate that > keyslot 8 always needs to contain a company recovery password > or that a long, random password has to be put into keyslot 8 > and then stored in a sealed envelope in a safe. > Thanks. We use a process very similar to this for recovery. -- JD