Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Paragon Initiative:
Let's Re-Think Security Trade-Offs
Dec 16, 2015 @ 12:38:08

On the Paragon Initiative blog there's a post that suggests changing your thinking about security trade-offs, those concessions we make every day in the development choices we make around the security of our applications versus other concerns.

The theory goes: You cannot have perfect security against all possible threats all the time for free. Usually, we expect our applications to incur a cost (usually in terms of CPU, memory, or electricity usage) in order to be secure. It seems logically correct that, if you need more security, your cost must therefore be higher.

Fortunately, this is not always true! Sometimes, given a choice between two solutions, the more secure option costs less than the insecure one.

The article points out that what we think might be a "fair tradeoff" between two choices may only look as much on the surface. They give the example of random number generation and the speed involved in using the random functions versus the true CSPRNG in PHP 7 (or the compatibility library). The article also points out that even those in the security industry make these same kinds of decisions. Essentially they lesson they're trying to suggest is that trade offs in security are usually based on the wrong assumptions or a limited knowledge of the technologies offered.

And if you reach the point where you have to make a choice between a secure option and an insecure option that might be better by some other metric, make sure you actually document and measure this trade-off. You might find that the benefit of the insecure choice is negligible, and that you therefore should opt for security.
tagged: security tradeoff performance unfair expert libsodium assumption

Link: https://paragonie.com/blog/2015/12/let-s-re-think-security-trade-offs

Brandon Savage's Blog:
Peer Review: Looking At Abstraction - Redux
Sep 02, 2009 @ 11:46:24

Brandon Savage has posted his latest part of his "Peer Review" series. He takesa step back and looks at abstraction again, this time incorporating some of the suggestions other members of the PHP community gave based on the previous version.

This entry will focus on our use of the database, and specifically on the already_tweeted() method. This method has a number of problems, and while we’re focusing on the implementation of the database, it's important to note that we will also need to address some of the logic (which will be the next part of the series).

He looks at assumptions (how they can be bad), the use of an ORM layer to help negate some of the problems surrounding them and adding in some exceptions to properly handle issues that might come up.

tagged: review abstraction orm assumption

Link:

Keith Casey's Blog:
Bad Assumptions in Development
Jun 19, 2009 @ 12:04:28

No one's code is perfect, and if you think yours is - you're wrong. There'll always be something - might be logic errors or unhandled exceptions - that could cause issues later on. One of the worst problems, at least according to Keith Casey's recent post, is making too many assumptions.

In my opinion, the most annoying and worst for cleaning up the system are the functions/methods that make too many assumptions for you. It could be a variety of things - assuming a database connection, assuming what the output destination is, or assuming what the input is - but I most often see it in scrubbing/cleaning functions.

His example is a function that not only assumes that the type of input is correct but also returns the value via an echo rather than a return (despite the name of the function implying the second). As a follow-up, he also suggests that libraries/external tools don't make assumptions when it comes to stopping execution of the script either.

tagged: opinion development assumption

Link: