Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62963 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50979 invoked from network); 12 Sep 2012 20:56:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Sep 2012 20:56:09 -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.155 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.155 smtp155.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.155] ([67.192.241.155:33498] helo=smtp155.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/72-34511-8E6F0505 for ; Wed, 12 Sep 2012 16:56:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp32.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 285E650534; Wed, 12 Sep 2012 16:56:05 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp32.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 7F4F85053E; Wed, 12 Sep 2012 16:56:04 -0400 (EDT) Message-ID: <5050F6E3.70605@sugarcrm.com> Date: Wed, 12 Sep 2012 13:56:03 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Scott MacVicar CC: Anthony Ferrara , "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] Add simplified password hashing API From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > "The salt parameter, if provided, will be used in place of an > auto-generated salt." This is setting someone up for failure by > letting them put in something weak, you should be forced to get an > auto-generated salt. If this is for unit testing then it should be > explicitly stated. This assumes that we have the best salt generation algorithm that ever existed or could exist, and never would have any bugs or vulnerabilities in it. If it's not the case, it makes sense to let people provide their own salts in case they can generate better ones. > E_WARNING in a crypto function is also bad. Throw an exception or > fatal. There's no reason to just raise a warning and continue > execution, if something went wrong in crypto then its a bad time for > everyone. This means the function will be behaving differently than other PHP functions. Because it's crypto and very important, I understand. But then comes somebody else and says "my file functions are super-important too, whole application depends on them, why can't I have them work the same as crypto ones?", etc. Core should be consistent in its responses. Also, since the function returns false on failure, you can easily know something went wrong and throw exception/produce fatal error there if you wanted. Just like other functions - e.g. fopen() - do. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227