Re: [PHP-DEV] bug 54547
>> I know this was discussed a number of times here, but just to bring it >> to a conclusion - I intend to apply patch in the bug report - which >> removes conversion for strings that do not convert to integers - to 5.4. >> If anybody sees anything that breaks because of this please tell. > > "12345678901234567890" == "12345678901234567890.0" > > used to be true, is now false ... i'd still say that's ok though as > it is a case of "never compare floats for equality" here, now that > the decimal clearly says that at least the right side is supposed > to be float, not integer ... In addition to == operator, >, <, >=, and <= operators are influenced. And, hexdecimal format for big number is now case-sensitive. http://www.mail-archive.com/internals@lists.php.net/msg58789.html -- OISHI Kazuo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 54547
On Fri, Jun 15, 2012 at 8:56 AM, Hartmut Holzgraefe wrote: > Too late to raise this now anyway, but ... > > On 13.05.2012 04:39, Stas Malyshev wrote: >> I know this was discussed a number of times here, but just to bring it >> to a conclusion - I intend to apply patch in the bug report - which >> removes conversion for strings that do not convert to integers - to 5.4. >> If anybody sees anything that breaks because of this please tell. > > "12345678901234567890" == "12345678901234567890.0" > > used to be true, is now false ... i'd still say that's ok though as > it is a case of "never compare floats for equality" here, now that > the decimal clearly says that at least the right side is supposed > to be float, not integer ... I don't think this is a case of "never compare floats for equality", as: 12345678901234567890.0 == 12345678901234567890.1 The number is simply too big, even for a float, to handle reliably. In fact number_format(12345678901234567890.0, 1, '', '') == '123456789012345671680' > > -- > hartmut > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] concatenation operator
On 2012-06-15 04:00, Ángel González wrote: On 13/06/12 05:26, Morgan L. Owens wrote: After reading the performance improvements RFC about interned strings, and its passing mention of a "special data structure (e.g. zend_string) instead of char*", I've been thinking a little bit about this and what such a structure could be. But rather than interned strings, I thought that _implicit_ concatenation would be a bigger win in the long term. Like interning, it relies on strings being immutable. This zend_string is a composite type. Leaves are _almost_ identical to existing string zvals - char* val, int len - but also an additional "child_count" field. For leaves, child_count is zero (not incidentally indicating that it _is_ a leaf). For internal nodes, "val" is a list of zend_strings (child_count of them). "len" still refers to the total string length (the sum of the len fields of its children). So a string that has been built up through concatenation is represented by a tree (actually a dag) of zend_strings. The edges in this dag are all properly reference-counted; discarding a string decrements the reference counts of its children. How do you list then? As a single-linked list? That would avoid reuse of the component strings in different superstrings except from matching ends... I was thinking just in terms of an array (the composite would be pointing either to an array of characters or an array of strings). Mainly just because that's how I pictured it (and haven't thought of a reason not to, since the number of children is known when the concatenated string is created, and fixed due to immutability). Component strings aren't copied as such, only referenced. In that sense the choice of array vs. list comes down to where that reference is kept - in the parent string or the elder sibling. Sharing common suffixes would save a number of references, but when concatenating two existing strings, the list of component references in the _prefix_ would need to be copied for the sake of whatever else is using it at the time (otherwise they would end up with the concatenated string as well). Speaking of concatenation, unless potentially scary stuff is done, concatenating three strings is done by concatenating two of them, then concatenating the result with the third, giving a binary tree; so why am I suggesting an array of arbitrary length? Think of an implementation of PHP's join()/implode() that exploits this structure. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
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
Re: [PHP-DEV] bug 54547
Too late to raise this now anyway, but ... On 13.05.2012 04:39, Stas Malyshev wrote: > I know this was discussed a number of times here, but just to bring it > to a conclusion - I intend to apply patch in the bug report - which > removes conversion for strings that do not convert to integers - to 5.4. > If anybody sees anything that breaks because of this please tell. "12345678901234567890" == "12345678901234567890.0" used to be true, is now false ... i'd still say that's ok though as it is a case of "never compare floats for equality" here, now that the decimal clearly says that at least the right side is supposed to be float, not integer ... -- hartmut -- 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 13, 2012 at 2:31 PM, Nikita Popov wrote: > Hi internals! > > Recent incidents have shown that even very large websites still don't > get how to do password hashing properly. The sha1 hashes used by > Linkedin et al can be easily cracked even by amateurs without special > hardware. > LinkedIn was using sha1?! Are you fucking serious?? I think it's time for me to change my password there to something I'm *not* using anywhere else lol. At this rate, tomorrow are we going to learn that Gmail uses md5 and that Facebook passwords are stored in plaintext files under the HTTP root? Anyway, BIG +1 on this RFC! --Kris
[PHP-DEV] Re: Confusion on how to exclude embedded sqlite3 during make/build
Now getting a lot of these messages: "/data/prj/php-5.3.13/Zend/zend.h", line 179.10: 1506-358 (I) "__restrict__" is defined on line 186 of /usr/include/standards.h. line 179... #if defined(__GNUC__) && ZEND_GCC_VERSION >= 3004 #else # define __restrict__ #endif #define restrict __restrict__ AIX: /usr/include/standards /* * Handle the use of the restrict keyword in non-C99 compilers */ #if ((__STDC_VERSION__ >= 199901L) || defined(__C99_RESTRICT)) #define __restrict__ restrict #else #define __restrict__ #endif Whose right?? On Thu, Jun 14, 2012 at 6:36 PM, Michael Felt wrote: > messages crossed - thanks. I was thinking of copying the sqlite, or at > least doing a diff when I saw the same error in both 5.3.14 and 5.4.4 > > > On Thu, Jun 14, 2012 at 6:33 PM, Michael Felt wrote: > >> Well, I am wondering if I posted this wrong - where are all the [PHP-DEV] >> brackets coming from. >> >> But, i believe I found the "syntax" error - by default AIX compiler does >> not support // comments, the CFLAG >> -qlangval=extc99 (or extc89) needs to be added. >> >> Testing further with 5.3.14 and 5.4.4 >> >> Michael >> >> >> On Thu, Jun 14, 2012 at 12:58 AM, Michael Felt wrote: >> >>> Hi. >>> >>> I am trying to compile php against httpd 2.4.2 - but before it gets >>> interesting I think I am having a different problem. >>> >>> The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against >>> vac.C v11 compiler. >>> >>> data/prj/php-5.3.13/ext/sqlite3/sqlite3.c -o ext/sqlite3/sqlite3.lo >>> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 893.9: 1506-046 (S) >>> Syntax error. >>> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.41: 1506-045 (S) >>> Undeclared identifier i. >>> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.51: 1506-277 (S) >>> Syntax error: possible missing ';' or ','? >>> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.65: 1506-045 (S) >>> Undeclared identifier or. >>> make: 1254-004 The error code from the last command is 1. >>> >>> Rather than try and solve that I compiled a separate sqlite3 version >>> root@x104:[/]sqlite3 -version >>> 3.6.22 >>> >>> However, even after make distclean and a new run of configure with the >>> following arguments - make still continues to try to compile the embedded >>> sqlite3. >>> >>> root@x104:[/data/prj/php-5.3.13]cat php_configure.ksh >>> #!/usr/bin/ksh >>> >>> set -x >>> >>> ./configure \ >>> --prefix=/opt \ >>> --sysconfdir=/etc \ >>> --mandir=/usr/share/man \ >>> --with-libdir=/opt/lib \ >>> --with-sqlite3=/opt \ >>> > build/aix/configure.out >>> >>> >>> >>> What am I doing wrong? Many thanks! >>> >>> Michael >>> >>> >> >
Re: [PHP-DEV] Confusion on how to exclude embedded sqlite3 during make/build
On Thu, 2012-06-14 at 18:26 +0200, Ángel González wrote: > What do you have at those lines? As it mentions "Undeclared identifier > or.", > perhaps it's (wrongly) taking the slash at "and/or " as a "*/" ?? > That would be very broken of a compiler... No, that's invalid C89 code and a quite standards compliant C89 compiler. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Confusion on how to exclude embedded sqlite3 during make/build
messages crossed - thanks. I was thinking of copying the sqlite, or at least doing a diff when I saw the same error in both 5.3.14 and 5.4.4 On Thu, Jun 14, 2012 at 6:33 PM, Michael Felt wrote: > Well, I am wondering if I posted this wrong - where are all the [PHP-DEV] > brackets coming from. > > But, i believe I found the "syntax" error - by default AIX compiler does > not support // comments, the CFLAG > -qlangval=extc99 (or extc89) needs to be added. > > Testing further with 5.3.14 and 5.4.4 > > Michael > > > On Thu, Jun 14, 2012 at 12:58 AM, Michael Felt wrote: > >> Hi. >> >> I am trying to compile php against httpd 2.4.2 - but before it gets >> interesting I think I am having a different problem. >> >> The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against >> vac.C v11 compiler. >> >> data/prj/php-5.3.13/ext/sqlite3/sqlite3.c -o ext/sqlite3/sqlite3.lo >> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 893.9: 1506-046 (S) >> Syntax error. >> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.41: 1506-045 (S) >> Undeclared identifier i. >> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.51: 1506-277 (S) >> Syntax error: possible missing ';' or ','? >> "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.65: 1506-045 (S) >> Undeclared identifier or. >> make: 1254-004 The error code from the last command is 1. >> >> Rather than try and solve that I compiled a separate sqlite3 version >> root@x104:[/]sqlite3 -version >> 3.6.22 >> >> However, even after make distclean and a new run of configure with the >> following arguments - make still continues to try to compile the embedded >> sqlite3. >> >> root@x104:[/data/prj/php-5.3.13]cat php_configure.ksh >> #!/usr/bin/ksh >> >> set -x >> >> ./configure \ >> --prefix=/opt \ >> --sysconfdir=/etc \ >> --mandir=/usr/share/man \ >> --with-libdir=/opt/lib \ >> --with-sqlite3=/opt \ >> > build/aix/configure.out >> >> >> >> What am I doing wrong? Many thanks! >> >> Michael >> >> >
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On 14 June 2012 17:50, Ángel González wrote: *snip* > May I ask how would you end up at the situation where the attackers have > the password hashes but not the salt? > > Any process which needs to read the password hashes will also need > knowledge of the salt. Thus an attacker would most likely also know both. > That's precisely how salts are designed to work. If your salts are not stored with your password hashes, then an sql injection that would leak your password hashes would not leak the salts. The recent database leaks come to mind: had they only contained password hashes but no salts (I know the hashes were unsalted, but *had* they been salted ...) attackers would have faced an impossible task trying to bruteforce even just one hash. Otherwise, you'd be able to focus on a given account (an admin account comes to mind) and spend all your efforts on that using the typical options. As pointed out once or twice, for most people/purposes, it's a theoretical discussion. That doesn't mean it shouldn't be taken into consideration though (people rarely break into your house where you expect them to). > I admit you could have a common salt for all users stored in php and > only a leak of the database. But such salt would most likely be provided > by the user, generated using a different program... expected to be secure. > Using a shared salt is worse than a uniqe salt per user, so that's not > something to promote either. > You wouldn't be "educating in the right way". And I'm obviously not advocating a shared salt (at least, I wasn't thinking I was, especially seeing as I asked for a parameter in function to make sure that salts would be more random). Regards Peter -- WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Confusion on how to exclude embedded sqlite3 during make/build
Well, I am wondering if I posted this wrong - where are all the [PHP-DEV] brackets coming from. But, i believe I found the "syntax" error - by default AIX compiler does not support // comments, the CFLAG -qlangval=extc99 (or extc89) needs to be added. Testing further with 5.3.14 and 5.4.4 Michael On Thu, Jun 14, 2012 at 12:58 AM, Michael Felt wrote: > Hi. > > I am trying to compile php against httpd 2.4.2 - but before it gets > interesting I think I am having a different problem. > > The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against vac.C > v11 compiler. > > data/prj/php-5.3.13/ext/sqlite3/sqlite3.c -o ext/sqlite3/sqlite3.lo > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 893.9: 1506-046 (S) > Syntax error. > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.41: 1506-045 (S) > Undeclared identifier i. > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.51: 1506-277 (S) > Syntax error: possible missing ';' or ','? > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.65: 1506-045 (S) > Undeclared identifier or. > make: 1254-004 The error code from the last command is 1. > > Rather than try and solve that I compiled a separate sqlite3 version > root@x104:[/]sqlite3 -version > 3.6.22 > > However, even after make distclean and a new run of configure with the > following arguments - make still continues to try to compile the embedded > sqlite3. > > root@x104:[/data/prj/php-5.3.13]cat php_configure.ksh > #!/usr/bin/ksh > > set -x > > ./configure \ > --prefix=/opt \ > --sysconfdir=/etc \ > --mandir=/usr/share/man \ > --with-libdir=/opt/lib \ > --with-sqlite3=/opt \ > > build/aix/configure.out > > > > What am I doing wrong? Many thanks! > > Michael > >
Re: [PHP-DEV] Confusion on how to exclude embedded sqlite3 during make/build
On 14/06/12 00:58, Michael Felt wrote: > Hi. > > I am trying to compile php against httpd 2.4.2 - but before it gets > interesting I think I am having a different problem. > > The sqlite3 embedded in ./ext/sqlite3 returns a syntax error against vac.C > v11 compiler. > > data/prj/php-5.3.13/ext/sqlite3/sqlite3.c -o ext/sqlite3/sqlite3.lo > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 893.9: 1506-046 (S) > Syntax error. > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.41: 1506-045 (S) > Undeclared identifier i. > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.51: 1506-277 (S) > Syntax error: possible missing ';' or ','? > "/data/prj/php-5.3.13/ext/sqlite3/sqlite3.c", line 894.65: 1506-045 (S) > Undeclared identifier or. > make: 1254-004 The error code from the last command is 1. ext/sqlite3/sqlite3.c in php-5.3.13 only has comments at lines 893-894. (That's a big comment from 846 to 906). What do you have at those lines? As it mentions "Undeclared identifier or.", perhaps it's (wrongly) taking the slash at "and/or " as a "*/" ?? That would be very broken of a compiler... > Rather than try and solve that I compiled a separate sqlite3 version > root@x104:[/]sqlite3 -version > 3.6.22 > > However, even after make distclean and a new run of configure with the > following arguments - make still continues to try to compile the embedded > sqlite3. > > root@x104:[/data/prj/php-5.3.13]cat php_configure.ksh > #!/usr/bin/ksh > > set -x > > ./configure \ > --prefix=/opt \ > --sysconfdir=/etc \ > --mandir=/usr/share/man \ > --with-libdir=/opt/lib \ > --with-sqlite3=/opt \ > > build/aix/configure.out > > What am I doing wrong? Many thanks! Seems a problem in the sqlite3 extension config.m4, in that it has a depends rule on the libsqlite/sqlite3.c copy. A simple fix would be to copy the sqlite amalgamation that works for you over the php copy. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] concatenation operator
On 13/06/12 05:26, Morgan L. Owens wrote: > After reading the performance improvements RFC about interned strings, > and its passing mention of a "special data structure (e.g. > zend_string) instead of char*", I've been thinking a little bit about > this and what such a structure could be. > > But rather than interned strings, I thought that _implicit_ > concatenation would be a bigger win in the long term. Like interning, > it relies on strings being immutable. > > This zend_string is a composite type. Leaves are _almost_ identical to > existing string zvals - char* val, int len - but also an additional > "child_count" field. For leaves, child_count is zero (not incidentally > indicating that it _is_ a leaf). For internal nodes, "val" is a list > of zend_strings (child_count of them). "len" still refers to the total > string length (the sum of the len fields of its children). > > So a string that has been built up through concatenation is > represented by a tree (actually a dag) of zend_strings. The edges in > this dag are all properly reference-counted; discarding a string > decrements the reference counts of its children. How do you list then? As a single-linked list? That would avoid reuse of the component strings in different superstrings except from matching ends... -- 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 14/06/12 16:26, Peter Lind wrote: > I would say it really depends upon the project. The salt can not only > protect against rainbow tables and password hash collisions, if it is > unknown to an attacker then it essentially acts to further strengthen > the hash by vastly expanding the keyspace. Supposing an attacker is > trying to get at the password for just one user account (say, admin) > and the hashed password is available - if the salt can be > predicted/guessed, then the keyspace is reduced to that of an unsalted > password and you can run a dictionary attack on the hash. If, on the > other hand, the salt is unpredictable and you don't have access to it, > there is no way to run a dictionary attack (offline, that is). The > security here depends upon storage as well, but the point remains - a > salt isn't by default something you can make public knowledge. > > It might be a theoretical concern for most people and the people > really wanting the extra level of security would probably know well > enough how to get exactly what they need - but if provisions are made > so you could reuse the same function you might also be able to educate > developers better. I.e. make it easy to do the right thing and more > people will do it. May I ask how would you end up at the situation where the attackers have the password hashes but not the salt? Any process which needs to read the password hashes will also need knowledge of the salt. Thus an attacker would most likely also know both. That's precisely how salts are designed to work. I admit you could have a common salt for all users stored in php and only a leak of the database. But such salt would most likely be provided by the user, generated using a different program... expected to be secure. Using a shared salt is worse than a uniqe salt per user, so that's not something to promote either. You wouldn't be "educating in the right way". -- 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?
Peter, > I would say it really depends upon the project. The salt can not only > protect against rainbow tables and password hash collisions, if it is > unknown to an attacker then it essentially acts to further strengthen > the hash by vastly expanding the keyspace. That's not true. There are two types of secure algorithms in cryptography. Those that are kept secure by a secret, and those that are secure by effort. Hashing is an effort based algorithm. It's difficult to reverse, so you need to brute force, expending a lot of effort in the process... Salts are designed to make that brute forcing non-amortizable, only (meaning that the effort put in to brute force one hash can't be applied to another). The way they are used in the algorithms shows that. They are even stored directly with the hash in a number of implementations (crypt being a key one). That should point out how the security that a salt adds does not depend on it being secret. > Supposing an attacker is > trying to get at the password for just one user account (say, admin) > and the hashed password is available - if the salt can be > predicted/guessed, then the keyspace is reduced to that of an unsalted > password and you can run a dictionary attack on the hash. If, on the > other hand, the salt is unpredictable and you don't have access to it, > there is no way to run a dictionary attack (offline, that is). The > security here depends upon storage as well, but the point remains - a > salt isn't by default something you can make public knowledge. Then it's not a salt. And unless you *really* know what you're doing, it's not worth it, and at best you're not making it more secure (and at worst, you're significantly reducing the security). Remember, security through obscurity is not security. Check out this post, and the comments from experts: http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html > It might be a theoretical concern for most people and the people > really wanting the extra level of security would probably know well > enough how to get exactly what they need - but if provisions are made > so you could reuse the same function you might also be able to educate > developers better. I.e. make it easy to do the right thing and more > people will do it. No, if people want the extra level of security, they should then encrypt the hash with a secure key before storing it. Note that 2 algorithms would be in place, one proof of work, and one dependent upon a secret. Trying to combine them because one parameter looks like it could be a secret is not the way to go... 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?
Thomas, > This: > > http://barebonescms.com/documentation/csprng/ > > Takes a different approach. Generate one or more stored root seeds and then > use those seeds to generate as much data as is needed without risking loss > of entropy. It also accepts extra entropy sources as input - even weak > sources such as an incrementing integer or serialized user-submitted data - > to further enhance the output. Actually, I would not call that CS. Where's the white paper for the algorithm? Where's the RFC? Just because you take data from a lot of sources does not make it CS... And just putting the *kitchen sink* into a single sha512 hash does not either. The vast majority of the data that's being called entropy is purely static on the system (page to page won't change). Especially for something that's going into core, I'd suggest sticking to approved, vetted algorithms. If it doesn't have an RFC or a reviewed white-paper, I would avoid it. Additionally, it's pushing all of the "entropy sources" into a single hash bucket. I'd much rather see it push each one through a hmac round with the existing data. That way, the relationship between a specific source and the overall result is complex. It's not just complex in relation to other data, but also into the algorithm itself... > Adding more random sources of information to PHP is a good thing. If > something like what is being discussed is developed, it will merely become > one more source for root seed generation. The more the merrier. Good > sources of entropy are hard to come by. Definitely agree... > One thing I would like to recommend is add to the documentation that certain > functions are inappropriate for specific use cases and recommend alternative > solutions. A lot of people out there think rand() and mt_rand() are > suitable for security. Maybe have a specific page in the PHP documentation > dedicated to covering random string and number generation and link to that > page from various function pages. Sounds good to me... 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?
On 14 June 2012 15:35, Anthony Ferrara wrote: > Peter, > >> Whether or not a CSPRNG is needed depends on what you're doing, your >> needed level of security. Perhaps add a parameter to control this, so >> it would be possible to make use of this function even if you need the >> maximum level of security? If it's not available, the function should >> fail in some suitable fashion. > > For password hashing, it won't ever be needed for the salt. The salt > is not a secret in the context of cryptography. But, on that note, if > we were adding a stronger PRNG generator, it would be good to expose > it natively. And that native exposure would likely take a parameter > for CS-safe PRNG... I would say it really depends upon the project. The salt can not only protect against rainbow tables and password hash collisions, if it is unknown to an attacker then it essentially acts to further strengthen the hash by vastly expanding the keyspace. Supposing an attacker is trying to get at the password for just one user account (say, admin) and the hashed password is available - if the salt can be predicted/guessed, then the keyspace is reduced to that of an unsalted password and you can run a dictionary attack on the hash. If, on the other hand, the salt is unpredictable and you don't have access to it, there is no way to run a dictionary attack (offline, that is). The security here depends upon storage as well, but the point remains - a salt isn't by default something you can make public knowledge. It might be a theoretical concern for most people and the people really wanting the extra level of security would probably know well enough how to get exactly what they need - but if provisions are made so you could reuse the same function you might also be able to educate developers better. I.e. make it easy to do the right thing and more people will do it. Regards Peter -- WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 -- 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 6/14/2012 6:11 AM, Anthony Ferrara wrote: Daniel, Stas has the right approach, not only should the methods be simplified and platform/algorithm agnostic but have a proper salt built in (there are a few CSPRNG implementations around), I've seen salts used from numbers to md5's to just being skipped altogether. Well, just to be clear, a salt does not need a CSPRNG. All it needs to be is reasonably unique. In fact, I wouldn't make it CS, as that would deplete the available entropy in the system for CSPRNG generation. So in practice, a normal PRNG will suffice. With that said, mt_rand() is not enough. It should be a moderately good PSRNG. It just doesn't need to be CS. If mcrypt is available, DEV_URANDOM would be a good place to get entropy. Or, we could implement a system like I did in https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random that follows RFC4086: http://tools.ietf.org/html/rfc4086#section-5.2 Where it mixes together several sources of weak and moderate strength PRNG... This: http://barebonescms.com/documentation/csprng/ Takes a different approach. Generate one or more stored root seeds and then use those seeds to generate as much data as is needed without risking loss of entropy. It also accepts extra entropy sources as input - even weak sources such as an incrementing integer or serialized user-submitted data - to further enhance the output. Adding more random sources of information to PHP is a good thing. If something like what is being discussed is developed, it will merely become one more source for root seed generation. The more the merrier. Good sources of entropy are hard to come by. One thing I would like to recommend is add to the documentation that certain functions are inappropriate for specific use cases and recommend alternative solutions. A lot of people out there think rand() and mt_rand() are suitable for security. Maybe have a specific page in the PHP documentation dedicated to covering random string and number generation and link to that page from various function pages. -- Thomas Hruska CubicleSoft President Barebones CMS is a high-performance, open source content management system for web developers operating in a team environment. An open source CubicleSoft initiative. Your choice of a MIT or LGPL license. http://barebonescms.com/ -- 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?
Peter, > Whether or not a CSPRNG is needed depends on what you're doing, your > needed level of security. Perhaps add a parameter to control this, so > it would be possible to make use of this function even if you need the > maximum level of security? If it's not available, the function should > fail in some suitable fashion. For password hashing, it won't ever be needed for the salt. The salt is not a secret in the context of cryptography. But, on that note, if we were adding a stronger PRNG generator, it would be good to expose it natively. And that native exposure would likely take a parameter for CS-safe PRNG... Just my $0.02... > *snip* > >> Or, we could implement a system like I did in >> https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random >> that follows RFC4086: http://tools.ietf.org/html/rfc4086#section-5.2 >> Where it mixes together several sources of weak and moderate strength >> PRNG... > > Will the entropy multiply by mixing sources? I.e. will the result be > "more random"? Won't it just be as random as the most random source? No, it will not multiply. It can in practice increase from the strongest source. But it will never be *weaker* than the strongest source. The reason for a mixing function like that, is that you're pulling entropy from multiple sources. So if a single source is compromised (say mt_rand is compromised with a known seed value), it doesn't reduce the overall strength of the generated value. If the strongest source is compromised, it will still be at least as strong as the next weakest source... Anthony > Other than that, the SPL version seems like a nice idea. > > Regards > Peter > > -- > > WWW: plphp.dk / plind.dk > LinkedIn: plind > BeWelcome/Couchsurfing: Fake51 > Twitter: kafe15 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.14 and PHP 5.4.4 released!
Hello! The PHP Development Team announces the immediate availability of PHP 5.4.4 and PHP 5.3.14. The releases two security related issues and over 30 bugs. The release fixes two security issues: A weakness in the DES implementation of crypt() and a heap overflow issue in the phar extension. All users are adviced to update to PHP 5.3.14 or PHP 5.4.4! PHP 5.4.4: Release Announcement: http://www.php.net/releases/5_4_4.php Downloads:http://php.net/downloads.php#v5.4.4 ChangeLog:http://www.php.net/ChangeLog-5.php#5.4.4 PHP 5.3.14: Release Announcement: http://www.php.net/releases/5_3_14.php Downloads:http://php.net/downloads.php#v5.3.14 ChangeLog:http://www.php.net/ChangeLog-5.php#5.3.14 regards, Johannes, Stas and David -- 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?
* snip* >> Stas has the right approach, not only should the methods be simplified and >> platform/algorithm agnostic but have a proper salt built in (there are a >> few CSPRNG implementations around), I've seen salts used from numbers to >> md5's to just being skipped altogether. > > Well, just to be clear, a salt does not need a CSPRNG. All it needs to > be is reasonably unique. In fact, I wouldn't make it CS, as that would > deplete the available entropy in the system for CSPRNG generation. Whether or not a CSPRNG is needed depends on what you're doing, your needed level of security. Perhaps add a parameter to control this, so it would be possible to make use of this function even if you need the maximum level of security? If it's not available, the function should fail in some suitable fashion. *snip* > Or, we could implement a system like I did in > https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random > that follows RFC4086: http://tools.ietf.org/html/rfc4086#section-5.2 > Where it mixes together several sources of weak and moderate strength > PRNG... Will the entropy multiply by mixing sources? I.e. will the result be "more random"? Won't it just be as random as the most random source? Other than that, the SPL version seems like a nice idea. Regards Peter -- WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 -- 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?
Daniel,
> However, I'd like to throw in scrypt as well. Thoughts?
Yes, that's something to include for sure. I've actually been working
on the side on an implementation of scrypt to sit next to my pbkdf2
proposal as hash_scrypt (as the native function, so that it can be
used natively (without the salt generation component)...
> Stas has the right approach, not only should the methods be simplified and
> platform/algorithm agnostic but have a proper salt built in (there are a
> few CSPRNG implementations around), I've seen salts used from numbers to
> md5's to just being skipped altogether.
Well, just to be clear, a salt does not need a CSPRNG. All it needs to
be is reasonably unique. In fact, I wouldn't make it CS, as that would
deplete the available entropy in the system for CSPRNG generation.
So in practice, a normal PRNG will suffice. With that said, mt_rand()
is not enough. It should be a moderately good PSRNG. It just doesn't
need to be CS. If mcrypt is available, DEV_URANDOM would be a good
place to get entropy.
Or, we could implement a system like I did in
https://github.com/ircmaxell/PHP-CryptLib/tree/master/lib/CryptLib/Random
that follows RFC4086: http://tools.ietf.org/html/rfc4086#section-5.2
Where it mixes together several sources of weak and moderate strength
PRNG...
On another note, I had started an implementation of this yesterday. So
far, I see two "clean" ways of doing it. We could do it class based (I
put it on SPL because it's more of a library addition):
interface \SPL\Password {
public function hash($password);
public function verify($password, $hash);
}
class \SPL\Password\BCrypt implements \SPL\Password {
public function __construct($cost = 15){}
public function hash($password) {
// Work involving crypt()
}
public function verify($password, $hash) {
// Work involving crypt()
}
}
Or, a more procedural approach, with a single "dispatching" function
function password_hash($password, $algorithm = PASSWORD_BLOWFISH,
$options = array()) {
}
function password_verify($password, $hash, $algorithm =
PASSWORD_BLOWFISH, $options = array()) {
}
function password_register($algorithm_name, $hashFunc, $verifyFunc) {
}
The one big issue that I ran into was in registering a namespaced
class into SPL. The SPL class functions aren't designed to handle
namespaced classes as far as I could tell. So we'd have to make a
patch to that first to add macros to support namespaced code...
Thoughts?
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?
Hi Nikita, I think you might just get everyone behind this; easily! However, I'd like to throw in scrypt as well. Thoughts? Stas has the right approach, not only should the methods be simplified and platform/algorithm agnostic but have a proper salt built in (there are a few CSPRNG implementations around), I've seen salts used from numbers to md5's to just being skipped altogether. ~ Daniel Macedo
Re: [PHP-DEV] [DRAFT] RFC - hash_pbkdf2 addition
Simon, > I personally would rename the 2nd parameter to $data as this function is not > only meant for creating secure hashes from passwords. Well, I understand your sentiment. But PBKDF stands for Password Based Key Derivation Function. Even the spec calls that parameter password: PBKDF2 (P, S, c, dkLen) Options:PRFunderlying pseudorandom function (hLen denotes the length in octets of the pseudorandom function output) Input: P password, an octet string S salt, an octet string c iteration count, a positive integer dkLen intended length in octets of the derived key, a positive integer, at most (2^32 - 1) * hLen Output: DK derived key, a dkLen-octet string So in this case, I feel calling the parameter "password" is justified... Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
Am Mi, 13.06.2012, 00:06 schrieb Nikita Popov: > That's how it is currently implemented. The generator backs up the > current execution context (execute_data, CVs, Ts), pushed stack > arguments and several executor globals. When the generator is resumed > everything is restored and it continues to run as if nothing happened > :) > > Doing context switching using setjmp family functions seems to me like > a really scary thing to do. I don't think that one can do that in a > sane way. I see what you mean but would disagree :) . Working with the php context only brings only a structural advantage. IMHO practically it's comparable with a pure php implementation. Where it might be ok for generators as the lexer must be touched anyway, I was talking about the base for spl_coroutine mentioned by Laurence. Also, some sane implementation do exist. Not only oss (see the links in my previous mail), but even in the premium products, just to be said. Of course it's complex, but doable, may be not right at the first step. Anatoliy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] RFC - hash_pbkdf2 addition
Hi, Anthony I personally would rename the 2nd parameter to $data as this function is not only meant for creating secure hashes from passwords. Bye Simon On Thu, Jun 14, 2012 at 4:00 AM, Anthony Ferrara wrote: > Hello all, > > I've written up a quick draft version of an RFC for pull request 105 ( > https://github.com/php/php-src/pull/105 ), to add hash_pbkdf2() to the > core implementation. Please give it a look and provide some feedback, > so that this can move into discussion as a more defined proposal. > > https://wiki.php.net/rfc/hash_pbkdf2 > > Thanks, > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
