On the Websec.io site there's a new tutorial posted showing a potential method for keeping secrets safe in PHP-based applications.

One of the most difficult things in any kind of application (not just web applications) is how to protect "secret" values. These values might be API keys, database passwords or even special bypass codes. Ideally, you're not having to define these directly in the application and can have them loaded from another source.

While a lot of the issues around protecting secrets can be removed by better secret handling, it seems like there's still always a need for some kind of secret value to exist in an application. Using this sort of pattern is, obviously, recommended against. The Common Weakness Enumeration database even has an entry specifically about it: CWE-798. Hard-coding credentials, especially plain-text ones, can be a huge risk if an attacker were able to somehow access the code and read them directly.

The post then goes on to talk about specific issues with secrets/credentials handling in PHP and some of the common approaches (mostly using a .env file). It covers some of the basics of using the phpdotenv package before getting into the encryption of the secrets it contains. It makes the recommendation of using an "Apache pull" method to pull in the encryption key when Apache starts, putting it into an environment variable and using the psecio/secure_dotenv library to work with the encrypted values.

The PHP Roundtable podcast, hosted by PHP community memeber Sammy K Powers, has posted its latest episode: Episode #68 - PHP's Dirty Little Segfault Secret. This time Sammy is joined by guest and core PHP developer Sara Golemon

PHP is known for running really bad code really well. But it has a dirty little secret: deep within its code is a hidden "stack bomb". You can cause PHP to completely crash with just a few lines of code. Today we discuss why this happens and what we can do to fix the issue.

You can listen to this latest episode either through the in-page audio or video player, over on YouTube or by downloading the audio directly. If you enjoy the show be sure to subscribe to their feed and follow them on Twitter for updates on when new shows are released.

Derick Rethans has posted another in his series covering the latest release of the Xdebug debugging tool for PHP, version 2.3. In this new article Derick introduces the "shared secret" handling, a custom string that for the "XDEBUG_PROFILE" that can trigger the the profiler to start.

Xdebug's profiling and trace file capabilities can both be triggered by a cookie, GET or POST variable, as long as you have enabled xdebug.profiler_enable_trigger and/or xdebug.trace_enable_trigger. With these triggers enabled, basically anybody could initiate a profile run, or trace file, by simply sending the XDEBUG_PROFILE or XDEBUG_TRACE cookies with an HTTP request. Although you should not really run Xdebug in production, you can see that this is not an optimal solution. Xdebug 2.3 adds supports for shared secrets for the trace file and profiler triggers through the xdebug.trace_enable_trigger_value and xdebug.profiler_enable_trigger_value.

He points out a browser extension, The easiest Xdebug, that already has support for this new feature. He also mentions two other tools but they have yet to integrate support for these shared secrets (but will soon hopefully): Xdebug halper and xdebug-helper-for-safari .

Cal Evans has posted another in his series looking at the right things to do when writing job posts and trying to attract developers for your company. In his previous posts he's talked about building a good team and getting the jobs page right. In his latest post he talks about a secret to writing the post itself: keeping it simple.

Is your company trying to hire a developer? Are you a recruiter responsible for helping your client hire a PHP developer? Do you have a job post out on the net? Get this one thing right and you’ll find your PHP developer. Yes, that’s the entire secret; keep it simple. Make it easy for us to scan, easy for us to understand, easy for us to figure out how to apply.

He includes a few points to follow to help guide you into the "keep it simple" approach including avoiding "semantically null terms" and listing the minimum skills for the job, not everything you could possibly need.

The WebLessons.info site has a new tutorial posted showing you how to use the LinkedIn authentication handling to allow your users to log in with their own account information.

LinkedIn is a business-oriented social networking service. It is mainly used for professional networking. So if you are having an application or website that serves working professionals then its very important for you to implement login with LinkedIn in your application. By this way you can able to access the data of your users like email, work history, education etc. So now let’s dive into the coding part.

They walk you through the various steps, providing screenshots or code where applicable:

• Creating a LinkedIn Application
• Get the API Key and Secret Key
• Create the database and set up the PHP configuration to connect
• finally, the PHP code for the login form and making the request to LinkedIn

A live demo can be found here (but if you're paranoid about your credentials, I wouldn't use it) and you can download all files included in the tutorial.

Jerermy Kendall has written up a post for his site showing the use of his QueryAuth library for API authentication, complete with plenty of examples. The library makes it simple to sign and verify requests based on a key, secret and parameters given.

Most APIs require some sort of query authentication: a method of signing API requests with an API key and signature. The signature is usually generated using a shared secret. When you’re consuming an API, there are (hopefully) easy to follow steps to create signatures. When you’re writing your own API, you have to whip up both server-side signature validation and a client-side signature creation strategy. Query Auth endeavors to handle both of those tasks; signature creation and signature validation.

He includes code examples showing how to create a signed request, validate the signature from an incoming request and generate randomized keys and secrets. He's also created a sample implementation as a Vagrant box that sets up a Slim framework based application and uses Guzzle to make requests. He briefly looks at some of the code that makes it work and what the raw HTTP request and response look like for the result.

Michael Nitschinger has a new post for the Lithium framework users out there - a quick tutorial about encrypting your session information with the new built in "Encrypt" strategy feature.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

Lorna Mitchell has posted the latest in her look at OAuth in PHP to her blog today, an introduction to access tokens - generating and handling them in your application.

I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. [...] This entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.

In this latest post, she talks about the three different types of tokens - consumer, request and verififier - and how to use them to locate a user in your app's users. Her code validates the request token and verifier against the database and, if successful, inserts the rest of the token information for the user.

Tim Lytle has written up a new tutorial for the Zend Developer Zone talking about OAuth and making one of the more difficult parts - getting an access token - a bit simpler using a command-line application.

OAuth is great - there's no need to save users' passwords, it's - in theory - a consistent way to interact with other services, and it's hopefully something that your users are familiar and comfortable using. But if you're not just interacting with your users' accounts - for example, your application uses a single account on a service to broadcast messages, or analyze data - getting or renewing the access token can be painful.

He illustrates the problem with an example connecting to Twitter and even points out a script that makes bridging this gap simpler. Unfortunately, it's not exactly what he needed, so he reworked the idea with a call to the Twitter API using a Zend_Oauth_Consumer and a custom callback. The script is then set up with some command line options for inputting the key and secret information. Also included is functionality letting you define a configuration file. You can see the final result here on github.

In this new post to his blog Cal Evans talks about a project he was working on that needed to interface with Twitter via their API. This, of course, requires OAuth but his script is all backend and Twitter requires a frontend to allow the application access.

There is no front end at all. It just collects info and stores it in a database so I can query it later. (I'm an old-school database guy and love just writing ad-hoc queries to see what I can see) Twitter wants to redirect you to a site once you have authorized access. Since I don't actually have a site to redirect it to, this was a problem.

His solution ("in two parts") involves tips from two different blog posts - this tutorial from Michelangelo van Dam and the other from Jaisen Mathai about using OAuth with Twitter. He's not releasing the source for his script just yet, though, so you'll have to do a little research on your own.