Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75736 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23300 invoked from network); 21 Jul 2014 05:53:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jul 2014 05:53:50 -0000 Authentication-Results: pb1.pair.com header.from=davidkmuir@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=davidkmuir@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.181 as permitted sender) X-PHP-List-Original-Sender: davidkmuir@gmail.com X-Host-Fingerprint: 209.85.192.181 mail-pd0-f181.google.com Received: from [209.85.192.181] ([209.85.192.181:60903] helo=mail-pd0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 71/EA-48607-DEAACC35 for ; Mon, 21 Jul 2014 01:53:49 -0400 Received: by mail-pd0-f181.google.com with SMTP id g10so7086194pdj.12 for ; Sun, 20 Jul 2014 22:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=YwcoiUc0E18JfuNwm5X0w7sfI/b+ZeNWCiIvDjUQi0U=; b=0QZHTCUj9XPl0tmQDQX807lnHLRogW3dhV3as+RBP/D2aQVWg2hzWv6dZwTcq9MGrZ sxQiyuvfAxJZdVIjynAyFFppIRbiJdDH+MOMfAhaD+43uqekL7VLbgXhQ3eqo3pU6h9l bhdenSvv03Ss17j4/PjNYlPj9i6Y+4uB2vWbMDae7kr1xfXp7L0POVQrSBvfodE/E0of aX9oj/nvWko3dxdBqTQmBz1/e/OF6AmpZTNBuVgJYvKehOtdqmZfI0xrtBE5/Doryw0b ZCzWMK8D+ANlO7TS5rbNj367Ti5m0GugvowPaf3UwuSG0ARQIwFk4Z1ddf2ytefovkqY UETA== X-Received: by 10.67.12.171 with SMTP id er11mr1087910pad.132.1405922025954; Sun, 20 Jul 2014 22:53:45 -0700 (PDT) Received: from [192.168.1.25] (tmwpho1.lnk.telstra.net. [110.142.207.74]) by mx.google.com with ESMTPSA id ds6sm17527737pdb.57.2014.07.20.22.53.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 22:53:44 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: Cc: Anthony Ferrara , Adam Harvey , Tjerk Meesters , Sara Golemon , "internals@lists.php.net" X-Mailer: iPhone Mail (10B500) Date: Mon, 21 Jul 2014 15:53:34 +1000 To: Yasuo Ohgaki Subject: Re: [PHP-DEV] crypt() BC issue From: davidkmuir@gmail.com (David Muir) On 21/07/2014, at 10:04 AM, Yasuo Ohgaki wrote: > Hi Anthony, >=20 > I want to finish and close this issue. >=20 > On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki wrote: >=20 >> Also, Deprecating crypt() without first discussing it (and having an >>> RFC to vote on) is not cool (and has been reverted): >>>=20 >>> http://svn.php.net/viewvc/phpdoc/en/trunk/reference/strings/functions/cr= ypt.xml?r1=3D333973&r2=3D334296 > I wrote >=20 > "Use of crypt is deprecated." >=20 > not >=20 > "crypt() is deprecated". I didn't mean crypt() function deprecation. If > it's confusing, I don't mind at all to rewrite it. > BTW, what part is wrong? >=20 > It seems we have misunderstanding each other, but the basis is the same, I= > suppose. >=20 > - crypt() will remain > - User/developer should use password_*() > - It's not good idea to have PHP own crypt() >=20 > The differences are E_NOTICE and workaround, it seems. > IMO, password_hash() must raise E_NOTICE for too long password. Truncation= > without error is > not an option for me. People write stupid code without internal knowledge.= > Adding fixed salt was > common since crypt() was not good enough used to be. In addition, maximum > password length > is not decided by us, but decided by app developers. Therefore, we are > better to provide/explain > workaround for password_hash() limitation. >=20 > Prehash in PHP is not an option as we don't want PHP only crypt(). Prehash= > by developer is > acceptable workaround for me. As you know, chars that are used in password= > is limited. Some > developers even allow UTF-8 for password, structured encoding could reduce= > total number of bits > in password hash with limited password length. Prehash with raw SHA512 wil= l > give us adequate > data for PASSWORD_BCRYPT hashing regardless of password length. >=20 > Prehash ruins password_*() flexibility for sure, but there is workaround > also. Developer may use > timestamp to check new hash (e.g. 1024 bits hash, etc) should be used or > not. >=20 > If we don't want such workarounds, we may enable SHA512 hash for > password_hash() for those > who don't want password length limit. >=20 > Regards, >=20 > -- > Yasuo Ohgaki > yohgaki@ohgaki.net Yasuo,=20 Prehashing with sha512 means it is no longer blowfish. It is now a non-vette= d DIY algorithm. The whole point of password_hash is to avoid this type of t= hing, and should be clearly discouraged in the documentation. It's a classic example of what not to do. David=