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>] [day] [month] [year] [list]

Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340E2D0@uxcn10-2.UoA.auckland.ac.nz>
Date: Tue, 19 Feb 2013 10:23:07 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Any "large verifiers" on the panel?

Jeremi Gosney <epixoip@...dshell.nl> writes:

>We are not assuming a complete compromise (i.e., root access) here. We're
>merely assuming an attacker who is able to execute arbitrary code in the
>context of the web server or webapp.

We're not assuming that either.  What people are assuming is whatever level of
attack they need to in order to justify their design idea.  We don't really
have a set threat model.  More specifically, we have what I call the
Inside-Out Threat Model in my book, "The threat is whatever our solution can
defend against".  To that end, could I suggest as a starting point the
following three levels of attacker:

1. Read-only (file) access to the system.  Easiest to obtain.  Defeats poorly-
   stored authenticators.

2. Read/write (file) access to the system.  Somewhat harder than (1).  Defeats
   most mechanisms (add your credentials to the user database and you're in).

3. Anything else (memory read, code execution, etc).  Defeats pretty much
   anything, including HSMs.

We're defending against (1), and can defend against (2) if the credentials are
stored MAC'd/protected via a machine-specific secret so new credentials can't
be injected.  We can't defend against (3).

Alternatively, we could list the non-goals of the exercise, things that the
design is not expected to be able to do.

Peter.