Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What PHP 5.5 might look like

nikic.github.com

Post reply on HN
Print view View original

81–90 of 139 posts

Re: What PHP 5.5 might look like

#81

Post by MarceloRamos »

Smerity wrote: post #77
geon wrote: post #60

Earlier quoted context omitted.

> I'm not sure why they're adding the array_column function Isn't the function call much more readable than the comprehension? At least as a beginner, I found the large set of built in functions to be one of the strongest points of PHP.

One major disadvantage with so many functions is the cluttered global namespace[1]. PHP only added namespaces in 5.3.0 and can't modularize their globals into namespaces without causing massive backwards compatibility problems. PHP is stuck with a polluted global namespace, I'd be wary of adding more. Mind you, I'm well aware that this feeling could just be as I'm primarily a Python coder -- in PHP, you perform array…

Yes what the code does is very clear, but the function call is even a level up clearer, maybe you don't want to know how it does it's job, you just want an array of values in a column (array_column(array, column)). Personally I like comprehensions, but I tend to disguise them behind a function, it's much more clear to me. (but if I need the code to be super fast, I avoid using an extra function.)

Re: What PHP 5.5 might look like

#82

Post by nieksand »

snorkel wrote: post #72

Conspicuously absent from PHP: array_copy() ... in order to copy-by-value on arrays containing references. Currently to do that you have to do a very fragile hack like this: $copy = array_flip(array_flip($original)); ... which is vulnerable to key-value collisions ... or you have to write your own homebrew array copy-by-value function.

Still ugly, but at least it won't crap out if your data has duplicate values:

    $copy = array_map( function($v) { return $v; }, $original );

Re: What PHP 5.5 might look like

#83

Post by warbiscuit »

DomBlack wrote: post #78
masklinn wrote: post #62

Earlier quoted context omitted.

> The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt…

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText); The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper. The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code. If your database is stolen,…

The most common pepper algorithm I've seen is doing e.g. "bcrypt(hmac_sha512(password, pepper), salt)" instead of "bcrypt(password, salt)". This has a number of advantages over working the pepper into the hash itself:

1) this wrapper can be applied to any hash scheme, regardless of it's internal structure or options.

2) it doesn't expose the pepper within the hash string.

3) brute-forcing the hash w/o the pepper means you're searching for the 64-byte binary string returned by hmac_sha512. whereas (assuming all inputs are ASCII) "md5(salt+pepper+password)" can still be brute-forced, just treat the pepper as part of the password you're looking for.

Re: What PHP 5.5 might look like

#84

Post by ChiperSoft »

debacle wrote: post #22
Spoom wrote: post #15

Earlier quoted context omitted.

I'm curious: Why do you think empty() should be deprecated? Do you think the same of isset?

http://www.zachstronaut.com/posts/2009/02/09/careful-with-ph... http://stackoverflow.com/questions/410002/fixing-the-php-emp... The behavior of empty is unreliable. isset is not ambiguous.

I could see it being depreciated for use on non-arrays, but at the moment the only other method of detecting an empty array is `!count($arr)`, which is significantly slower if the array isn't empty.

Ultimately this isn't a language issue, it's a training issue. If you're using empty in place of isset, you're doing it wrong, the both serve completely different purposes.

Re: What PHP 5.5 might look like

#85

Post by Tloewald »

geon wrote: post #60
Smerity wrote: post #6

The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…

> I'm not sure why they're adding the array_column function Isn't the function call much more readable than the comprehension? At least as a beginner, I found the large set of built in functions to be one of the strongest points of PHP.

If they're going to allow queries on arrays of lists -- not a bad idea -- why not simply implement a SQL subset? I can see a huge collection of new array functions...

Re: What PHP 5.5 might look like

#86

Post by masklinn »

DomBlack wrote: post #78
masklinn wrote: post #62

Earlier quoted context omitted.

> The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt…

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText); The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper. The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code. If your database is stolen,…

> Every hashing algorithm allows it, even bcrypt.

That is not the meaning I intended in my usage of the word "support", but if you equate "support" and "is compatible with", then this API also "supports" peppers, just as much as bcrypt does.

> md5($salt.$pepper.$clearText)

How cute, not just md5 but length-extension vulnerable MD5. I'd recommend not using that scheme for MACs (and more generally not using md5 directly, really, as there are precious few reasons to do so)

> The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper.

Which just happens to be the exact same way bcrypt's API works. Here's an idea: combine the pepper to the password (this is usually done through hmac), not the salt. That's how you use a pepper and remain compatible with the Modular Crypt Format.

> The whole point of a pepper is to keep a second salt out of the database [blah blah blah]

Contrary to your apparent belief, I am aware of what peppers are, how they are used and what they're supposed to do.

Re: What PHP 5.5 might look like

#87

Post by [deleted] »

DomBlack wrote: post #78
masklinn wrote: post #62

Earlier quoted context omitted.

> The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt…

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText); The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper. The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code. If your database is stolen,…

[deleted]

Re: What PHP 5.5 might look like

#88

Post by mikeash »

pbiggar wrote: post #69
mikeash wrote: post #46

Regarding the "constant dereferencing" proposal, how do you even make a language parser that can't apply array operations to literals in the first place? I'm trying very hard not to bash on PHP here, and this is a completely honest question. I can't figure out how you'd even go about breaking that if you wanted to. Anyone know the background there?

This would probably ban "4[5]" but not "$x = 4; $x[5]". PHP enforces a lot of things in the parser (as opposed to making bytecode and having a simple type checker). Instead of having a general "expression" type which can be dereferenced, they have different rules for scalars, strings, variables, function calls, etc. For a long time, you couldn't dereference the result of a function call, because the parser didn't all…

Enforcing it in the parser seems so horribly wrong. If you want to disallow stuff like 4[5] at compile time then you should do that in a separate pass on the AST, not in the parser itself. That's ought to be a semantic error, not a syntax error. Treating that separately would require all manner of special cases. But, I guess that must be what they do.

Re: What PHP 5.5 might look like

#89

Post by [deleted] »

DomBlack wrote: post #78
masklinn wrote: post #62

Earlier quoted context omitted.

> The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt…

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText); The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper. The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code. If your database is stolen,…

[deleted]

Re: What PHP 5.5 might look like

#90

Post by bnr »

DomBlack wrote: post #78
masklinn wrote: post #62

Earlier quoted context omitted.

> The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt…

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText); The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper. The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code. If your database is stolen,…

If the attacker has one known password in the database, finding the pepper has the same difficulty as finding one password in a DB without pepper.
Post reply on HN