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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Mar 2014 14:36:05 +0000
From: Peter Maxwell <>
To: "" <>
Subject: Re: [PHC] New password hashing entry: PolyPassHash

On 25 March 2014 14:17, Justin Cappos <> 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