Re: [PHP-DEV] Re: #61421 for 5.3/4
On Tue, 2012-06-26 at 23:44 -0700, Stas Malyshev wrote: > Hi! > > > I would like to merge the patch from #61421 to all active branches (RMs as > > CC). > > > > It is not a new function nor does it add new features but new > > constants to support more algorithms for the signature verification. > > Don't see any problem with it. It's a feature .. but acceptable -) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
Hi all, On Sat, Jun 16, 2012 at 03:39:35PM +0200, Pierre Joye wrote: > Adding Alex to the loop as his insight will be unvaluable in this thread. Thank you for the chance to comment, and sorry that I did not do so yet. I am busy with lots of other stuff. I'd appreciate it if you don't hurry to implement this stuff too much, and I likely will comment on it (that is, on the actual proposed API and implementation). Please keep me in the loop. > On Sat, Jun 16, 2012 at 2:41 PM, Anthony Ferrara wrote: > > >> This userland library already solves all the issues you outlined with > >> bcrypt: http://www.openwall.com/phpass/ > > > > That library is not without its issues. For example, if you ask for a > > portable hash, it gives you a custom algorithm instead of bcrypt. > > That's because the library is php4 compatible. Note: _if_ you ask for a portable hash. What else should it do if you ask it for just that? > > So for modern versions > > of PHP (5.3+), it produces an unnecessarily weak hash. For modern versions of PHP, if you don't require portability of hashes to older versions, don't ask it for a portable hash. Of course, new PHP apps that will depend on your new API won't run on older versions of PHP by definition, so they could assume bcrypt is available. A concern, though, is that by the time major web apps would be able to assume a recent enough version of PHP (with this new API) we'll prefer to use a password hashing method with more than one configurable parameter (not just one "cost" setting), so we may want to design the API with that in mind. Additionally, I was/am going to experiment with implementing a decent KDF in PHP, but also considering its native reimplementation at the same time (for inclusion in PHP proper, etc.) That way, we could have hashes that are both portable (to older versions of PHP, to other scripting languages, etc.) and efficient. My expectation is that when implemented in a scripting language (using a widely-available crypto primitive like SHA-512 or AES), they could be somewhere inbetween bcrypt and scrypt in terms of cost of attack - and when reimplemented natively, they could be approaching scrypt (although Colin's choice of Salsa20/8 core for the crypto primitive was not arbitrary, and unfortunately we don't have that in PHP). I feel that there's room for exactly one such would-be de-facto standard "scripting KDF", and I might be in a position to set this standard due to phpass (this new thing could be a next generation phpass). But I haven't decided on this yet, I'd need to experiment first, and I don't like to be rushed. ;-) http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00051.html I think it's OK/preferable not to introduce this new hash type earlier than in a year from now or so, unless there's imminent threat of someone else doing it substantially worse. ;-) Meanwhile, I don't mind having an API that would provide bcrypt, even though I think that phpass does this well enough (and I intend to release a minor update to this first generation phpass). As long as we're not introducing a new hash type to this world yet, we are OK to experiment with APIs, etc. Alexander -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #61421 for 5.3/4
On Wed, Jun 27, 2012 at 11:18 AM, Johannes Schlüter wrote: > On Tue, 2012-06-26 at 23:44 -0700, Stas Malyshev wrote: >> Hi! >> >> > I would like to merge the patch from #61421 to all active branches (RMs as >> > CC). >> > >> > It is not a new function nor does it add new features but new >> > constants to support more algorithms for the signature verification. >> >> Don't see any problem with it. > > It's a feature .. but acceptable -) Not per se, a grey area where only adding constants could be fine. Anything else or more complicated is not. But why I ask :) Waiting David's reply and then I will merge it. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Hi, Anthony Some questions coming up in my mind by reading this RFC: * Will the value of the constant *PASSWORD_DEFAULT* remain unchanged forever? Otherwise this lib, in my opinion, can cause big problems when trying to port an existing system to a newer PHP-version. * Is this a native version of phpass? http://www.openwall.com/phpass/ Sorry if those things have already been discussed somewhere. I was not actively following this list in the last weeks ;) Bye Simon On Tue, Jun 26, 2012 at 5:25 PM, Anthony Ferrara wrote: > Hello All, > > I've taken the conversation of the previous simplified password > hashing API, and generated a patch and draft RFC for it. The patch > isn't ready yet (needs review, cleanup and testing), but it's a start. > > https://wiki.php.net/rfc/password_hash > > Please have a look and comment away! > > Thanks, > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
hi! On Wed, Jun 27, 2012 at 12:13 PM, Simon Schick wrote: > Hi, Anthony > > Some questions coming up in my mind by reading this RFC: > > * Will the value of the constant *PASSWORD_DEFAULT* remain unchanged > forever? Otherwise this lib, in my opinion, can cause big problems when > trying to port an existing system to a newer PHP-version. I won't set allow any default. This can't stay unchanged. > * Is this a native version of phpass? http://www.openwall.com/phpass/ Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] [DRAFT] RFC - array_column() function
On 2012-06-26 07:22, Ben Ramsey wrote:
However, in Prototype.js and Underscore.js, pluck seems behave more like
array_map() in PHP:
http://api.prototypejs.org/language/Enumerable/prototype/pluck/
http://documentcloud.github.com/underscore/#pluck
Nevertheless, it would technically have the same effect as the "column"
functionality, since calling that method/property in Javascript simply
returns the value of the property or result of the method call.
Remember that, in JavaScript, "foo.length" is equivalent to
"foo['length']". The use case for map that pluck was created to cover is
basically the same one here - essentially:
function array_{column|pluck}($array, $key)
{
return array_map(function($element)use($key)
{
return $element[$key];
}, $array);
};
Or, as it's implemented in Prototype.js (which inlines the map invocation),
function pluck(property) {
var results = [];
this.each(function(value) {
results.push(value[property]);
});
return results;
}
I will say I'm not sold on "pluck" since it describes the physical
action (a sharp tug) rather than the intended result (you pluck feathers
from a chicken but you pluck fruit from a tree). Other alternatives to
array_column that have crossed my mind include:
An extra argument to array_values() analogous to the extra argument to
array_keys(): I'm worried the analogy isn't close enough to excuse the
differences.
array_project(): too mathematically esoteric
array_select(): potentially also overloaded - what next, array_join()? -
but I admit that this is the name I typically use when I write the sort
of function that I gave above.
***
One thing about the existing implementation: it doesn't retain the keys
of the original array.
This throws away information that might still be needed. It's possible
that some elements in the original array didn't supply values to the
result (they lacked have the key in question); without the original
array's keys to provide a mapping, you won't know which ones they were.
If you did this twice on different keys, then as soon as one result
array came up short, the two sets would no longer be reconcilable.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Simon, > * Will the value of the constant PASSWORD_DEFAULT remain unchanged forever? > Otherwise this lib, in my opinion, can cause big problems when trying to > port an existing system to a newer PHP-version. No. That's why it's a separate constant. As newer, stronger hashing options become available, the default is designed to change over time. I'll update the RFC to indicate such. > * Is this a native version of phpass? http://www.openwall.com/phpass/ In a sense, yes. It's designed to have a dirt-simple API (similar to yours) built in to the core. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev wrote: > Hi! > > > Makes sense to me. So should I do this? Remove warnings + add string > > parameter for json_last_error? > I think its weird that the parameter is called $error_string and setting it to true means returning an array. Why not in the spirit of others have a new function json_last_error_msg() or something similar? > > Looks fine. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
On Wed, Jun 27, 2012 at 1:27 PM, Benjamin Eberlei wrote: > > On Wed, Jun 27, 2012 at 1:41 AM, Stas Malyshev > wrote: >> >> Hi! >> >> > Makes sense to me. So should I do this? Remove warnings + add string >> > parameter for json_last_error? > > > I think its weird that the parameter is called $error_string and setting it > to true means returning an array. > > Why not in the spirit of others have a new function json_last_error_msg() or > something similar? I implemented it with json_last_error(true) returning just a string, not an array. You can get the array using array(json_last_error(), json_last_error(true)) if you really want. But usually you will only need one of them as they both have different use cases. The stringified version for debugging and the error code version for detecting the error programmatically. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Session Handler enhancement (create_sid)
Session Handler enhancement (create_sid) I would like to propose a new feature to the current custom session handling; the ability for a user defined function to be used when generating the session id. The reasons are as follows: The Session Handler doesn't know when session_regenerate_id is used. If you want to set custom session identifiers, you have to use a replacement for session_regenerate_id. This prevents a session handler being dropped in to existing code without modification to that code. The flexibility given to sid generation using session.hash_function and session.hash_bits_per_character is still quite restrictive. I particularly dislike the chosen character set for session.hash_bits_per_character = 6, as the comma will always be urlencoded to %2C prior to being sent as a cookie. Existing code caters for a custom sid function (and has done since PHP 4), but it is not implemented. ps_module_struct already has a placeholder for s_create_sid, but it is hard-mapped to an internal function. The modifications required to allow a user function are minimal. I have created a patch/pull-request: https://github.com/php/php-src/pull/109 Regarding BC, I have implemented it such that supplying individual callbacks to session_set_save_handler is backwards compatible. The 7th argument is optional and if no callback is supplied the default is used. However when calling session_set_save_handler with a SessionHandler object, BC is broken. It is possible to preserve BC with a few changes but that means the interface would have to be incomplete. I think it is less evil to break BC for this relatively new feature (by new feature I mean the SessionHandler class - not create_sid), than it is to have a built-in class that doesn't match its associated built-in interface.
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
hi, On Wed, Jun 27, 2012 at 1:24 PM, Anthony Ferrara wrote: > Simon, > >> * Will the value of the constant PASSWORD_DEFAULT remain unchanged forever? >> Otherwise this lib, in my opinion, can cause big problems when trying to >> port an existing system to a newer PHP-version. > > the default is designed to change over time. That's exactly what I meant, having a changing default in this may force code change during php updates. I'm not in favour of having such default. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
hi, On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov wrote: >> Why not in the spirit of others have a new function json_last_error_msg() or >> something similar? > > I implemented it with json_last_error(true) returning just a string, > not an array. You can get the array using array(json_last_error(), > json_last_error(true)) if you really want. But usually you will only > need one of them as they both have different use cases. The > stringified version for debugging and the error code version for > detecting the error programmatically. I do not think this signature is consistent with the other error functions. I'd to go with the _msg or _string equivalent. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye escreveu: That's exactly what I meant, having a changing default in this may force code change during php updates. I'm not in favour of having such default. This would not require any code changes after updates. As I understand, hashes computed with the old default method could still be checked without any modification as the hash itself stores information about the method. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
Alex, > Thank you for the chance to comment, and sorry that I did not do so yet. > I am busy with lots of other stuff. I'd appreciate it if you don't > hurry to implement this stuff too much, and I likely will comment on it > (that is, on the actual proposed API and implementation). Please keep > me in the loop. It's not a huge rush, but at the same time I'd like to get it in by 5.5. The RFC process takes at minimum 3 weeks from official proposal (2 week discussion + 1 week voting). And I haven't officially proposed it yet. So there's still some time. > Note: _if_ you ask for a portable hash. What else should it do if you > ask it for just that? That's a fair point. I guess since the adoption of 5.3, and the fact that 5.2 is dead (yet alone php4), has me thinking that "portable" means something different today than it did then... >> > So for modern versions >> > of PHP (5.3+), it produces an unnecessarily weak hash. > > For modern versions of PHP, if you don't require portability of hashes > to older versions, don't ask it for a portable hash. That's fair. Perhaps the documentation needs updating to indicate that *portable* really just means compatibility with php <= 5.2... > Of course, new PHP apps that will depend on your new API won't run on > older versions of PHP by definition, so they could assume bcrypt is > available. A concern, though, is that by the time major web apps would > be able to assume a recent enough version of PHP (with this new API) > we'll prefer to use a password hashing method with more than one > configurable parameter (not just one "cost" setting), so we may want to > design the API with that in mind. That's a very good point. And it's already designed into the API. Right now, it only implements one algorithm in the core, but the switches and options are all there to support multiple. I just didn't see any solid reason to include the other (slightly less favored) crypt() hashes available today (SHA512 for example). But it's designed so that they can be added easily. I know there's talk floating around the list with respect to adding scrypt support into core. If that happens, it would definitely be added to the implementation. > Additionally, I was/am going to experiment with implementing a decent > KDF in PHP, but also considering its native reimplementation at the same > time (for inclusion in PHP proper, etc.) That way, we could have hashes > that are both portable (to older versions of PHP, to other scripting > languages, etc.) and efficient. My expectation is that when implemented > in a scripting language (using a widely-available crypto primitive like > SHA-512 or AES), they could be somewhere inbetween bcrypt and scrypt in > terms of cost of attack - and when reimplemented natively, they could be > approaching scrypt (although Colin's choice of Salsa20/8 core for the > crypto primitive was not arbitrary, and unfortunately we don't have that > in PHP). I feel that there's room for exactly one such would-be > de-facto standard "scripting KDF", and I might be in a position to set > this standard due to phpass (this new thing could be a next generation > phpass). But I haven't decided on this yet, I'd need to experiment > first, and I don't like to be rushed. ;-) No rush at all. I like the concept though. Would it be worth while to add an implementation of salsa20/8 to the core? > http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00051.html > > I think it's OK/preferable not to introduce this new hash type earlier > than in a year from now or so, unless there's imminent threat of someone > else doing it substantially worse. ;-) Meanwhile, I don't mind having > an API that would provide bcrypt, even though I think that phpass does > this well enough (and I intend to release a minor update to this first > generation phpass). As long as we're not introducing a new hash type to > this world yet, we are OK to experiment with APIs, etc. Well, part of the reason for this API, is that it appears that the majority of developers either aren't willing to use a library, or don't know it exists (even though it's very easy to find if you try). Additionally, I would think there would need to be a vetting period for a new KDF like this (for review, and trial implementations and such) before it would be considered "stronger" than bcrypt. If that's the case, then the core implementation would work fine. You implement the new KDF in a library. It goes through vetting and testing. if all is good, when it's mature it can be added back into core in this API. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
hi, On Wed, Jun 27, 2012 at 1:49 PM, Gustavo Lopes wrote: > Em Wed, 27 Jun 2012 13:37:50 +0200, Pierre Joye > escreveu: > > >> That's exactly what I meant, having a changing default in this may >> force code change during php updates. I'm not in favour of having such >> default. >> > > This would not require any code changes after updates. > > As I understand, hashes computed with the old default method could still be > checked without any modification as the hash itself stores information about > the method. That's only about one relatively simple use case where only PHP would be involved or crypt-like implemenation. For any other and rather common cases, it won't. I do not think a default should be implemented and actually let the user knows what he uses and what he is doing. That's one argument after all and clears all possible caveats. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
On Wed, Jun 27, 2012 at 1:40 PM, Pierre Joye wrote: > hi, > > On Wed, Jun 27, 2012 at 1:30 PM, Nikita Popov > wrote: > >>> Why not in the spirit of others have a new function json_last_error_msg() or >>> something similar? >> >> I implemented it with json_last_error(true) returning just a string, >> not an array. You can get the array using array(json_last_error(), >> json_last_error(true)) if you really want. But usually you will only >> need one of them as they both have different use cases. The >> stringified version for debugging and the error code version for >> detecting the error programmatically. > > I do not think this signature is consistent with the other error > functions. I'd to go with the _msg or _string equivalent. I looked at a few other error functions (of which we by the way we have *loads*, which is a bad sign) and indeed it seems that they all use a separate function to get the error message. Most use a xyz_errno() + xyz_error() pair. So it seems reasonable to instead provide the functionality via json_last_error_msg(). Any objections? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Pierre, >> As I understand, hashes computed with the old default method could still be >> checked without any modification as the hash itself stores information about >> the method. > > That's only about one relatively simple use case where only PHP would > be involved or crypt-like implemenation. For any other and rather > common cases, it won't. I do not think a default should be implemented > and actually let the user knows what he uses and what he is doing. > That's one argument after all and clears all possible caveats. Well, the argument could be made that if you need portability in that respect, that you should be using `crypt()` or the other library directly. This API is designed for the common use-case that impacts 99.9% of developers, where their applications will be the only ones accessing the passwords. And even if in the future they need to access it from a different system entirely (python for example), we're only implementing standard algorithms. So there should be a python binding available to verify (and hash) those passwords. This won't take the place of crypt() or other libraries. It's only there to solve the lowest common denominator in a dirt simple way. I think removing the default (and forcing an algorithm specification) kind-of defeats that point a little bit. It's not the end of the world, and I could possibly be convinced, but I'm skeptical. As for the issue you raised, I think that could be handled in the documentation. Perhaps something to the effect of: > PASSWORD_DEFAULT - This is the default algorithm that password_hash will use > if none is specified. Note that this is designed to change over time as newer > and stronger algorithms are implemented. If you need to stay with a single > algorithm (for portability or other reasons), it's recommended to always > specify the algorithm in the function call. Actually, now that I'm talking that out, perhaps the way to do it would be to specify the default algorithm in a php.ini parameter instead of the constant? That way the API can stay the same, but gives people more control over the default creation... Then again, maybe not. Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara escreveu: Actually, now that I'm talking that out, perhaps the way to do it would be to specify the default algorithm in a php.ini parameter instead of the constant? That way the API can stay the same, but gives people more control over the default creation... Then again, maybe not. Thoughts? I don't see any advantage in adding complexity through another level of indirection. If people want control over the default their application uses, they can just use a constant they define. That said, I think the default algorithm should provide sufficient guarantees to enable it to be used in a forward compatible fashion. For instance, if the default hash at one point consumes n bytes, then it may be backwards incompatible to change to use more than n bytes as at that point you may need a larger database field. So it should be documented with future changes in mind. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
hi, On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes wrote: > Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara > escreveu: > > >> Actually, now that I'm talking that out, perhaps the way to do it >> would be to specify the default algorithm in a php.ini parameter >> instead of the constant? That way the API can stay the same, but gives >> people more control over the default creation... Then again, maybe >> not. >> >> Thoughts? > > > I don't see any advantage in adding complexity through another level of > indirection. If people want control over the default their application uses, > they can just use a constant they define. And people will have to, as I described it earlier, and see below. > That said, I think the default algorithm should provide sufficient > guarantees to enable it to be used in a forward compatible fashion. Back then MD5 alone was all nice and shiny. So no, it is not possible to be forward compatible. > For > instance, if the default hash at one point consumes n bytes, then it may be > backwards incompatible to change to use more than n bytes as at that point > you may need a larger database field. So it should be documented with future It is not about size but ability to use the password across many applications. The days were only PHP were involved are behind us. yes, crypt may (in some extend) allows that, but this RFC purpose is to replace it, for a more developer friendly API. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Em Wed, 27 Jun 2012 14:43:35 +0200, Pierre Joye escreveu: On Wed, Jun 27, 2012 at 2:32 PM, Gustavo Lopes wrote: Em Wed, 27 Jun 2012 14:24:39 +0200, Anthony Ferrara escreveu: I don't see any advantage in adding complexity through another level of indirection. If people want control over the default their application uses, they can just use a constant they define. And people will have to, as I described it earlier, and see below. You described why people *may* have to, depending on the circumstances -- for instance, when interoperability in mixed environments is required. No one is saying that relying on a default value is appropriate in those circumstances, so this argument misses the mark. That said, I think the default algorithm should provide sufficient guarantees to enable it to be used in a forward compatible fashion. Back then MD5 alone was all nice and shiny. So no, it is not possible to be forward compatible. If this API existed 10 or more years ago and used MD5 as a default, I don't see how it could not be used in a forward compatible manner back then -- seen from the outside there's nothing different about MD5 or other digest method except for different parameters (which can be stored together with the salt and the method in the result of password_hash()) and digest size. And, unsurprisingly, you have no justification on why it could not be made forward compatible. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On Wed, Jun 27, 2012 at 07:51:38AM -0400, Anthony Ferrara wrote: > > > Note: _if_ you ask for a portable hash. What else should it do if you > > ask it for just that? > > That's a fair point. I guess since the adoption of 5.3, and the fact > that 5.2 is dead (yet alone php4), has me thinking that "portable" > means something different today than it did then... Regarding "5.2 is dead (yet alone php4)", it's wishful thinking. Sure, these have known vulnerabilities and such, yet they're still widely used. For PHP 3, I agree - it's in fact dead. I am going to drop support for PHP 3 in the very next revision of first generation phpass. BTW, what version of PHP introduced the === comparison operator? I guess this should become the minimum version for phpass since this is highly desirable to use. http://www.php.net/manual/en/language.operators.comparison.php does not say anything about that. > >> > So for modern versions > >> > of PHP (5.3+), it produces an unnecessarily weak hash. > > > > For modern versions of PHP, if you don't require portability of hashes > > to older versions, don't ask it for a portable hash. > > That's fair. Perhaps the documentation needs updating to indicate that > *portable* really just means compatibility with php <= 5.2... Yes, I may do that. The website mentions that on PHP 5.3.0+ the fallback never occurs, but it does not say when not to force the use of portable hashes. (In a new revision, the minimum version for never-fallback will likely be 5.3.7 as I am going to add a check for CVE-2011-2483.) > > Of course, new PHP apps that will depend on your new API won't run on > > older versions of PHP by definition, so they could assume bcrypt is > > available. A concern, though, is that by the time major web apps would > > be able to assume a recent enough version of PHP (with this new API) > > we'll prefer to use a password hashing method with more than one > > configurable parameter (not just one "cost" setting), so we may want to > > design the API with that in mind. > > That's a very good point. And it's already designed into the API. I'll take a look once I have a moment. > Right now, it only implements one algorithm in the core, but the > switches and options are all there to support multiple. I just didn't > see any solid reason to include the other (slightly less favored) > crypt() hashes available today (SHA512 for example). Thank you for not including other crypt() hashes. I fully support starting with bcrypt only, and only adding to it if there's something actually better, not just for the sake of giving more options to a user who can't make an educated decision. In the same spirit, while I support your proposal to add PBKDF2 to PHP proper, let's not add a crypt()-like hash encoding based on PBKDF2. I'd rather not see additional weaker-than-bcrypt hash types in use. In other words, I oppose your $pbkdf$ thing from PHP-PasswordLib. ;-) > But it's designed > so that they can be added easily. I know there's talk floating around > the list with respect to adding scrypt support into core. If that > happens, it would definitely be added to the implementation. For that, we'd need to decide on a proper crypt() hash encoding syntax for scrypt - something Colin chose not to do so far. At the very least, we'd need to know and consider his current opinion on the matter. IIRC, when I asked in 2010 (in March or April), his reply was that he did not feel scrypt was mature enough for that (it was about 1 year old at the time, since 2009). It might happen that we come up with another memory-hard function to use for password hashing before there's an agreed upon hash encoding syntax for scrypt in particular. To me, this possibility is a reason not to hurry with introducing such syntax for scrypt. We also need to decide on an approach to this: http://www.openwall.com/lists/crypt-dev/2011/05/12/4 (dealing with the memory requirements with concurrent authentication requests). Well, maybe just require relatively little memory - way more than bcrypt, but less than what scrypt was originally designed for. Meanwhile, I suggest that we treat scrypt just like we do PBKDF2 - provide a native function for it as a KDF, but no crypt() hash encoding syntax for its use for password authentication yet (even though this might be a more relevant use of it in PHP in the long run). BTW, for scrypt, it would be highly desirable to include the version of it that uses SSE2 intrinsics in the Salsa20/8 implementation (for use on systems capable of SSE2, indeed). While on x86-64 SSE2 is implied, I imagine that for 32-bit x86 builds of PHP we could choose to add runtime CPU detection and choice between two implementations. > > Additionally, I was/am going to experiment with implementing a decent > > KDF in PHP, but also considering its native reimplementation at the same > > time (for inclusion in PHP proper, etc.) That way, we could have hashes > > that are both portable (to older vers
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Pierre, > Back then MD5 alone was all nice and shiny. So no, it is not possible > to be forward compatible. By forward compatible, if you mean able to support any new algo, I think this is forward compatible. The options array allows for new implementations to implement whatever options they need. If you mean 100% compatibility, then no. That's not possible (due to storage requirements, etc). But the API would stay the same... >> For >> instance, if the default hash at one point consumes n bytes, then it may be >> backwards incompatible to change to use more than n bytes as at that point >> you may need a larger database field. So it should be documented with future > > It is not about size but ability to use the password across many > applications. The days were only PHP were involved are behind us. yes, > crypt may (in some extend) allows that, but this RFC purpose is to > replace it, for a more developer friendly API. This RFC does not intend to replace crypt(). It is intended to be a reasonably thin wrapper around it to make it easier to use for the average use case. Crypt() will still be there, and will still be encouraged for the use-cases that it makes sense for (portability, etc). This just attempts to solve the problem for the vast majority of users. In fact, the exposed password_make_salt() should make it easier for developers to use crypt: $hash = crypt($pass, "$6$" . password_make_salt(16)); Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
Alexander, > BTW, what version of PHP introduced the === comparison operator? > I guess this should become the minimum version for phpass since this is > highly desirable to use. > > http://www.php.net/manual/en/language.operators.comparison.php does not > say anything about that. > That's been in there for quite some time... I know at least php 5.0 had it (and I'm pretty sure it was 4)... > Thank you for not including other crypt() hashes. I fully support > starting with bcrypt only, and only adding to it if there's something > actually better, not just for the sake of giving more options to a user > who can't make an educated decision. I originally included them, but then it was pointed out that they are weaker, and I was asked *why include them*. when I couldn't answer, I pulled them... > In the same spirit, while I support your proposal to add PBKDF2 to PHP > proper, let's not add a crypt()-like hash encoding based on PBKDF2. > I'd rather not see additional weaker-than-bcrypt hash types in use. > In other words, I oppose your $pbkdf$ thing from PHP-PasswordLib. ;-) I had no plan on adding that to the core... So we're in perfect agreement there... (although in a side-lib, I don't see the harm as long as it's not default). > For that, we'd need to decide on a proper crypt() hash encoding syntax > for scrypt - something Colin chose not to do so far. At the very least, > we'd need to know and consider his current opinion on the matter. IIRC, > when I asked in 2010 (in March or April), his reply was that he did not > feel scrypt was mature enough for that (it was about 1 year old at the > time, since 2009). Agree. If I was to add it (I've been thinking about it), I would add it along side hash_pbkdf2 as hash_scrypt(). I would prefer waiting for the standard encoding syntax (so that we're not creating a new one) to include it in crypt(). > It might happen that we come up with another memory-hard function to use > for password hashing before there's an agreed upon hash encoding syntax > for scrypt in particular. To me, this possibility is a reason not to > hurry with introducing such syntax for scrypt. We also need to decide > on an approach to this: > http://www.openwall.com/lists/crypt-dev/2011/05/12/4 > (dealing with the memory requirements with concurrent authentication > requests). Well, maybe just require relatively little memory - way more > than bcrypt, but less than what scrypt was originally designed for. Sure... > Meanwhile, I suggest that we treat scrypt just like we do PBKDF2 - > provide a native function for it as a KDF, but no crypt() hash encoding > syntax for its use for password authentication yet (even though this > might be a more relevant use of it in PHP in the long run). Again, agreed. > Maybe, but if we add scrypt proper then I see little use for Salsa20/8 > on its own. Very true. Was just a thought. > What was the reason why Salsa20 was dropped in 5.4 (it was in 5.3, but > probably not usable for scrypt because of different round count)? I don't know. I was trying to find that out but everywhere I looked turned into a dead end. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Hello. I personally think that using PASSWORD_DEFAULT for algorythm by default is a bad idea. This should be defined by user in the code. Even worse if it is defined by .ini setting - deploy to a remote server and realize that there is a different .ini default that messes up everything. Lessons learned in the past are forgetten fast? And the thing I don't get is how do I verify a salted password? I have read throught the RFC and what I know about the salts makes me wonder - how da hell I will verify my salted hash if I can't pass the salt to password_verify? If there is some trick behind, it should be explained in the RFC (and in the docs later, because otherwise it makes people WTF?! who are not into cryptography). Arvids.
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Arvids,
On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
wrote:
> Hello.
>
> I personally think that using PASSWORD_DEFAULT for algorythm by default is a
> bad idea. This should be defined by user in the code. Even worse if it is
> defined by .ini setting - deploy to a remote server and realize that there
> is a different .ini default that messes up everything. Lessons learned in
> the past are forgetten fast?
It wouldn't mess up anything. All it would do is change the algorithm
used by the library when creating new passwords. Existing ones will
still validate. The new ones will validate on the old server as long
as that algorithm is supported (could be an issue in a mixed
environment where there are servers using an older version without
support for the new method in crypt())...
> And the thing I don't get is how do I verify a salted password? I have read
> throught the RFC and what I know about the salts makes me wonder - how da
> hell I will verify my salted hash if I can't pass the salt to
> password_verify?
Ah, I think I see the disconnect. crypt() returns the full salt
information along with everything necessary to hash it (all settings).
So the generated hash includes the salt, the method, and the cost
parameter. For example:
var_dump(crypt("rasmuslerdorf", "$2a$07$usesomesillystringfor"));
string(60) "$2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi"
So just storing the hash is enough...
> If there is some trick behind, it should be explained in the RFC (and in the
> docs later, because otherwise it makes people WTF?! who are not into
> cryptography).
That's completely fair. I'll add a section to the RFC about that...
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
hi, On Wed, Jun 27, 2012 at 2:59 PM, Gustavo Lopes wrote: > You described why people *may* have to, depending on the circumstances -- > for instance, when interoperability in mixed environments is required. No > one is saying that relying on a default value is appropriate in those > circumstances, so this argument misses the mark. No, it is exactly one example out of many where changing values are a real pain to deal with over the years. We should not have one. > If this API existed 10 or more years ago and used MD5 as a default, I don't > see how it could not be used in a forward compatible manner back then -- > seen from the outside there's nothing different about MD5 or other digest > method except for different parameters (which can be stored together with > the salt and the method in the result of password_hash()) and digest size. > And, unsurprisingly, you have no justification on why it could not be made > forward compatible. Changing default value forces code change if you have to keep a given hash, for one obvious side effect. If you disagree or does not like the idea, that's all fine, but you can't really say that it is not an argument (nothing to justify, this is a draft and it is being discussed). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
On that note I have only one request - please point me to the good article
that describes how this thing works (I would prefer one that at least tries
to explain in simple words) because at the moment i do not understand how
salt stored in the hash itself makes hash more secure than an unsalted one.
Thank you :-)
27.06.2012 14:16 пользователь "Anthony Ferrara"
написал:
> Arvids,
>
> On Wed, Jun 27, 2012 at 9:23 AM, Arvids Godjuks
> wrote:
> > Hello.
> >
> > I personally think that using PASSWORD_DEFAULT for algorythm by default
> is a
> > bad idea. This should be defined by user in the code. Even worse if it is
> > defined by .ini setting - deploy to a remote server and realize that
> there
> > is a different .ini default that messes up everything. Lessons learned in
> > the past are forgetten fast?
>
> It wouldn't mess up anything. All it would do is change the algorithm
> used by the library when creating new passwords. Existing ones will
> still validate. The new ones will validate on the old server as long
> as that algorithm is supported (could be an issue in a mixed
> environment where there are servers using an older version without
> support for the new method in crypt())...
>
> > And the thing I don't get is how do I verify a salted password? I have
> read
> > throught the RFC and what I know about the salts makes me wonder - how da
> > hell I will verify my salted hash if I can't pass the salt to
> > password_verify?
>
> Ah, I think I see the disconnect. crypt() returns the full salt
> information along with everything necessary to hash it (all settings).
> So the generated hash includes the salt, the method, and the cost
> parameter. For example:
>
> var_dump(crypt("rasmuslerdorf", "$2a$07$usesomesillystringfor"));
>
> string(60) "$2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi"
>
> So just storing the hash is enough...
>
> > If there is some trick behind, it should be explained in the RFC (and in
> the
> > docs later, because otherwise it makes people WTF?! who are not into
> > cryptography).
>
> That's completely fair. I'll add a section to the RFC about that...
>
> Thanks,
>
> Anthony
>
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Hi, On Tue, 2012-06-26 at 11:25 -0400, Anthony Ferrara wrote: > https://wiki.php.net/rfc/password_hash Some comments on the "error behavior" part: E_WARNING - When CRYPT is not included in core (was disabled compile-time, or is listed in disabled_functions declaration) Disabling a different function should have no effect. This is not intuitive. If crypt is a dependency and is not available this function shouldn't be available either. E_WARNING - When supplied an incorrect number of arguments. E_WARNING - When supplied a non-string first parameter (password) This should follow common semantics of zend_parse_parameters(... "s"). i.e. it has to support objects with __toString(). Also other scalars are fine. (if they can be casted to string) E_WARNING - If a non-string salt option is provided As above. If any error is raise, false is returned by the function. In http://de.php.net/functions.internal it is documented that internal functions return NULL on error during parameter parsing. New exceptions for that should have a good reason. These things are all minor and you might consider them bad, but then change it globally, not by adding new inconsistencies. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Braceless Syntax extended to functions and classes (bugs #47416 and 24100)
PHP has a braceless syntax stretching back to its roots as a template
language. Frameworks which make use of php templating use these tags
quite frequently since it's harder to overlook an endif statement in a
sea of HTML tags than a brace. But what of endfunction?
I did some look ups and found in the archive two of the most unhelpful
- bordering on rude - comments I've seen on the bug database.
[2003-06-09 13:40 UTC] der...@php.net > The "endif;" stuff is old
legacy syntax and is definitely not the recommended way of doing
things. For my part if can be removed for PHP 5... anyway, definitely
not something we will add.
[2009-02-17 15:41 UTC] johan...@php.net > Derick'S response to #24100
is still valid. We still prefer the {} syntax.
So sure "we" (whoever we is) prefer braces. I prefer them in straight
code contexts - I don't want to work with them in HTML templates.
This said, the need to do a function or class closure inside a
template is rare, bordering on non-existent.
But for functions there is one case - anonymous functions -
specifically for recursion. Here's a live example that renders a
nested list.
0):
echo $render( $category['children'] );
endif ?>
This would be ever so slightly easier to read with endfunction.
0):
echo $render( $category['children'] );
endif ?>
I'm not going to raise too much of a fuss over it. At the end of the
day, it's a small change. But the elitist, dismissive comments to the
idea from the team at the time were unwarranted.
Also, I have to wonder if the position on this has changed any at all?
Particularly since http://www.php.net/unsub.php
Re: [PHP-DEV] Braceless Syntax extended to functions and classes (bugs #47416 and 24100)
On Wed, Jun 27, 2012 at 11:06 AM, Michael Morris wrote:
> PHP has a braceless syntax stretching back to its roots as a template
> language. Frameworks which make use of php templating use these tags
> quite frequently since it's harder to overlook an endif statement in a
> sea of HTML tags than a brace. But what of endfunction?
>
> I did some look ups and found in the archive two of the most unhelpful
> - bordering on rude - comments I've seen on the bug database.
>
> [2003-06-09 13:40 UTC] der...@php.net > The "endif;" stuff is old
> legacy syntax and is definitely not the recommended way of doing
> things. For my part if can be removed for PHP 5... anyway, definitely
> not something we will add.
> [2009-02-17 15:41 UTC] johan...@php.net > Derick'S response to #24100
> is still valid. We still prefer the {} syntax.
>
>
> So sure "we" (whoever we is) prefer braces. I prefer them in straight
> code contexts - I don't want to work with them in HTML templates.
> This said, the need to do a function or class closure inside a
> template is rare, bordering on non-existent.
>
> But for functions there is one case - anonymous functions -
> specifically for recursion. Here's a live example that renders a
> nested list.
>
> $render = function( $categories ) use (&$render) {
>ob_start() ?>
>
>
>
> 0):
>echo $render( $category['children']
> );
>endif ?>
>
>
>
> }
> ?>
>
> This would be ever so slightly easier to read with endfunction.
>
> $render = function( $categories ) use (&$render):
>ob_start() ?>
>
>
>
> 0):
>echo $render( $category['children']
> );
>endif ?>
>
>
>
> endfunction
> ?>
>
> I'm not going to raise too much of a fuss over it. At the end of the
> day, it's a small change. But the elitist, dismissive comments to the
> idea from the team at the time were unwarranted.
>
> Also, I have to wonder if the position on this has changed any at all?
> Particularly since
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
If those are the most unhelpful comments you've seen in the bug database,
you haven't been looking hard enough :)
This does seem like an improvement to readability, but in an edge case that
I would try to avoid. Defining functions in templates just seems wrong.
I know your example isn't meant to be taken as the only archtype, but an
example of how I would deal with recursion:
0):
$tmp = $categories;
$categories = $category['children'];
include "renderCategories.php"
$categories = $tmp;
endif ?>
Not sure how great an idea doing a recursive include on a template would
be, but I also prefer using a templating engine, so I may be biased to work
in a different way.
Thanks,
John
Re: [PHP-DEV] bug 54547
On 06/26/2012 09:06 PM, OISHI Kazuo wrote: Does this need an architecture specific SKIPIF? See the mention of PHP_INT_SIZE on http://qa.php.net/write-test.php Like this? === --SKIPIF-- === Yes - if your test is for 64 bit platforms. If other conditions affect the output (endianess etc?) then you should add other tests to the SKIPIF section. Can you also create another PHPT file for 32 bit platforms, if there isn't one already? I'm afraid I may miss your point. Can you add some phpt tests for all the cases you've raised? Could you tell me your intention of this question? So that next time this code changes any breakage is obvious. I don't know whether to suggest adding an XFAIL for 5.4, or whether to suggest changing the expected output. This would depend on whether there is likely to be any code change to 5.4 or not. Sorry, I cannot understand what you say, but PHP code changes from 5.4.3 to 5.4.4 for #54547 and #62097 are: https://github.com/php/php-src/commit/9344bf193c6e35c8706923953f3e63bb01cc05ed https://github.com/php/php-src/commit/acd711685a592c52be200e248154283c6c49c9f8 zendi_smart_strcmp() and is_numeric_string[_ex]() are changed. Any test you create for PHP 5.4 need to either: 1. Pass, or 2. have an XFAIL section I don't know whether or not PHP 5.4 is going to be changed. If it is not going to be changed, then you should do #1. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On Wed, Jun 27, 2012 at 6:07 AM, Solar Designer wrote: > [...] > > BTW, what version of PHP introduced the === comparison operator? > I guess this should become the minimum version for phpass since this is > highly desirable to use. > === was added on Oct 19, 1999. php_version.h gives the version as 4.0B3-dev. http://git.php.net/?p=php-src.git;a=commit;h=65b152948e418e709893f6d3343e967ca2a789bc I ♥ git.
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On Wed, Jun 27, 2012 at 11:37 AM, Galen Wright-Watson wrote: > > On Wed, Jun 27, 2012 at 6:07 AM, Solar Designer wrote: > >> [...] >> >> BTW, what version of PHP introduced the === comparison operator? >> I guess this should become the minimum version for phpass since this is >> highly desirable to use. >> > > === was added on Oct 19, 1999. php_version.h gives the version > as 4.0B3-dev. > > > http://git.php.net/?p=php-src.git;a=commit;h=65b152948e418e709893f6d3343e967ca2a789bc > > I ♥ git. > That commit turns out to be just a NEWS update. The actual change was made on the same day but was committed a few hours earlier. In any case, setting PHP 4.0 as phpass's minimum version should work. http://git.php.net/?p=php-src.git;a=commit;h=7a205f6087892996b2a2e3deabcf8a714e4b9d96 Git log, why did you lead me astray?
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
On 27/06/12 18:13, Pierre Joye wrote:
> Changing default value forces code change if you have to keep a given
> hash, for one obvious side effect.
>
> If you disagree or does not like the idea, that's all fine, but you
> can't really say that it is not an argument (nothing to justify, this
> is a draft and it is being discussed).
>
> Cheers,
Precisely the point of such constant is to allow the applications to
magically
change to use more secure hashes, without needing to parform a recursive
sed in the codebase to change HASH_SHA2015 with HASH_SHA2048.
If you want to be in precise control of the actual hash used in a newer
version
(such as an hereogeneous deployment), you could set it to the lower
denominator
in php.ini.
Obviously, any such bump -which I would expect to happen on major releases-
would hold an entry in the NEWS file explaining that PASSWORD_DEFAULT_HASH
is now md5 by default instead of crc32 (still, I would expect a new hash
to have
been available on several releases -they could easily be added on minor
ones-
before becoming the PASSWORD_DEFAULT_HASH).
Remember that the goal was to make the next-generation password hasing api.
An (almost) foolproof way to make the applications secure. If you expect
them to
timely realise the problems of md5() and go back to change all their
functions,
you will replace the current function with password_hash('password',
SILLY_HASH, ...).
Developers with higher security knowledge (few of them, you'd almost
need to be a
cryptographer yourself) can use the advanced parameters to tweak it to
their needs.
Regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Arvids, On Wed, Jun 27, 2012 at 12:32 PM, Arvids Godjuks wrote: > On that note I have only one request - please point me to the good article > that describes how this thing works (I would prefer one that at least tries > to explain in simple words) because at the moment i do not understand how > salt stored in the hash itself makes hash more secure than an unsalted one. Here are some articles that are worth while: http://php.net/manual/en/function.crypt.php http://www.devshed.com/c/a/PHP/Using-the-PHP-Crypt-Function/ http://stackoverflow.com/a/4808616/338665 If more explanation is needed, I can try to expand the RFC a bit more. But give the new sections a read and let me know what you think. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Johannes,
> Some comments on the "error behavior" part:
>
> E_WARNING - When CRYPT is not included in core (was disabled
> compile-time, or is listed in disabled_functions declaration)
>
> Disabling a different function should have no effect. This is not
> intuitive. If crypt is a dependency and is not available this function
> shouldn't be available either.
Hrm. Well, then I guess I could re-implement against crypt internally.
That would take either a slight re-implementation of the crypt()
internals, or slight refactoring of the PHP_FUNCTION(crypt) function
to enable c calls to it (even if it's disabled).
I don't like the concept of core functions disappearing if they are
not implemented. I think that does nothing but make it harder on the
developers (now having to inject a function_exists(), etc).
Additionally, since this is a security issue, I think that always
defining the function is the better approach. Otherwise, you can wind
up in a situation where someone else comes in and implements function
password_verify($password, $hash) { return true; }, which would be all
sorts of bad... I can see the static linking to the function (instead
of the dynamic call that's there), So in this case, I personally think
the warning is appropriate.
> E_WARNING - When supplied an incorrect number of arguments.
> E_WARNING - When supplied a non-string first parameter (password)
>
> This should follow common semantics of zend_parse_parameters(... "s").
> i.e. it has to support objects with __toString(). Also other scalars are
> fine. (if they can be casted to string)
>
> E_WARNING - If a non-string salt option is provided
>
> As above.
Yeah, I guess that's fair. Is there a macro or function like
Z_REPRESENTABLE_AS_STRING_P() or something? To make it easier to
check?
> If any error is raise, false is returned by the function.
>
> In http://de.php.net/functions.internal it is documented that internal
> functions return NULL on error during parameter parsing. New exceptions
> for that should have a good reason.
The good reason is consistency. Otherwise there would be three return
values, `null`, `false` and `true` for password_verify(). Therefore, a
check of `false === password_verify($foo)` would actually fail
inadvertantly.
My opinion is that it should do what's appropriate. The other 2 I can
live with returning null (although I disagree with it significantly),
but password_verify I think really should only ever return a
boolean...
> These things are all minor and you might consider them bad, but then
> change it globally, not by adding new inconsistencies.
Fair enough...
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 54547
> So that next time this code changes any breakage is obvious. Next time? I had reported breakage for PHP 5.4.4 RC, but it "wont fix" and PHP 5.4.4 was released. https://bugs.php.net/bug.php?id=62097 I think the breakage exists in current version (PHP 5.4.4). > Any test you create for PHP 5.4 need to either: > > 1. Pass, or > 2. have an XFAIL section > > I don't know whether or not PHP 5.4 is going to be changed. If it is not > going to be changed, then you should do #1. All my tests are passed at previous version (PHP 5.4.3), and are failed at current version (PHP 5.4.4). Behavior of PHP 5.4 WAS changed. I intend to show evidence of breakage (backward incompatibility) in PHP 5.4.4, not intend to write test code to be passed on PHP 5.4.4. -- Oishi Kazuo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
Pierre, > No, it is exactly one example out of many where changing values are a > real pain to deal with over the years. We should not have one. While I completely see your point (and don't disagree with it in isolation), I also see the counter point of making it easy for people to use. Knowing anything about algorithms to force the common developer to make a choice between bcrypt and scrypt is unreasonable IMHO. It's an implementation detail that they should know, but most won't. Knowing the intricacies of the different algorithms is something even most senior devs (who are not active in security at least) don't understand. I'd rather present them best-case defaults, and let them make the decision to diverge from them. With that said, what about a compromise. What if we made the API: password_hash($password, $algo, array $options = array()) And instead of just making the users choose which algorithm to use, we provide a "moving" constant called PASSWORD_MOST_SECURE Which will be updated every major release (assuming there's an update to apply) or in extreme circumstances (a serious flaw is found in the current most secure algorithm, justifying a concern). That way, people don't have to worry about moving targets, because the core moves it for them as needed. But the choice has to be made. They aren't just relying upon the default. And the documentation surrounding it must indicate that if cross-platform interoperability is a concern, pick a standard algorithm such as bcrypt and use just that. So then, a basic call would be $hash = password_hash($password, PASSWORD_MOST_SECURE); It solves both problems, while still being reasonably easy... Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Hi, I forgot to mention MySQL's query cache. This change may have negative performance impact, since prepared query is not cached and native prepared query may not be used by other requests. It would be nice to have an option keeping prepared statement when PDOStatement destroyed. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/6/20 Yasuo Ohgaki : > Hi, > > I'm not opposed to this change, but I would like to give some ideas. > > If I use PDO postgresql and prepared statement, it executes native > prepared query. However, prepared statement is released(removed) > when PDOStatement object is destroyed. > > If PDO MySQL made like this, performance will not increase much > unless app issues the same SQL query over and over during request. > It would be nice to have option for not to release prepared query for > better performance. > > BTW, PDO should have method for setting client/database encoding. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > > 2012/6/15 Anthony Ferrara : >> Hello all, >> >> I raised this topic on list over a year ago ( >> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was >> determined that it wasn't time yet to disable prepared statement >> emulation for MySQL yet. However, Rasmus did mention that it was a >> possibility for 5.4 ( >> http://marc.info/?l=php-internals&m=130418875017027&w=2 ). Since that >> ship has sailed, I submitted a pull request for trunk to change the >> default value of prepared statement emulation for MySQL. >> >> https://github.com/php/php-src/pull/108 >> >> https://bugs.php.net/bug.php?id=54638 >> >> Does this need to be an RFC (should I draft one)? Or can it just be >> pulled as-is? >> >> Thanks, >> >> Anthony >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 06/27/2012 08:45 PM, Yasuo Ohgaki wrote: > Hi, > > I forgot to mention MySQL's query cache. > This change may have negative performance impact, since prepared > query is not cached and native prepared query may not be used by > other requests. That's not really true anymore. There are some limitations, yes, but in general prepared statements are cached since MySQL version 5.1.21 -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT RFC] Adding Simplified Password Hashing API
hi, On Thu, Jun 28, 2012 at 12:03 AM, Ángel González wrote: > Precisely the point of such constant is to allow the applications to > magically Right, but not a default argument, which is bad in this case, for the reasons explained earlier. > Obviously, any such bump -which I would expect to happen on major releases- > would hold an entry in the NEWS file explaining that PASSWORD_DEFAULT_HASH I have no problem with such constant and let the user uses it instead of a given algo. But then he will do it on purpose and being well informed about the implications. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
