phc-discussions - Re: [PHC] Any "large verifiers" on the panel?

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: <878v6lidbz.fsf@wolfjaw.dfranke.us>
Date: Mon, 18 Feb 2013 15:20:16 -0500
From: Daniel Franke <dfoxfranke@...il.com>
To: Jeremi Gosney <epixoip@...dshell.nl>
Cc: discussions@...sword-hashing.net
Subject: Re: [PHC] Any "large verifiers" on the panel?

Jeremi Gosney <epixoip@...dshell.nl> writes:
> On 2/17/2013 8:24 PM, Daniel Franke wrote:
>> If the attacker can obtain a shell under the same uid as the webapp
>> process and go undetected for a while, then he can ptrace the webapp and
>> see the passwords as they're being passed into the hashing function.
>
> It does not work this way anymore. At least not on modern Linux
> distributions that enable the Yama LSM, which I'm pretty sure all
> distributers started doing ~ 3 years back.

No version of vanilla Debian enables YAMA. Precise, which is less than a
year old, was the first Ubuntu LTS release to do so. I have no idea
about any of the RedHat derivatives.

My personal opinion is that ptrace restriction is a good feature to have
available, but a bad one to turn on by default, because it breaks things
that POSIX says should work. It's basically useless on desktop systems,
and having it enabled on mine would annoy the hell out of me, because
attaching gdb to a running process that's misbehaving is something I do
quite regularly.

In reply to your IRC comments:

> 03:10 <@epixoip> i think all this talk about using reversible encryption and shared secrets is just plain silly, though
> 03:10 <@epixoip> surely one can come up with a solid algorithm that doesn't rely on the user keeping secrets a secret, because that just won't happen

I am not making any argument at this point, about whether symmetric
secrets, trapdoor functions, etc. are useful or not.  I have no ideas in
mind for any scheme that incorporates them, but neither am I committed
to any threat model in which I can prove that no such scheme exists. My
thesis at this stage is simply that deciding on an appropriate threat
model, and justifying that decision through something better than
"inside-out" reasoning (thank you, Peter -- I'm going to be using that
term regularly from now on), should be a goal of this competition.