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

Paragon Initiative:
Choosing the Right Cryptography Library for your PHP Project: A Guide
Nov 16, 2015 @ 12:19:16

On the Paragon Initiative blog there's a new article posted that wants to help you pick the right cryptography library for your project and your needs. In it they make several recommendations and the benefits of each.

Cryptography is not magic. Adding encryption to an application doesn't automatically make it secure against attackers (especially if you aren't authenticating your ciphertext). But if you do need it to satisfy a business need, conventional wisdom states that you almost certainly should not try to design your own cryptography. Instead, you should use an existing cryptography library.

Okay, great. So which PHP cryptography library should I use? That depends on your exact requirements. Let's look at some good choices. (We won't cover any terrible choices.)

The three libraries they recommend are: Halite, the Libsodium library, the Defuse Security PHP Encryption library and the PHPSecLib library. For each they make some recommendations on places they may be most effective and how it using them relates to passwords (hint, hashing over encryption).

tagged: cryptography library choice hailite libsodium phpencryption phpseclib password

Link: https://paragonie.com/blog/2015/11/choosing-right-cryptography-library-for-your-php-project-guide

Is your database password stored safely?
Sep 08, 2015 @ 11:48:18

The Fortrabbit blog has a post that want to help you store your database password securely and away from prying attacker eyes. While they use the example of a a database password, credentials for just about any other service could be protected the same way.

How do you protect your access data? Your sensitive secrets, basically anything your PHP application uses to authenticate or authorize with other services such as databases, caches, cloud storages, image resize services, transactional mail providers. All of them. Where do you put this — easily accessible while in development and secure for production?

They start by pointing out a few places where they should not be stored: in your code, in a version control system or in an environment variable (plain text). Instead, they suggest using a combination of a secret key that's configured in the application and encrypted versions of the values in environment variables. Some code is included showing how to set this up in a Laravel-based application, but the principle can be applied independent of the framework too with some other simple tools. They end the post with some links to other articles including a "considered harmful" piece reinforcing their methods.

tagged: credential protection password database tutorial encryption environment variable

Link: http://blog.fortrabbit.com/how-to-keep-a-secret

Paragon Initiative:
Secure Data Encryption in Web Applications with PHP
Aug 03, 2015 @ 10:58:47

The Paragon Initiative has posted a new white paper to their site covering secure data encryption in web applications written in PHP. The paper covers high level topics and offers some more practical suggestions about tools and guides to use in protecting your applications.

Encrypting network communications is absolutely essential to the security of anyone who wishes to use your website or application. The standard and most reliable form of network encryption is called Transport Layer Security (TLS), which was preceded by and older standard called Secure Socket Layer (SSL).

Websites that use SSL or TLS are accessible by typing https://domain.com into your browser instead of just http://domain.com. Consequently, the shorthand way to refer to HTTP over TLS is simply HTTPS. Contrasted with network cryptography, storing sensitive information is a much more challenging and interesting problem to solve, and is the focus of this paper.

