phc-discussions - Re: [PHC] cache timing attacks (Re: [PHC] Initial multiply-compute-hardened Catena-3 benchmark)

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: Fri, 24 Jan 2014 17:33:24 +0100 (CET)
From: Stefan.Lucks@...-weimar.de
To: discussions@...sword-hashing.net
Subject: Re: [PHC] cache timing attacks (Re: [PHC] Initial multiply-compute-hardened
 Catena-3 benchmark)

On Fri, 24 Jan 2014, Peter Maxwell wrote:

> Unless I've missed something important, surely that is only if the attacker has both the collection of hashes+salts *and*
> continuing access to the compromised host?  

Actually, the salts are sufficient, you don't even need to know the 
hashes.

And "continuing access" is a bit of a stretch. You need some temporary 
access for some measurements. It doesn't matter if you compromise the 
hashes before you have access to the host, or at the time when you have 
access to the host, or after you have access to the host.

> In that scenario, is it not likely that the attacker can also observe plaintext
> password attempts too?

Well, the whole point of a password hash is to provide a defense if the 
salt (and, actually, the password hash) has been compromised. Who, on 
earth, would need a slow and, maybe, memory-consuming password hash, 
otherwise? What would be the point of the entire PHC?

Actually, it is amazing that with the memory access pattern, you don't 
even need the password hash for this attack! In that sense, password hash 
functions with password dependent memory access patterns can turn things 
from bad to worse!

(This is probably not a big deal. Usually, I'd expect salt and password 
hash to be stored at the same place, so if either is compromised, the 
other one is compromised as well. On the other hand, the salt is a 
"random" value, and recent relevations regarding, e.g., the Dual-EC-RBG 
random generator are frightening ...)

In any case, the adversary just needs the salt and the ability "to rent a 
virtual machine sharing the same CPU as the defender" (quoting Marsh Ray).

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--