Re: [PHP-DEV] Adding a simple API for secure password hashing?
Hi Anthony, I'm not sure about the idea to have a specific SPL for password hashing. I like the idea to have a standard interface for that but maybe is enough just a set of functions. I see a valid argument to have a standard interface especially for the password_register_algo(). Enrico 2012/6/18 Anthony Ferrara ircmax...@gmail.com: Enrico I like your idea to offer a wrapper of crypt() with a better API (actually I used this approach in the ZF2 project: https://github.com/zendframework/zf2/blob/master/library/Zend/Crypt/Password/Bcrypt.php). Yeah, crypt() is really nice, and offers a lot of good things out of the box. It's just the salt generation and error handling that are a pita... I think we should also support the user's salt as option and generate a random salt if not provided. Yeah, that could be good. The only part we'd need to be careful of is error checking the salt (correct length, correct format, etc). But in general I like the idea... For the random generation I suggest to use as first option the openssl_random_pseudo_bytes() that is considered more secure compared with mcrypt_create_iv($size, MCRYPT_DEV_URANDOM). Well, the point wasn't to make a CS secure salt. We've already had discussions on that (it's not needed, and can harm the system to try to use CS salts). All salts need to be is unique (statistically unique is usually good enough). If people really want to use a CS salt, they should pass one in as the user-generated salt. But I'd really like to voice my opposition to having this function default to CS secure salt generation... I just wrote that changes here: https://gist.github.com/2949592 Looks good to me otherwise. I expanded my original gist a bit to add in the ability to register your own algorithm: https://gist.github.com/2949382 That way, existing projects that use things like PHPASS can register their own handler, and move towards this (let the fallback happen in password_validate instead of in user code). If we're going to go with this option (the series of functions), what do you think of putting them under spl: \SPL\password_create() \SPL\password_validate() \SPL\password_register_algo() \SPL\password_create_salt() Instead of doing it class based as was originally suggested? The reason for namespacing is that password_validate is used in the wild (not by many: http://www.koders.com/default.aspx?s=%22password_validate%28%22search.x=0search.y=0la=PHPli=*scope= ) Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
hi Anthony! On Tue, Jun 19, 2012 at 1:14 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hello all, Since there wasn't that much traffic on the draft version of the RFC, I've moved it into Proposed. https://wiki.php.net/rfc/hash_pbkdf2 What are your thoughts? Very nice work! Thanks :) I would update the RFC with the current available algorithms or recommended to be used (depending on the usage or goal). About adding this to 5.4, I do not think it should be done. This is not a small change and it may require more testing, both for the implementations or the API (while it is fairly simple as of now :). php-next is next year anyway. 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] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
hi Chris, On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones christopher.jo...@oracle.com wrote: We should take this offline - I can see cases where I'd strongly disagree. I see no reason to move a discussion offline or off list, this is a topic that interests many other readers or developers. 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] [RFC] Add hash_pbkdf2 function
Hi Anthony, i think your RFC is very good! I like the idea to have PBKDF2 implementation that is able to act, at the same time, as secure hash value generator (without the length parameter) and as key derivation function (with the length parameter). I think we should be consistent with the API of Hash functions of PHP and use the raw_output = false to generate hex string and raw_output = true to generate binary output. If folks need to convert the output to Base64 they can easily use base64_encode($output) where $output is generated with raw_output = true. I don't think this is a big deal. I also agree to insert this function in PHP 5.4, actually in this implementation we reused other hash functions of PHP and the tests for PBKDF2 are fully specified in PKCS #5 test vectors that you used in your patch test. Very nice job! Regards, Enrico 2012/6/19 Anthony Ferrara ircmax...@gmail.com: Hello all, Since there wasn't that much traffic on the draft version of the RFC, I've moved it into Proposed. https://wiki.php.net/rfc/hash_pbkdf2 What are your thoughts? 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] Adding a simple API for secure password hashing?
Angel, I don't think the code is the most appropiate one, but I suppose that's not a final proposal. Correct, it was just to fill out the interface a bit so that people could play with it and see how the interface worked... The interfaces look good to me. I'd maybe set the default $algo to PASSWORD_DEFAULT_HASH or similar, being a value bumped on each next revisions. Yeah, that's a good idea. Makes it easier to update without changing the interface. I would consider preferable to have the $ ofpassword_register_algoprefix implicit. That's fair. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
Pierre, Very nice work! Thanks :) Thanks! I would update the RFC with the current available algorithms or recommended to be used (depending on the usage or goal). When you say currently available algorithms, are you talking about the hash library as a whole? Or recommended for use with PBKDF2? Or other iterated stretching algorithms similar to PBKDF2? About adding this to 5.4, I do not think it should be done. This is not a small change and it may require more testing, both for the implementations or the API (while it is fairly simple as of now :). php-next is next year anyway. I'm not arguing that. When I proposed the draft earlier I had indicated that it was for trunk, and others said it could go into 5.4. That's why I put that section in the RFC. Personally, I'm in the middle. I can see some advantage to adding it to 5.4, but I can also see some disadvantages. So I leave that decision to others (such as yourself). Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
hi Anthony! On Wed, Jun 20, 2012 at 12:12 PM, Anthony Ferrara ircmax...@gmail.com wrote: I would update the RFC with the current available algorithms or recommended to be used (depending on the usage or goal). When you say currently available algorithms, are you talking about the hash library as a whole? Or recommended for use with PBKDF2? Or other iterated stretching algorithms similar to PBKDF2? The algos recommended to use with PBKDF2. About adding this to 5.4, I do not think it should be done. This is not a small change and it may require more testing, both for the implementations or the API (while it is fairly simple as of now :). php-next is next year anyway. I can see some advantage to adding it to 5.4, but I can also see some disadvantages. So I leave that decision to others (such as yourself). There are always advantages to do it. But they do not help the big picture. However, besides what I said earlier, fast releases of features, 100% BC releases will ease the move to newer versions, faster than the horrible situation we have now. If we keep merging features, nobody will migrate, ever or until they have no other choices. 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] [RFC] Add hash_pbkdf2 function
Pierre, On Jun 20, 2012 8:27 AM, Pierre Joye pierre@gmail.com wrote: hi Anthony! On Wed, Jun 20, 2012 at 12:12 PM, Anthony Ferrara ircmax...@gmail.com wrote: I would update the RFC with the current available algorithms or recommended to be used (depending on the usage or goal). When you say currently available algorithms, are you talking about the hash library as a whole? Or recommended for use with PBKDF2? Or other iterated stretching algorithms similar to PBKDF2? The algos recommended to use with PBKDF2. I will update the RFC tonight... About adding this to 5.4, I do not think it should be done. This is not a small change and it may require more testing, both for the implementations or the API (while it is fairly simple as of now :). php-next is next year anyway. I can see some advantage to adding it to 5.4, but I can also see some disadvantages. So I leave that decision to others (such as yourself). There are always advantages to do it. But they do not help the big picture. However, besides what I said earlier, fast releases of features, 100% BC releases will ease the move to newer versions, faster than the horrible situation we have now. If we keep merging features, nobody will migrate, ever or until they have no other choices. You have me convinced... Anthony
[PHP-DEV] Resume keyword
I can't get this out of my head after two weeks, but some part of me
says this is a *really* bad idea. Of course another part of my brain
things its a great idea and I'm getting tired of the argument.
Resume is similar to return, but can only be used in catch blocks or
in error handling functions. When encountered the run time returns to
the line after the exception was initially thrown and, well,
resumes.
If resume has a value, and the exception was an assignment operation,
then that value is assigned to the variable.
The part of me that likes this idea points out it allows exceptions to
behave like PHP errors when that behavior is wanted. It would also
open the possibility of converting all engine errors to exceptions,
because a mechanism would now be in place to handle exceptions in BC
manner to errors would be in place. Further, the default exception
handler could call resume after echoing on the non fatal errors.
The part of me that hates this idea is concerned with how it could be
abused to create even more nightmarish spaghetti tangles.
An example for additional clarity.
set_exception_handler(function ($e) {
echo $e-getMessage();
// Don't know if this is correct - but should be able to illustrate here
if ($e-getCode() == E_NOTICE E_STRICT) {
resume null;
}
echo 'Dying now'; exit;
});
throw new Exception('A test', E_NOTICE);
echo We didn't die;
The code above when run would echo A test. We didn't die.;
I leave this to smarter people than me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Add hash_pbkdf2 function
On Mon Jun 18 07:14 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/hash_pbkdf2
I like this proposal, it could be useful to add a simpler api that has
defaults matching the NIST recommendation:
hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
if the salt doesn't have at least 16 characters (128 bits), throw error
internally this calls:
hash_pbkdf2('sha1', $password, $salt, 1000);
My point being that:
$hash = hash_password('1234', 'my'. $password[1] .
'super-long-salt-secret');
Gives good enough security 80% of use cases and is simpler then:
$hash = hash_pbkdf2('sha1', '1234', 'my'. $password[1] .
'super-long-salt-secret', 1000);
Developers will still use sha1 or md5 because they are so simple.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Generators patch
Hi Nikita, I've just tried to compile your generators branch on windows, the build is broken there. This are the relevant messages before the compilation bails out: c:\php-sdk\phpmaster\vc9\x86\nikic\zend\zend_execute.c(1543) : error C2065: 'tsrm_ls' : undeclared identifier c:\php-sdk\phpmaster\vc9\x86\nikic\zend\zend_execute.c(1543) : error C2065: 'tsrm_ls' : undeclared identifier c:\php-sdk\phpmaster\vc9\x86\nikic\zend\zend_execute.c(1550) : error C2065: 'tsrm_ls' : undeclared identifier NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 9.0\VC\Bin\cl.exe' : return code '0x2' Stop. Hope this helps to improve it. Regards Anatoliy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] json_encode() behavior for incorrectly encoded strings
Hi internals! We currently have a big mess concerning the behavior of json_encode() with incorrectly encoded UTF-8 strings. To summarize the situation: PHP = 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8 string is encountered: * The invalid string is replaced with null, thus creating a partial JSON serialization * json_encode() returns the partial serialization, *not* false as it should * A warning is thrown, but only if display_errors=off * json_last_error() returns JSON_ERROR_UTF8 PHP 5.3.14 behaves as follows: * json_encode() returns false, as it should * A warning is thrown always, even with display_errors=on * json_last_error() returns JSON_ERROR_UTF8 * If the PHP_JSON_PARTIAL_OUTPUT_ON_ERROR option is specified, the old behavior is restored The reason for this situation is that a patch was applied for all branches, and then reverted, because Stas didn't consider the change towards always throwing a warning (even with display_errors=on) appropriate without further discussion. The backout though was done only on PHP 5.4 and master, but *not* on the PHP 5.3 branch. Thus we now have differing behavior between 5.3 and 5.4 (and PHP = 5.3.13). So, I'd like to ask whether the patch can be reapplied to 5.4 and master or whether we should do something else to solve this problem. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Resume keyword
Resume is similar to return, but can only be used in catch blocks or
in error handling functions. When encountered the run time returns to
the line after the exception was initially thrown and, well,
resumes.
Interesting idea. Just by reading that I thought of this scenario instead:
---
try {
echo about to throw exception;
throw new Exception;
echo still alive;
} catch (Exception $e) {
resume;
}
-
Which kinda looks nice to have. But how about this:
--
function my_function()
{
echo throwing exception;
throw new Exception;
echo still here?;
}
try {
echo calling function;
my_function();
} catch (Exception $e) {
resume;
}
By the time the exception is handled, the function stack would have
been unloaded, so how would it be able to resume? :)
If resume has a value, and the exception was an assignment operation,
then that value is assigned to the variable.
This feels a bit too magical IMO
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] destroying an array and using a new one
I'm trying to reverse an array but I keep getting bizarre results, such as
seg faults
0x006d0940 in gc_remove_from_buffer (zv=0x7fffb550) at
/home/yaderbh/php-5.4.3/Zend/zend_gc.h:189
189 root-next-prev = root-prev;
or I'll get PHP Fatal error: Allowed memory size of errors when trying
to manipulate the array in a script.
Basically what I'm doing is creating a pointer to zval, allocating and
creating the zval into an array, traversing the existing array and
calling add_index_zval. The position of the index is the current size and
work my way down.
hash_table = Z_ARRVAL_P(intern-elements);
ALLOC_INIT_ZVAL(new_elements);
array_init(new_elements);
zend_hash_internal_pointer_reset_ex(hash_table, pos);
i = intern-size;
while (zend_hash_get_current_data_ex(hash_table, (void **)current,
pos) == SUCCESS) {
tmp = **current;
zval_copy_ctor(tmp);
add_index_zval(new_elements, i, tmp);
i--;
zend_hash_move_forward_ex(hash_table, pos);
}
zval_ptr_dtor(intern-elements);
intern-elements = new_elements;
Can anyone spot the problem?
Re: [PHP-DEV] destroying an array and using a new one
On Thu, Jun 21, 2012 at 11:39 AM, Yader Hernandez
yader.hernan...@gmail.com wrote:
I'm trying to reverse an array but I keep getting bizarre results, such as
seg faults
0x006d0940 in gc_remove_from_buffer (zv=0x7fffb550) at
/home/yaderbh/php-5.4.3/Zend/zend_gc.h:189
189 root-next-prev = root-prev;
or I'll get PHP Fatal error: Allowed memory size of errors when trying
to manipulate the array in a script.
Basically what I'm doing is creating a pointer to zval, allocating and
creating the zval into an array, traversing the existing array and
calling add_index_zval. The position of the index is the current size and
work my way down.
hash_table = Z_ARRVAL_P(intern-elements);
ALLOC_INIT_ZVAL(new_elements);
array_init(new_elements);
zend_hash_internal_pointer_reset_ex(hash_table, pos);
i = intern-size;
while (zend_hash_get_current_data_ex(hash_table, (void **)current,
pos) == SUCCESS) {
tmp = **current;
Hi:
tmp is a stack allocted variable. when this scope is dead, *(tmp)
is undefined value.
you should use a heap allocated variable, or just add_ref the current zval
thanks
zval_copy_ctor(tmp);
add_index_zval(new_elements, i, tmp);
i--;
zend_hash_move_forward_ex(hash_table, pos);
}
zval_ptr_dtor(intern-elements);
intern-elements = new_elements;
Can anyone spot the problem?
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] destroying an array and using a new one
On Wed, Jun 20, 2012 at 8:51 PM, Laruence larue...@php.net wrote:
On Thu, Jun 21, 2012 at 11:39 AM, Yader Hernandez
yader.hernan...@gmail.com wrote:
I'm trying to reverse an array but I keep getting bizarre results, such
as
seg faults
0x006d0940 in gc_remove_from_buffer (zv=0x7fffb550) at
/home/yaderbh/php-5.4.3/Zend/zend_gc.h:189
189 root-next-prev = root-prev;
or I'll get PHP Fatal error: Allowed memory size of errors when trying
to manipulate the array in a script.
Basically what I'm doing is creating a pointer to zval, allocating and
creating the zval into an array, traversing the existing array and
calling add_index_zval. The position of the index is the current size and
work my way down.
hash_table = Z_ARRVAL_P(intern-elements);
ALLOC_INIT_ZVAL(new_elements);
array_init(new_elements);
zend_hash_internal_pointer_reset_ex(hash_table, pos);
i = intern-size;
while (zend_hash_get_current_data_ex(hash_table, (void **)current,
pos) == SUCCESS) {
tmp = **current;
Hi:
tmp is a stack allocted variable. when this scope is dead, *(tmp)
is undefined value.
you should use a heap allocated variable, or just add_ref the current zval
thanks
zval_copy_ctor(tmp);
add_index_zval(new_elements, i, tmp);
i--;
zend_hash_move_forward_ex(hash_table, pos);
}
zval_ptr_dtor(intern-elements);
intern-elements = new_elements;
Can anyone spot the problem?
--
Laruence Xinchen Hui
http://www.laruence.com/
Of course, I forgot to use Z_ADDREF_P. But I'm still having an issue. All
of the elements in the new array are now null. zend_hash_index_find is
returning SUCCESS.
Apart from adding Z_ADDREF_P, is there anything I should be doing?
thanks
