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]
Message-ID: <CAMVss_pQ=yk4Q6HVHV3GONSdP-5t7eLGgxu5eH6Etbq00v+Q5A@mail.gmail.com>
Date: Tue, 25 Mar 2014 10:17:57 -0400
From: Justin Cappos <jcappos@....edu>
To: discussions@...sword-hashing.net
Cc: santiago torres <sat417@...dents.poly.edu>
Subject: Re: [PHC] New password hashing entry: PolyPassHash

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

Thanks,
Justin


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

>
>
> On 25 March 2014 13:47, Alexandre Anzala-Yamajako <anzalaya@...il.com>wrote:
>
>> Am i being dense or does this "meta technique" increases the load on the
>> attacker only if he doesn t also get the shares ?
>>
>>
> Justin has a pdf paper on the github link.  Part of his threat model is
> that the attacker cannot read arbitrary memory on the server.  He discusses
> what he proposes are advantages of the secret sharing scheme over storing a
> simple master secret in memory.
>
> Personally, while I think the idea is really rather novel, I'm not
> convinced the advantages over storing a single master secret in memory are
> particularly significant in most contexts.  It's hardly uncommon for a
> security team to manage a small list of "master" keys.  Having said that,
> the PHC is currently running because as a species we can't convince people
> to pick non-trivial passwords, so in that light the secret sharing scheme
> to store passwords may arguably be reasonable.
>
>
>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