phc-discussions - Re: [PHC] New password hashing entry: PolyPassHash

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

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 <jcappos@....edu>
To: discussions@...sword-hashing.net
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...

Thanks,
Justin

On Tue, Mar 25, 2014 at 10:36 AM, Peter Maxwell <peter@...icient.co.uk>wrote:

>
>
>
> 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