Slashdot Mirror
PHP Becomes First Programming Language To Add 'Modern' Cryptography Library In Its Core (bleepingcomputer.com)
An anonymous reader writes from a report via BleepingComputer: The PHP team has unanimously voted to integrate the Libsodium library in the PHP core, and by doing so, becoming the first programming language to support a modern cryptography library by default. Developers approved a proposal with a vote of 37 to 0 and decided that Libsodium will be added to the upcoming PHP 7.2 release that will be launched towards the end of 2017. Scott Arciszewski, the cryptography expert who made the proposal, says that by supporting modern crypto in the PHP core, the PHP team will force the WordPress team to implement better security in its CMS, something they avoided until now. Additionally, it will allow PHP and CMS developers to add advanced cryptography features to their apps that run on shared hosting providers, where until now they weren't able to install custom PHP extensions to support modern cryptography. Other reasons on why he made the proposal are detailed here. Arciszewski also says that PHP is actually "the first" programming language to support a "modern" cryptography library in its core, despite Erlang and Go including similar libraries, which he claims are not as powerful and up-to-date as PHP's upcoming Libsodium implementation.
I'll stick to every other language that has had libsodium bindings for a while now.
Your hair look like poop, Bob! - Wanker.
I don't even understand the point of the claim. So the interpreter has a baked-in crypto library? And how is that different than simply #including a crypto library, which has the added bonus that you can pick any number of crypto libraries.
The world's burning. Moped Jesus spotted on I50. Details at 11.
I remember when Java was the first language to do this. Shortly after that, C# was the first language to do this. Now PHP is the first language to do this. So who will be the next one to do it first?
Except for objects, where a === b is true only if a and b are the same object. Such a beautifully designed language.
Any language where the default equality comparison operator is *true* given two string-type variables with values "0E54321" and "0E12345" is not a cryptographically secure language. In fact there is a nonzero chance of the default equality operator returning true between two different MD5 or SHA256 hashes if they happen to fall into a hexadecimal form that is all digits except for one E or F.
Technically, that (in itself) doesn't necessarily mean that the built-in cryptography nor the language itself are inherently insecure. In theory, that is, provided you understand the language and use it correctly.
And that's the problem. Because in practice, PHP's design philosophy of trying to be clever- often too clever by half- when it comes to comparisons, equality, automatic coercion, data types, etc. etc. too often gives unpredictable and unexpected results from people who weren't aware of that behaviour.
You absolutely do *not* want any risk of this happening when you're designing a system that has to be secure. You want boringly explicit and utterly predictable data and type handling.
My prediction is that far, *far* more security holes will be down to bugs caused by unforeseen subtle aspects- i.e. pitfalls- of PHP's type handling and equality behaviour (etc.) in the apps using it rather than bugs in the cryptographic module itself.
PHP being a language more favoured by inexperienced users, this is likely to be made far worse. Expect lots of newbies with misplaced confidence designing what they think are "secure" apps that are in fact full of holes- either because they've misused or misunderstood the cryptographic module, or because they've overlooked some basic aspect of computer security elsewhere (e.g. failure to parse input securely) that makes the use of cryptography irrelevant.
And those are the sorts of mistakes newbies would make when using any language- with PHP's language design issues on top of that, it has the potential to be far worse.
So, yeah. I trust that the module will be secure. The main problems- I guarantee- will be caused by caused by overlooked (or not known about) aspects of PHP's too-clever-by-half data handling (in client apps using it) leading to exploitable holes, and by the fact that too many of PHP's newbie-skewing userbase will overconfidently assume it makes their apps foolproof while using it incorrectly and ignoring security holes elsewhere that make it redundant.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
...which effectively prevents me from updating it. Great choice for a security library guys.