News Feed
Sections




News Archive
feed this:

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

Allan MacGregor:
Swiss Army Knife Syndrome
May 21, 2014 @ 10:47:12

In his latest post Allan MacGregor talks about something commonly referred to as Swiss Army Knife Syndrome, a common problem in software development where features and functionality are added "just in case" and aren't needed.

The inspiration for the "Swiss Army Knife Syndrome" came from my frustration in dealing with project managers, clients, and even other developers, that think in too much of a narrow, particular way. I call it the "Swiss Army Knife Syndrome". [...] The term 'Swiss Army Knife' is often used to describe a collection of useful items or tools that are able to perform well in multiple scenarios. While this may be useful, there are risks to be aware of as well.

He points out that not only can software with unnecessary features become cumbersome over time, it can also have the potential for being mostly useless (and unmaintainable). He suggests a few ways the syndrome can show up in your process including scope creep, early optimization and anything that assumes that "more features" is the same as "more value" in the product. In his opinion, software with a clear purpose and that does its job well is more valuable that one packed with features, especially ones no one wants to use.

0 comments voice your opinion now!
swissarmy knife syndrome features scope risk

Link: http://coderoncode.com/2014/05/20/swiss-knife-syndrome.html

SitePoint PHP Blog:
Risks and Challenges of Password Hashing
March 11, 2014 @ 09:31:45

The SitePoint PHP blog has a new post today about the challenges of password hashing and some of the common risks that can come with it. It's a continuation of a previous article about the actual techniques for hashing in PHP.

The fact that the output of a hash function cannot be reverted back to the input using an efficient algorithm does not mean that it cannot be cracked. Databases containing hashes of common words and short strings are usually within our reach with a simple google search. Also, common strings can be easily and quickly brute-forced or cracked with a dictionary attack.

He points to a video demonstrating a method for getting the password data and why just salted hashes aren't a secure method for storing this information. He mentions a "randomness issue" (and PHP's rand function). Instead, he shows an example with openssl_random_pseudo_bytes o pull a chunk of randomized data. He then talks some about password stretching using the PBKDF2 handling in PHP. Finally, he goes past the hashing and gets into encryption, mentioning "password tweaking" as an alternative to generating a single key for every user.

0 comments voice your opinion now!
password hashing encryption challenge risk tutorial

Link: http://www.sitepoint.com/risks-challenges-password-hashing/

The Nerdery:
Why Most Stories About WordPress Security Are Wrong
September 12, 2013 @ 09:18:55

On The Nerdery's blog today there's a new post suggesting that most of the reports of WordPress' insecurity are wrong and they're going to set the record straight.

I have often heard the remark "WordPress is insecure!" My response is "Where did you hear that?" and "When did you hear that?" [...] WordPress core is, in fact, very secure, just as secure as any other Content Management System, just as secure as any other software suite or Operating System. Security issues most often arise from administrators and users. In other words, you are the weakest link.

They suggest that between the high-profile nature of WordPress and the constant (sometimes wrongful) warning being put out there about its security, people perpetuate the message sometimes unknowingly. Besides the human element being the largest risk, they also point out a few others including issues around shared hosting and the availability of easy-to-find tools to exploit flaws. They talk about a brief history of the WP core security and how they define the real security of a product - how quickly it responds to security issues. They also include a few suggestions for you to help harden your own WP installation.

0 comments voice your opinion now!
wordpress security risk history wrong story advice

Link: http://blog.nerdery.com/2013/09/why-wordpress-security-stories-are-wrong/

Snipe.net:
Failing Well Managing Risk in Web Applications
August 02, 2013 @ 09:27:38

In this new post Snipe looks at something that we, as web developers, don't seem to think about too much when designing our applications and architectures - risk (and how to manage it).

When I talk about risk as it relates to web applications, people usually assume I'm talking about hardening applications from hackers, spammers and other ne'er-do-wells. While malicious attacks are absolutely a non-trivial part of risk management, there's a lot more to it that's just as important.

She introduces some of the basic concepts behind risk management, specifically as it relates to web applications. She points out that it's not always an external threat you'll need to worry about either. Sometimes its your own development group that introduces bugs or something that makes the system come to a crashing halt. She recommends starting all projects "risk first" and include it into your planning process. She shows how to create a "risk matrix" to get insight into the problem and the data that should be on it.

Finally, she reminds you of a few good rules (including "keep your systems simple") and that analyzing risk doesn't have to be a boring process. Figuring out where things will break, how to break them and what happens when they do can be an interesting process.

0 comments voice your opinion now!
application risk management mitigation introduction

Link: http://www.snipe.net/2013/08/failing-well-managing-risk-in-web-applications

Zend Developer Zone:
What is your project's Bus Factor?
January 05, 2011 @ 12:47:29

In this new post to the Zend Developer Zone Cal Evans asks open source projects and companies alike - "what's your bus factor?"

In a previous job I had it was the "Beer Truck" factor (you can see where our heads were) but the common term these days is Bus Factor. Put simply, it's your projects exposure to the risk of key members disappearing tomorrow. To be crude if your project can't survive a key member of your project being hit by a bus tomorrow then you have a very high "Bus Factor".

He points out that it's not just an open source problem, but something that companies should take into consideration as well. Technology groups are especially bad about having single developers consistently working on certain parts of a system. If the time comes that that developer can't do the work (bus, leaves company, etc), how much of an impact will that have? Cal suggests a few ways that it can be avoided including spreading the work around a bit more, moving developers to places in the codebase they don't know and avoiding the "black boxes" created by certain developers.

0 comments voice your opinion now!
busfactor opinion risk developer survival



Community Events





Don't see your event here?
Let us know!


symfony unittest package zendserver series deployment introduction interview install library podcast framework language laravel bugfix opinion community release api update

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework