Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Simple, secure cryptography lands in PHP 7.2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Simple, secure cryptography lands in PHP 7.2

joepie91joepie91 Member, Patron Provider

Some excerpts of the most important points:

The goals were as follows:

  1. Get the sodium extension into the PHP core in version 7.2.

  2. Write a pure-PHP polyfill that supports all the way back to PHP 5.

I'm happy to report that, halfway through 2017, both efforts have been successful.

[...]

The pull request was merged yesterday, thereby cementing Sodium's status as a core extension to the next version of the PHP programming language. This means several huge, practical wins for developers:

  1. Simple and secure public key cryptography is baked in, using Diffie-Hellman and digital signatures over Curve25519.

    • The old standby, OpenSSL, had public key cryptography interfaces that were vulnerable to a 1998 vulnerability by default, that not even Zend used correctly the first time around.
  2. Interoperability with other protocols that use NaCl or libsodium. (e.g. Noise)

  3. The ability to wipe memory buffers for the first time since PHP's inception.

  4. Encryption algorithms that are not vulnerable to side-channels in the absence of special hardware.

  5. Authenticated encryption, almost exclusively.

I wrote a libsodium quick reference guide last month to demonstrate how the new PHP extension should be used to solve common problems.

[...]

PHP 7.2 is scheduled to be released on 2017-11-30 (November 30, 2017).

[...]

The other part of the equation was to build a pure-PHP implementation of the cryptography offers. We tagged the first version 1.x release of paragonie/sodium_compat last month, and are currently focusing on making sure we're forward compatible with PHP 7.2 and supporting 32-bit operating systems (which was missed during our beta testing because most of the world has moved onto 64-bit hardware).

[...]

We've proposed the start of a plan to make Composer, the package manager used by the PHP community, use Chronicle and libsodium to offer secure code delivery by streaming software release metadata into a dedicated Chronicle instance.

Source: https://paragonie.com/blog/2017/07/it-turns-out-2017-is-year-simply-secure-php-cryptography

My personal dislike of PHP aside, this is a pretty important step in increasing internet-wide security, especially in widely deployed off-the-shelf PHP software.

The article also contains some advice on how to contribute and help support widespread deployment of the new cryptography API. It's definitely worth a read if you spend any amount of time developing PHP or writing articles/tutorials about it.

«1

Comments

  • bsdguybsdguy Member

    Judging from what I saw on your website you seem to have a quite good understanding of security and crypto; there are some weaknesses like e.g. "the difference between IVs and nonces is subtle" (it isn't) or "intentionally slow password hashing" (time is just one factor, memory cost is existential, too) but those can be easily forgiven, particularly when considering the audience.

    But the title of this thread gets a sarcastic LOL. "security" and "php" in one sentence, my ass. Oh, and good luck implementing NaCl in php (rather than just making a binding); that's about as reasonable as implementing a good door lock using rabbit poop.

    The positive: sodium was a smart choice. If you made the binding properly (didn't check), compliments.

  • jhjh Member

    My guess is that the volume of real world problems caused by using PHP are dwarfed by the volume of real world problems caused by the average developer writing bad PHP code.

    This is great news.

    Thanked by 2jar WSS
  • joepie91joepie91 Member, Patron Provider

    @bsdguy said:
    Judging from what I saw on your website you seem to have a quite good understanding of security and crypto; there are some weaknesses like e.g. "the difference between IVs and nonces is subtle" (it isn't) or "intentionally slow password hashing" (time is just one factor, memory cost is existential, too) but those can be easily forgiven, particularly when considering the audience.

    But the title of this thread gets a sarcastic LOL. "security" and "php" in one sentence, my ass. Oh, and good luck implementing NaCl in php (rather than just making a binding); that's about as reasonable as implementing a good door lock using rabbit poop.

    The positive: sodium was a smart choice. If you made the binding properly (didn't check), compliments.

    Not sure why you're assuming that to be my post. I didn't implement any of that, somebody I know did - I'm just posting it here as news, as I usually do when something might be interesting to people here but isn't getting a lot of attention (yet).

    And scoff at "PHP and security in the same sentence" all you want, but the reality is that PHP applications are widely deployed and are not going to go away for the foreseeable future. While I consider PHP to be full of footguns, and too difficult to write correct and secure code in (which is why I don't recommend people to use it), that doesn't mean that there are no easy ecosystem security wins to be had by offering things like this in core.

    At the very least, it could get people signed updates for major off-the-shelf applications and frameworks, something that is currently missing and a ticking timebomb.

    I'm reasonably confident that sodium_compat is implemented correctly. It's maintained by one of the few people that actually understands PHP well enough and is rigorous enough about writing secure code, to implement something like this correctly. In any case it's just a compatibility mechanism for PHP <7.2, and ideally the core implementation would be used. I believe there's a PECL package for it, too.

  • bsdguybsdguy Member

    @joepie91 said:
    Not sure why you're assuming that to be my post. I didn't implement any of that, somebody I know did ...

    OK, not "you" but "the team who wrote that".

    And scoff at "PHP and security in the same sentence" all you want, but the reality is that PHP applications are widely deployed and are not going to go away for the foreseeable future....

    If you talk about the (very few) php "developers" who care shit plus have a brain what you say might be realistic (but one could reasonably argue that people who care don't use php in the first place).

    Will those widely deployed php applications be enhanced using the php sodium binding? We'll see. I have doubts.

    As for the proper implementation of a binding I'm not too worried. The people who did it seem to understand their stuff and sodium is anyway meant to be easy.

    What I would be worried about (if I cared a rats ass about php and php "developers") is the plan to implement sodium in php itself (instead of just making a binding). I'm quite confident that, if it can be done at all in php, then php quirks, bugs, and problems will create all sorts of funny trouble.

    I have implemented and ported crypto myself and I used real languages (like C and Ada) and encountered lots of mines (e.g. how a language/compiler deals with unsigneds, modulo arithmetic, operators being implemented as functions, etc). Implementing crypto in php isn't something I'd like to touch with a pole.

    Well, whatever. Probably one should be happy about just anything that makes the clusterfuck called php a bit less creepy and lousy.

  • bsdguy said: Well, whatever. Probably one should be happy about just anything that makes the clusterfuck called php a bit less creepy and lousy.

    What programming/scripting language would you suggest for powering the back end of web sites, that can be developed in a reasonable time frame?

  • bsdguybsdguy Member

    @ricardo said:

    What programming/scripting language would you suggest for powering the back end of web sites, that can be developed in a reasonable time frame?

    Short answer (tongue in cheek): anything but php.

    More serious answer: come on, there's plenty available nowadays. Today one can build dynamic websites in pretty much any language one likes.

    In case your question wasn't political/rethorical: My advice - at least for anything commercial or otherwise dealing with sensitive data - is to use a typed language; preferably statically typed but inferred types is good enough for many applications.

    There is, for instance, java and a plethora of derivates (true, java isn't exactly secure either but then we're not talking about highly secure site but about not-utterly-crappy ones).

  • @ricardo said:

    bsdguy said: Well, whatever. Probably one should be happy about just anything that makes the clusterfuck called php a bit less creepy and lousy.

    What programming/scripting language would you suggest for powering the back end of web sites, that can be developed in a reasonable time frame?

    Ruby, python, and node are all popular.

  • YuraYura Member

    @Jonchun said:
    Ruby, python, and node are all popular.

    Node is a language, PHP is secure now. Wow, so much news today.

    Thanked by 1Aidan
  • bsdguybsdguy Member

    @Jonchun said:

    @ricardo said:

    bsdguy said: Well, whatever. Probably one should be happy about just anything that makes the clusterfuck called php a bit less creepy and lousy.

    What programming/scripting language would you suggest for powering the back end of web sites, that can be developed in a reasonable time frame?

    Ruby, python, and node are all popular.

    nodejs is chique but I consider it to be kind of a more modern php (javascript is an utterly poor choice). ruby and python are much better but not really great choices either.

    For a mom and dad web or "pictures of my cats" site, well, who cares. But when sensitive data such as customer or, god forbid financial, data are involved none of the widely used scripting languages (almost all of which are dynamically typed) is adequate.

    And btw. why does "reasonable time frame" always come up? As if that were the only important criterion.

  • Build half of an application on PHP. Am using phpseclib for communication with server but thinking to learn node and use agent instead. Or shall convert whole app to nodejs or keep everything with php? So confused.

  • It was somewhat rhetorical. I don't see an issue with PHP per se, that'd be more to do with green programmers being able to mistakes easier and in more ways. I think it gets a harder time than it deserves because of this.

    Before PHP there was Perl and now there's Ruby/NodeJS.

    Python, is probably what I'd choose over the rest.

    Personally I use PHP for a website backend and anything that's performance critical is written in C (insert obligatory caveat about memory management). The argument is really about careless programming and human error, and if you believe that as a programmer you're more likely to make mistakes using one, then fine.

    And btw. why does "reasonable time frame" always come up? As if that were the only important criterion.

    Usually time and money are the constraints. You could write exactly the same program in half a dozen languages... some may be more performant than others.

    Thanked by 1netomx
  • joepie91joepie91 Member, Patron Provider
    edited July 2017

    bsdguy said: If you talk about the (very few) php "developers" who care shit plus have a brain what you say might be realistic (but one could reasonably argue that people who care don't use php in the first place).

    Will those widely deployed php applications be enhanced using the php sodium binding? We'll see. I have doubts.

    If it's easy enough? Yes. The problem is that a lot of developers are willing to invest the time into making their thing look secure, but not into actually making it be secure. If the 'barrier to entry' for Actual Security is low enough, and it looks marketable enough, then it will see adoption. This is partly technical, partly marketing.

    bsdguy said: What I would be worried about (if I cared a rats ass about php and php "developers") is the plan to implement sodium in php itself (instead of just making a binding). I'm quite confident that, if it can be done at all in php, then php quirks, bugs, and problems will create all sorts of funny trouble.

    PHP quirks are for the most part consistent. That is, they're massively confusing to a developer and it's easy to fuck things up, but things rarely change behaviour between PHP versions anymore. It's not something I'd be too worried about anymore, assuming that the person implementing it in PHP is familiar with the caveats (which the author of sodium_compat certainly is).

    bsdguy said: Well, whatever. Probably one should be happy about just anything that makes the clusterfuck called php a bit less creepy and lousy.

    That's more or less how I'm looking at this development as well.

    bsdguy said: nodejs is chique but I consider it to be kind of a more modern php (javascript is an utterly poor choice).

    Not really true. There are some issues with the security process in Node core, but overall, it's a healthy ecosystem where it's hard to screw things up. JS as a language has way, way less warts than PHP as well, and I'd say even less warts than Perl and Ruby.

    Sure, if you try to write JS like you write other languages, you're going to have a problem, because JS is just fundamentally designed differently from most popular languages, it being half functional in nature. But that's going to result primarily in functionality bugs, not security bugs - and in the end it's an education problem, not a language design problem. Modern JS is surprisingly well-designed, when you really look into it.

    That's not to say that there are no issues at all, but they are relatively limited and very much fixable in the long term, unlike PHP where many of the issues are inherent in the design of the language and cannot be fixed without breaking backwards compatibility.

    bsdguy said: And btw. why does "reasonable time frame" always come up? As if that were the only important criterion.

    Not the only important criterion, but it's an unnegotiable business requirement that needs to be met in many cases. It's certainly a big relevant factor.

    bsdguy said: But when sensitive data such as customer or, god forbid financial, data are involved none of the widely used scripting languages (almost all of which are dynamically typed) is adequate.

    There's no such thing as a "scripting language", that's pretty much just a derogatory term for something along the lines of "not like C++ / C / Java". There's absolutely no technical definition for it.

    And please don't come up with "well, it's interpreted and that makes it a scripting language" either - aside from a language being 'interpreted' being determined by the runtime and not the language, almost no modern runtime runs code in a purely interpreted manner anymore. It's a meaningless distinction.

    (Static typing also isn't anywhere near as important as you're making it out to be. The vast majority of real-world bugs would not have been prevented by static typing, and especially taking into account more generic good practices, the value of static typing is extremely questionable while the cost is often significant.)

    @jetchirag said:
    Build half of an application on PHP. Am using phpseclib for communication with server but thinking to learn node and use agent instead. Or shall convert whole app to nodejs or keep everything with php? So confused.

    Whatever you do, don't combine languages if you can at all avoid it. Tying together two parts of an application in different languages creates a considerable surface for things to go wrong, and will often be far more difficult than writing the entire thing in a single language.

    PHP has an inherent limitation in its design in that it's unsuitable for long-running process, so if that's what you need for any reason (remote agents, WebSockets, etc.), then go with something that isn't PHP, and build your entire application with it if possible.

  • bsdguybsdguy Member

    @ricardo said:
    The argument is really about careless programming and human error, and if you believe that as a programmer you're more likely to make mistakes using one, then fine.

    With that view you are gravely mistaken. Even very experienced developers who work carefully make many errors. One major reason is that - unlike computers - humans aren't good at high complexity and many, many details.
    Example: Even quite experienced programmers make quite many (strikingly simple) errors such as buffer overflows, illegal array indices, etc.

    That's why strict languages are so valuable: errors are caught early.

    And btw. why does "reasonable time frame" always come up? As if that were the only important criterion.

    Usually time and money are the constraints.

    So? The assumption "easy language allowing quick development equals low costs" is * proven* to be wrong.

    Studies clearly show that costs increase along the stages. An error found early is cheap. The same error found only in unit testing incurs multiple times the costs. An error in the next stage, debugging, is typically about 10 times more expensive to repair than one found in unit testing. And finally, once the product is shipping (or in production) repairing errors is insanely more expensive. And we are not even yet talking about costs of damages.

    Your equation is true only in (the typical php) cases along the line "I want something that looks useable and I don't care shit about reliability or safety".

    If the target, however, is "we need an application that meets reasonable standards of quality and safety" - as it certainly should be with many web applications dealing with sensitive data - then even developing in Ada (which is considered unsurmountably hard for most developers) is much cheaper than php or js.

    Granted, most applications don't need the highest level of quality and safety. For those a middle ground, say Pascal or Java, is sufficient - and much cheaper overall that js or php.

  • bsdguy said: One major reason is that - unlike computers - humans aren't good at high complexity

    Yah, I think this is where you're mistaken. Whatever language you use the equation is simple, you either assume the language and libraries you're given work, or you take it upon yourself to write something that works. This is why the likes of PHP is popular, because all that work is abstracted away from you into a simple function call.

    bsdguy said: So? The assumption...Granted, most applications don't need the highest level of quality and safety

    A lot of the time, a proof of concept is all that's needed.

  • joepie91joepie91 Member, Patron Provider
    edited July 2017

    bsdguy said: That's why strict languages are so valuable: errors are caught early.

    Just want to emphasize here that while that statement is true on the face of it, 'strict' does not just mean 'statically typed'; to be truly effective at catching errors early, it must be strict in many other respects as well. Rust is a good example of a language that does that. The typing model is not an especially significant factor in that.

  • bsdguybsdguy Member
    edited July 2017

    @joepie

    Pardon me, but your maniac urge to know everything better makes discussions with you quite tiring and meaningless.

    Statements like for example "static typing isn't worth a lot for quality code" are just ridiculous.

    Once again you obviously don't really know what you are opinionating about. Do yourself a favour and get informed. In pretty every sensitive field (finance, air traffic, both planes and control, medicine, etc) there are standards in place that exclude any not statically typed language (plus have rigorous demands for formal specs, modelling, implementation, and verification of those).

    Even Pascal, to name an example, and Scala often aren't meeting the requirements (let alone C or C++).

    But I guess they are all just cluelessly wasting hundreds of millions of $ and only joepie has the wisdom ...

  • bsdguybsdguy Member

    @joepie91 said:

    bsdguy said: That's why strict languages are so valuable: errors are caught early.

    Just want to emphasize here that while that statement is true on the face of it, 'strict' does not just mean 'statically typed'; to be truly effective at catching errors early, it must be strict in many other respects as well. Rust is a good example of a language that does that. The typing model is not an especially significant factor in that.

    "strict" necessarily includes static types. And rust is a lousy example (but one that many without expertise in the field love to come up with). I do not know of a single case in sensitive areas (see above) where rust was considered, let alone accepted. Rust is hardly more than an attempt to create a kind of C without the worst clusterfucks.

  • joepie91joepie91 Member, Patron Provider
    edited July 2017

    @bsdguy said:
    @joepie

    Pardon me, but your maniac urge to know everything better makes discussions with you quite tiring and meaningless.

    Statements like for example "static typing isn't worth a lot for quality code" is just ridiculous.

    Once again you obviously don't really know what you are opinionating about. Do yourself a favour and get informed. In pretty every sensitive field (finance, air traffic, both planes and control, medicine, etc. there are standards in place that exclude any not statically typed language (plus have rigorous demands for formal specs, modelling, implementation, and verification of those).

    Even Pascal, to name an example, and Scala often aren't meeting the requirements (let alone C or C++).

    But I guess they are all just cluelessly wasting hundreds of millions of $ and only joepie has the wisdom ...

    I'm not really interested in appeals to authority. There are many reasons why procedures may be in place, and nowhere near all of them are for rational, technical reasons. The primary concern of these industries is not to prevent bugs; it's to reduce liability, and that is often a partly political process.

    If you wish to claim that static typing, in and of itself, provides meaningful value to software projects, to a degree that it makes sense considering the business tradeoffs and other options available to a software developer... then provide a technical rationale as to why that is.

    Here's the technical rationale about why it doesn't provide meaningful value in the bulk of cases: the vast majority of real-world bugs are not type bugs. By far the biggest category of value-related bugs is "a mix-up of two values of potentially the same type but with different semantics", which static typing will not protect you from.

    Then consider one of the other options: writing small, modular code by default, without reassigning variables, and with one responsibility per function/module/class/what-have-you. This solves the "mixed up values" problem, and prevents the bulk of typing bugs (because typing errors are just a subset of value errors), at effectively no extra cost.

    Compare the two, and you have the following options:

    1. Only do static typing. This means you're not protected from value mix-ups. Considerable amount of work involved, especially because it becomes expensive to design abstractions. Let's say this covers 100% of type errors and 0% of value mix-ups.
    2. Only do modular code. This means you're protected from most value mix-ups and type errors - say 99% of value mix-ups and 99% of type errors.
    3. Do both static typing and modular code. Catches slightly more type errors than option 2, but requires all the work and drawbacks of option 1, while gaining very little protection in addition to what you get from option 2 - 99% of value mix-ups and 100% of type errors, which is only slightly better in the "type error" area.

    The problem here is that you're looking at strict typing and its value in isolation, not considering whether the same benefits can be obtained in a different, less expensive manner. Does it make sense in critical scenarios to go for the last 1%? Yes. Does it make sense to do so for the average application? Almost certainly not.

    bsdguy said: "strict" necessarily includes static types.

    And is a relatively insignificant part of it, mostly as a building block for other strictness measures.

    bsdguy said: I do not know of a single case in sensitive areas (see above) where rust was considered, let alone accepted.

    This surprises you? Like I said, liability reduction is the name of the game, and nobody wants to be responsible for approving a thing that's only been around for a few years. That doesn't say anything about the quality of its design, however.

  • ricardoricardo Member
    edited July 2017

    bsdguy said: "strict" necessarily includes static types

    Though with some simple wrappers, you can achieve the same thing in any language. It's just one layer of sanity checking that is abstracted away from you. To me, I'd always considered it as a performance gain rather than a security feature.

    @bsdguy your frame of reference seems to be mission critical software written for a company with a small acronym. Surely you appreciate that isn't the criteria across the whole spectra of 'reasons to write code'. Though, if you're just talking about a theoretical ideal, where the goal is perfect, most-secure, best-performing code... sure.

    joepie91 said: Then consider one of the other options: writing small, modular code by default, without reassigning variables, and with one responsibility per function/module/class/what-have-you. This solves the "mixed up values" problem, and prevents the bulk of typing bugs (because typing errors are just a subset of value errors), at effectively no extra cost.

    Indeed.

    Thanked by 2rincewind vimalware
  • raindog308raindog308 Administrator, Veteran

    bsdguy said: Pardon me, but your maniac urge to know everything better makes discussions with you quite tiring and meaningless.

    image

  • netomxnetomx Moderator, Veteran

    I used php and c++ for a backend fpr an automation process... I feel dumb now:(

    Thanked by 1Janevski
  • In my opinion NodeJS crypto is the best just make API to work around.

  • @bsdguy You are certainly knowledgeable; no denying that. I couldn't help but to point out that you're being a d*ck. If @joepie91 isn't creating content that you approve of, why don't you create some yourself? I mean, you've been fighting with him anyway, and you're explicitly telling Joe that he's hard to talk with.

    Think about the perspective everyone else has I certainly don't see anything wrong with posting some news (whether it be good practice or not). I don't think anyone intended to transform this thread into some shitstorm where you tried to prove that this is insecure, or the language itself. If you're so passionate about not using PHP, don't use it. Hell, WHMCS is built on it.

    What I'm saying is (tl;dr): don't be such a dick. Even if you don't necessarily like something, it's not your job to criticize and (basically) put down someone because of what you feel.

    Thanked by 3netomx Lee vimalware
  • LeeLee Veteran

    One of the hardest challenges to solve for the PHP ecosystem is the high ratio of insecure to secure tutorials and example code on the Internet.

    Aint that the truth..

    Thanked by 1Aidan
  • bsdguybsdguy Member
    edited July 2017

    @doghouch said:
    I certainly don't see anything wrong with posting some news (whether it be good practice or not).

    So? Just look at my first post. It was rather friendly.

    If you're so passionate about not using PHP, don't use it. Hell, WHMCS is built on it.

    So? Their luck that there wasn't yet a major security breach won't hold forever. Or maybe it already broke and was reduced by the luck it didn't get publicly known.

    What I'm saying is (tl;dr): don't be such a dick. Even if you don't necessarily like something, it's not your job to criticize and (basically) put down someone because of what you feel.

    Is it your job to tell me your opinion or even to judge me? Nope. So what, we are not here to do our job, we're to discuss.

    And no, it's not about "feelings". It's about reality and facts. A propos facts: facebook who a) had a massive code base in php, b) had major security nightmares, c) had the money and the people to mitigate the nightmare ...

    created the "Hack" language, a php derivate. Later they even created their own VM.
    Let's have a look. What's one of the major differences? Bingo! It's static or quasi static (inferred) types. What a coincidence!

    P.S. I don't respond to joepie anymore (nor read his amateur musings) on the topic of security.

  • yomeroyomero Member

    Waiting for this at the Dotdeb repos for ease.

  • joepie91joepie91 Member, Patron Provider
    edited July 2017

    bsdguy said: And no, it's not about "feelings". It's about reality and facts. A propos facts: facebook who a) had a massive code base in php, b) had major security nightmares, c) had the money and the people to mitigate the nightmare ...

    created the "Hack" language, a php derivate. Later they even created their own VM. Let's have a look. What's one of the major differences? Bingo! It's static or quasi static (inferred) types. What a coincidence!

    Your problem is that you're looking at single, anecdotal incidents in isolation, and then extrapolating that to a general claim or causation, without ever actually building an understanding of why certain decisions were made and how things came to be.

    It's easy to "support" just about any claim if you selectively pick-and-choose evidence that fits your narrative. That doesn't make it a logically valid rationale - in fact, it's one of the more common fallacies.

  • sinsin Member

    yomero said: Waiting for this at the Dotdeb repos for ease.

    Why not just use deb.sury.org ? He's the official maintainer for Debian and he provides repos for 7.0, 7.1, and 7.2. Dotdeb has also said to use deb sury for PHP.

    Thanked by 2yomero MikePT
  • bsdguy said: Statements like for example "static typing isn't worth a lot for quality code" are just ridiculous.

    Can you prove this?

  • Nothing is safe on the internet

Sign In or Register to comment.