From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v1.tansi.org (mail.tansi.org [84.19.178.47]) by mail.server123.net (Postfix) with ESMTP for ; Thu, 27 Oct 2016 09:55:37 +0200 (CEST) Received: from gatewagner.dyndns.org (77-56-144-126.dclient.hispeed.ch [77.56.144.126]) by v1.tansi.org (Postfix) with ESMTPA id 483C7140060 for ; Thu, 27 Oct 2016 09:55:35 +0200 (CEST) Date: Thu, 27 Oct 2016 09:55:35 +0200 From: Arno Wagner Message-ID: <20161027075535.GA4754@tansi.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] pashphrase management question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Thu, Oct 27, 2016 at 01:17:42 CEST, Robert Nichols wrote: > On 10/26/2016 11:43 AM, ClEmFoster wrote: > >hello, > > > >The setup: > > > >I work in an environment that has a whole disk encryption requirement for > >VMs. If the VM is restarted an admin has to hit the console and type in > >the passphrase to boot. This is OK, we don't reboot much, and security > >guys are happy. The problem is they are going to start requiring that > >these machines also receive a passphrase change every 3 or 6 months. That > >brings me to the question. > > Are "they" aware that anyone who has had read access to the device > with the LUKS container has had an opportunity to copy the LUKS > header, and can always use that LUKS header with the old passphrase > to unlock the container (perhaps after spending however much time > and processing power is needed to crack that passphrase offline). > > For that matter, anyone with root access to the VM while the LUKS > container is unlocked can easily obtain the master key > (dmsetup table --showkeys /dev/{whatever}) and can always access > the LUKS container with that. > > Changing the passphrase doesn't protect against any of that. This is probably just the usual "cargo-cult" security, i.e. follow the ritual (a.k.a. "Process") without question, because that would require understanding. Regular passphrase changes on storage-encryption make absolutely no sense and gives you absolutely no protection benefit (unless you have told somebody that should not know, in which case you need to change them immediately). I would try to give "them" a definition of the LUKS passphrase that does not make it a "password" or "login credential", and with a bit of luck you can negate thereby prevent the usuall "password" process and its requirements from applying. One approach would be to make this a "technical secret" or the like. After all, they probably to not require, say, passphrases protecting certificates to be changed regularly, because that would be relatively difficult. Regards, Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier