Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75856 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3755 invoked from network); 22 Jul 2014 14:27:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jul 2014 14:27:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.182 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.220.182 mail-vc0-f182.google.com Received: from [209.85.220.182] ([209.85.220.182:39139] helo=mail-vc0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/83-21666-1D47EC35 for ; Tue, 22 Jul 2014 10:27:29 -0400 Received: by mail-vc0-f182.google.com with SMTP id hy4so15480037vcb.27 for ; Tue, 22 Jul 2014 07:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTAkJ+tp2jQZOIKggvZqVSovDT0a3H7tacrbBbOQQto=; b=C9mEOQCAbOyYLVtVOGhHQVieAxey1nJ8GqrLozXy88HB4euZHbUVxzfSgfqIBSAzqn bEfROlsy2FaPCCvow8F01gphPV8vbyFmRgQEkIDx9au5oNNngN1CLK2zSoi76YGww1Gk updxoINyjskd9y9y8ED+1XWgrjJqf5J75+/W9XCg4UFBArZi0HY8/1p7J5QQXITOiZCk C0AEgh8S6SUcciEQocI7Tc7f0L0XYQO5pUFqo3KFimseuuqPEdjiXCy8bQC2+39SD3Nk pYjciIV8tZQBANIkYMiqEZMXJyC1CxGBMIO6MBimDYenBbnPrC11T2GtzToP0oXuqiwo t6iA== MIME-Version: 1.0 X-Received: by 10.52.25.228 with SMTP id f4mr19213360vdg.62.1406039245334; Tue, 22 Jul 2014 07:27:25 -0700 (PDT) Received: by 10.58.45.137 with HTTP; Tue, 22 Jul 2014 07:27:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 10:27:25 -0400 Message-ID: To: Yasuo Ohgaki Cc: David Muir , Adam Harvey , Tjerk Meesters , Sara Golemon , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] crypt() BC issue From: ircmaxell@gmail.com (Anthony Ferrara) Yasuo, > However, I don't mind at all to write RFC raising E_NOTICE for > password_hash() > with PASSWORD_BCRYPT. Awesome, thanks! > Although cryptgraphic hash functions are supposed work cryptgraphic way, but > many of them are failing. This was in real world and I aware of the risk. It's less about being aware of the risk, and more showing that the example you cited of combining hash functions (to show that's it's OK to do) was actually changed to stop doing that because it's known to be insecure. So if anything, by citing that example you're actually demonstrating what shouldn't be done, rather than giving an example of "it's ok to do in the real world". > I agree with your discussion and have no objection. I understand that it's > correct in > theory and real world. > > Even if I understand the risk, it's acceptable for me to use SHA512 to > workaround > password length limit as long as SHA512 and/or blowfish is considered safe > by > specialists. As I wrote, password length limit is decided by app developers > and we > are not the app developer. > > (BTW, I do code audit/web security check/education for living, but I'm not a > cryptographer) For your code, that's fine. For you **personally** to advocate for it, that's fine. Write blog posts, answer stack-overflow questions, etc, that's absolutely fine! To have a programming language and associated community (which is seen as a significant authority) to advocate for it is not. To document it in an official manner in an official context (PHP's documentation), "understanding the risk" isn't good enough. We shouldn't be recommending anything that "probably is fine", instead we should be documenting known good method. Methods that have proofs. >> And a E_NOTICE will prevent nothing. If you *really* want to prevent >> it, raise a warning and return false from the hash function. But >> that's not possible without a MASSIVE BC break. Hence why I'm >> recommending that you open an RFC on it. > > > I'll strongly object returning FALSE for faulty usage. IMHO, it is as bad as > using too long > prefix for PASSWORD_BCRYPT. It could disable authentication completely. And that's why this discussion needs to happen. A notice isn't going to change anything. A significant number of developers turn them off. Especially in production (which is where long passwords are likely to occur). It may help a few people, but the majority it wouldn't. And it would make some people start calling `@password_hash()` to suppress the notice (because why bother fixing bugs, when we can ignore them!). Which is **really** bad. If you truly want to prevent people doing silly things like password_hash(SHA512($secret) . $password), then returning false and raising a warning is the only way that will actually do so. How to do so is tricky, as it's a pretty significant BC break, and will break some running software. But it would prevent the issue that you've stated you want to prevent. So that leaves 2 practical options (IMHO): 1. Document the behavior, and don't change code functionality. 2. Add warning, returning false on overlong password (with documentation). I don't like 2 (for a similar reason as you), so that leaves 1. Which is where we are today, so nothing left to do. > >> > If we would like to recommend "Just use it", we may consider adding >> > SHA512 >> > to password_hash(). >> >> As I pointed out above, no. > > I'm lost here. Are you going to discuss use of SHA512 for password hashing > is > insecure? Blowfish is suitable for password hashing because of its > "slowness". > Isn't it matter of rounds? I assumed that you meant bcrypt(sha512(password)). If you mean crypt-sha512 (aka $6$), why would we want to add a demonstrably less secure algorithm? If anything, I'd add PBKDF2-SHA512, but considering there are no public crypt bindings to PBKDF2 (aka a crypt format), I'm **really** hesitant to do that. Yes, Python has one (a crypt format): https://www.dlitz.net/software/python-pbkdf2/ Yes, PERL has one: http://search.cpan.org/~arodland/Crypt-PBKDF2-0.101170/lib/Crypt/PBKDF2.pm Yes, Ruby has one: https://github.com/nomoon/pbkdf2-crypt But note none of those are in core distributions. And all of them are different (incompatible with one another). > We need 72 bytes limit workaround/solution some how, but it seems you are > objecting possible choices. Most developers need adequate level of security > to > build applications, not perfect security. Not all developers have right to > decide > maximum password length and how password is hashed. (e.g. Adding secret salt > is > still valid protection against stolen password database via SQL > injection,etc. > Some organizations require to add custom static slat to user defined > password.) I am objecting to the possible choices, because none of them are good enough to offset the risk. The risk associated with overlong passwords is trivially small. The risk to "inventing crypto" (such as with `crypt(sha512(password))` ) or weakening the case for the rest of passwords (such as with crypt-sha512) is significantly greater IMHO then the case where a user's password exceeds 72 characters. Yes, we could add a notice, but it wouldn't really help the class of users you're intending it to. And it may wind up hurting some by masking more serious errors (when the suppress with @). So I stick with the only good option that IMHO doesn't hurt users, which is documentation. But again, this is why I asked for the RFC. My opinion isn't the only one that matters. I care about it significantly, and I don't want to see users hurt. But ultimately there are far more people involved than just you and me. Putting together an RFC will let the discussion happen, each of us make our case, and let the community decide. > I'm not sure your opinions for > - password_hash() truncation behavior > - What to do to accept password longer than 72 bytes > > Could you give your opinion for these? My opinions (which I've stated above, but will summarize here): Truncation behavior: document it. That should be all that's needed. What to do to accept passwords longer than 72 bytes: Either put an upper cap on password length in the application, or don't worry about it. The chances the first 72 bytes can be guessed, but a further one is different is EXTREMELY small (you're more likely to win a lottery's jackpot 5 times, than to do so, based on a quick back-of-envelope estimation). Yes, ideally a hash function would allow for infinitely long (practically, 2^32-1 would be enough, 2^64-1 would be better) passwords. But it's not worth weakening a system to defend against it (by moving to crypt-sha512). And it's not worth suggesting invented crypto to defend against it (recommending crypt(sha512(password))). My recommendation: deal with it today. When scrypt (or the winner of the current PHC) gets crypt(3) bindings, then we'll pull it in and make it available to password_hash(). Until then, it's not a significant enough risk to worry about... Anthony