Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60815 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26826 invoked from network); 13 Jun 2012 22:34:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jun 2012 22:34:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.133 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.133 smtp133.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.133] ([67.192.241.133:33592] helo=smtp133.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0D/C7-08889-66519DF4 for ; Wed, 13 Jun 2012 18:34:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp23.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 399832F8393; Wed, 13 Jun 2012 18:34:12 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp23.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 0211B2F82BA; Wed, 13 Jun 2012 18:34:11 -0400 (EDT) Message-ID: <4FD91563.4060908@sugarcrm.com> Date: Wed, 13 Jun 2012 15:34:11 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikita Popov CC: PHP internals References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Adding a simple API for secure password hashing? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > So, wouldn't it be better if PHP provided an easy to use API for > secure password hashes natively? So you just have to call a single > function, which magically handles everything for you (like salt > generation). Yes. The fact that crypt() doesn't allow to generate salt automatically for non-default algorithms leads to people either defaulting to weaker md5crypt or doing salt generation manually, which is dangerous. So I think we need two things here: 1. An RFC for generic password hashing function (probably in hash, but can be standalone too) improving on crypt()). The start with pbkdf2 looks good, but if we could intergate all possible ways it'd be nicer. 2. A patch (and RFC if necessary) for crypt() to allow it to generate salts for non-default algorithms. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227