| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CA+aY-u7hV6C88fCeZWuPVBij3OhPo+kWeZGC1xg4G65F9Knfsg@mail.gmail.com>
Date: Tue, 25 Mar 2014 14:36:05 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] New password hashing entry: PolyPassHash
On 25 March 2014 14:17, Justin Cappos <jcappos@....edu> wrote:
> The issue is where does the security team / admins store the key between
> reboots? If it is on disk, then an attacker can trivially find and use
> it. (Several surveys of password breaches have shown that attackers
> usually obtain password databases through attacks where they do not have
> root access on a live machine.)
>
>
In a previous incarnation, we solved the problem by setting up some custom
software akin to keepass/passwordsafe on a secure server that was only
accessible to the security team (if an attacker gained access to that
machine, we'd have bigger problems than a compromised password database).
There were only about a dozen passwords/keys needing stored and it worked
fine. Worst comes to the worst, a notepad and pen will often suffice :-)
(and has the distinct advantage that it canny be compromised remotely)
So in your threat model: on reboot, a member of the security team/SoC would
retrieve the master key from their password store then use it to setup the
password server.
The two models are security equivalent: if memory on the password server is
compromised in either your example or in the situation of storing a simple
master key, the consequences are the same.
Content of type "text/html" skipped
Powered by blists - more mailing lists