On 31/07/12 18:21, Anthony Ferrara wrote:
> Jonathan,
>
> On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron
> <jbo...@openmv.com>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...).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
