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 11:28:50 -0400
From: Justin Cappos <>
Subject: Re: [PHC] New password hashing entry: PolyPassHash

Okay, but if you can secure this separate secure system, why not just store
the password database there and have a well defined interface for asking
auth questions (like systems such as HoneyWords argue for)?

I get the notepad / pen argument from a security standpoint.  Of course,
you have to change this password anytime someone leaves, etc.  I guess
whether this is a concern depends on your environment.   You also need to
wait for someone to enter the password / key to be able to use a new system
upon restart.

I agree that either way if an attacker can read memory on a running server,
they can read what is essentially a hashed and salted password database.
Of course they can also read plain-text passwords as they are entered (for
most auth systems).

I don't think that anyone would disagree that having an offline / uber
secure mechanism for storing some private data that is used to encrypt
password hash databases is a big win.   The admin / security team could go
and access a separate server, copy over a key / password, change them
diligently as people come and go, etc.   However, from a usability
standpoint, it seems to be something that organizations often are found not
to do in practice.

Instead of doing all of this, they could just do "apt-get install
polypasshash" and then worry about other things...


On Tue, Mar 25, 2014 at 10:36 AM, Peter Maxwell <>wrote:

> 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