Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61897 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81640 invoked from network); 31 Jul 2012 18:49:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Jul 2012 18:49:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=keisial@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=keisial@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender) X-PHP-List-Original-Sender: keisial@gmail.com X-Host-Fingerprint: 74.125.83.42 mail-ee0-f42.google.com Received: from [74.125.83.42] ([74.125.83.42:33135] helo=mail-ee0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1D/01-00342-4D828105 for ; Tue, 31 Jul 2012 14:49:57 -0400 Received: by eekb15 with SMTP id b15so1593283eek.29 for ; Tue, 31 Jul 2012 11:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aWsGmmJQQYzd9HATqwgzuKskO4M37XftKdg4iL2sRaQ=; b=scbGaTCT+cb3HlsmRFS7N+Iscmh2DGNQnFVKsoMUdvowQY2KTB2Up4t8GKsqs9CZvB cm8N6/rCSkISMi25GLeFqfB33EGaI5+SElF5lZR8//plYaFdMacs9GxEILcCTGSWxCUV luKn7StB/9ZQ6zJEZwzCzPtKhK/jPkWEpaLZri2axjKDTyyZOJe3Cpo40vubpKplZQV7 ccykide0W6SbXqTCUFRznshuFyXZb6m5gl8Ovhof9eViyJhlq9SzJI+7Hoh8/McqPqh0 UXbWhTFasBxSvGKIlPdKRZbQvnPyW4tNycecB0ghJwXqwS2nOADXY8y8yIuIgZzKcxIq +YhQ== Received: by 10.14.178.67 with SMTP id e43mr18911919eem.44.1343760594452; Tue, 31 Jul 2012 11:49:54 -0700 (PDT) Received: from [192.168.1.26] ([80.28.68.14]) by mx.google.com with ESMTPS id o47sm2573143eem.0.2012.07.31.11.49.52 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 11:49:53 -0700 (PDT) Message-ID: <50182812.6010603@gmail.com> Date: Tue, 31 Jul 2012 20:46:42 +0200 User-Agent: Thunderbird MIME-Version: 1.0 To: Anthony Ferrara CC: Jonathan Bond-Caron , internals@lists.php.net References: <4FFF1831.8070902@sugarcrm.com> <005101cd6f18$9da38510$d8ea8f30$@com> <009401cd6f28$b71c69c0$25553d40$@com> <00b701cd6f35$b2d621a0$188264e0$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PROPOSED] password_hash RFC - Implementing simplified password hashing functions From: keisial@gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) On 31/07/12 18:21, Anthony Ferrara wrote: > Jonathan, > > On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron wrote: >> Sure managing keys properly can be hard, simple cases: >> $secret = MY_KEY; >> $secret = file_get_contents('/security/key.pem'); >> > Actually, that's not properly managing the key. It requires the web server > user to be able to read the key. That allows anyone who gains permissions > as the web server (even on a different vhost) to be able to get your key. > > Properly managing it would require either a dedicated cryptography server > to handle it for you, or a dedicated piece of hardware to manage the key. > Anything less is just security through obscurity... If there are several vhosts in that server, they should run with different uids. Assuming the file is 600/400, that should be good. I don't think a crypto store would be much useful if once you become the web server you can decrypt everything. It would help in case of a read-only compromise of the full filesystem, such a leakage of the disk backups (but then, those backups would be incomplete, as you couldn't restore them in a different machine either, and your whole system relies on that piece of hardware not breaking...). I think a better method would be to use an external suid binary similar to unix_chkpwd which handles password_hash() and password_verify() for you. It could encrypt the hash with a secret before returning it to you, but as its password_verify interface would only return yes/no, breaking on the db wouldn't expose the passwords without also breaking into the uid that program is running as. If you want to get fancy, that program could lock itself if it detects it's being called with an higher frequency than the throttling the webserver should be applying (and thus is potentially compromised...).