Among the topics covered in the white paper are things like:

  • The flow of a HTTPS request (and if it's "fast" or not)
  • Secure password storage and handling
  • On-demand encryption/decryption
  • Cryptography library recommendations
  • Using asymmetric cryptography with public and private keys

They also point to this curated list of resources to help you learn more about general web application security including cryptography.

tagged: secure application cryptography https password library libsodium resources

Link: https://paragonie.com/white-paper/2015-secure-php-data-encryption

IBM developerWorks:
PHP renewed: Password security in modern PHP
Apr 17, 2015 @ 08:53:15

The IBM developerWorks site has a new tutorial posted talking about how PHP has been "renewed" in recent versions, more specifically in the password security department.

When PHP was first crafted in the mid-1990s, the term web application didn't even exist yet. Password protection, then, wasn't one of the features that the PHP creators devoted resources to. After all, you didn't need to worry about passwords when you used PHP just to put a site-visit counter or a date-modified stamp on your web page. But 20 years have passed, and now it's almost unthinkable to create a web application that doesn't involve password-protected user accounts. It's of the utmost importance that PHP programmers safeguard account passwords by using the latest and most secure methods.

The article goes on to talk about the importance of using secure hashing methods for password storage, the speed at which "cracking" programs can run and the use of "rainbow tables". It then gets into some of the older methods commonly used for password storage and protection and shows how to refactor them into the new password hashing functionality introduced in PHP 5.5.

tagged: password security hashing renewed modern language release

Link: http://www.ibm.com/developerworks/web/library/wa-php-renewed_2/index.html

Evert Pot:
The problem with password_hash()
Feb 25, 2015 @ 10:51:04

Evert Pot has shared some of his thoughts about why he has a problem with password_hash (and friends). His thoughts are initially about this particular feature but they're actually wider than that.

The initial introduction and rfc for these functions made me uneasy, and I felt like a lone voice against many in that I thought something bad was happening. I felt that they should not be added to the PHP engine. I think that we should not extend the PHP engine, when it's possible to write the same API in userland, or there are significant benefits to do it in PHP, such as performance. Since the heavy lifting of the password functions is done by underlying libraries that are already exposed to userland-PHP, it didn't make sense to me to expose it as well in the core.

He includes a list of things he sees as drawbacks for new C-based functionality in PHP including the fact that it extends the "PHP specification" and forces other projects to implement it (like HHVM). He does include a few positives, though, such as the increased visibility and legitimacy, but still thinks they don't outweigh the negatives.

tagged: password hash core language c implementation opinion userland

Link: http://evertpot.com/password-hash-ew/

The Code of a Ninja:
Salt, Hash and Store Passwords Securely with Phpass
Jun 16, 2014 @ 11:15:37

In this post to the CodeOfANinjs.com site, they walk you through password hashing, salting and storage using the PHPAss tool from OpenWall. The post itself is a bit older, but the content still provides a good example to teach the basics.

I think the main reason why we have to hash passwords is to prevent passwords from being stolen or compromised. You see, even if someone steal your database, they will never read your actual or cleartext password. I know that some PHP frameworks or CMS already provide this functionality, but I believe that it is important for us to know how its implementation can be made.

The tutorial shows you how to use the library and how to store the result in a simple "users" table in a MySQL database. The examples hash the password given from a simple form and use prepared statements (via PDO) to save it to the database. All PHP, HTML and CSS code you'll need - including the login form that checks the username/password - is included. There's also a few screenshots showing what the resulting forms and data should look like.

tagged: phpass tutorial hash salt password storage mysql user

Link: http://www.codeofaninja.com/2013/03/php-hash-password.html

Anna Filina:
Brute-force countermeasures
Jun 11, 2014 @ 10:09:10

In her latest post Anna Filina has made some recommendations of countermeasures you can use to help prevent abuse against brute force attacks in your applications. The recommendations aren't PHP-specific, but they're a good guide and a place to start.

Password brute-forcing refers to trying all password permutations until the attacker finds the right one. Here are some of the most common ways to mitigate that risk: increase the length of the password and increase the number of possible characters. [...] The human factor should not be ignored here. People often use letters in the beginning and numbers at the end.

She recommends a few other tactics to helping prevent the brute forcing including locking an account after a number of unsuccessful login attempts and requiring a CAPTCHA after a number of unsuccessful logins. She recommends not relying on a single method to help prevent this kind of attack, however. Multiple layers can only help, but be careful not to introduce too much complexity.

tagged: brute force attack countermeasure password

Link: http://afilina.com/brute-force-countermesures

Jordi Boggiano:
Authentication management in Composer
May 28, 2014 @ 11:07:35

Jordi Boggiano has posted about a new feature in Composer, the popular dependency manager for PHP, around the handling of authentication information.

Up until today if you run a home-grown package repository serving private packages it was quite a pain to use with Composer. You did not have efficient way to password-protect the repository except by inlining the password in the composer.json or by typing the username/password every single time. With the merge of PR#1862 and some further improvements you can now remove credentials from your composer.json!

The new functionality allows for the external storage of the credentials in a file, either globally of in one relative to the repository. He also includes the command you can use to configure and set these username/password combinations and have them stored in the "auth.json" file.

tagged: composer authentication management username password authjson json

Link: http://seld.be/notes/authentication-management-in-composer

Anthony Ferrara:
Why I Don't Recommend Scrypt
Mar 13, 2014 @ 10:11:59

Anthony Ferrara has a new post today looking at password hashing and a type of hashing that's beginning to get more attention in the PHP community - scrypt. However, he doesn't recommend it for production password storage and shares his reasoning why.

Scrypt was not designed for password storage. It was designed as a key derivation function for generating keys from weak material (namely passwords). The prime type of attack that scrypt is designed to defeat is ASIC based attackers. It is not designed to try to favor CPU over GPU (and thereby defeat GPU based attacks). It is this fact that we can leverage to gain an advantage when used as a password hashing mechanism.

He covers some of the basic design decisions that were made when scrypt was created. He also points out that none of the results of these decisions are strictly fatal, they just make it a bit weaker than something like bcrypt for password storage. He goes through the basic inputs scrypt requires and includes a quick snippet of code (not PHP, but easy to understand) showing its use. He talks about its "chain of 4 operations" and gets into what he sees as limitations: loop unrolling and the tune-able reduced memory usages. He finishes off the post mentioning that scrypt is still secure, but despite this he doesn't recommend it for password storage specifically.

tagged: scrypt recommend hashing password

Link: http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html

SitePoint PHP Blog:
Risks and Challenges of Password Hashing
Mar 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.

tagged: password hashing encryption challenge risk tutorial

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