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>] [day] [month] [year] [list]
Date: Tue, 19 Feb 2013 10:23:07 +0000
From: Peter Gutmann <>
To: "" <>
Subject: Re: [PHC] Any "large verifiers" on the panel?

Jeremi Gosney <> 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.


Powered by blists - more mailing lists