security posts

Reading this weekend about a backdoor introduced to the open source xz project.…

I came across an interesting Stackexchange question about easy to type passwords. It seems a useful consideration for passwords we have to type frequently. Reading through the answers got me to thinking about a solution that fits the criteria of easy / fast to type along with the general password criteria of easy to remember and some reasonable level of secure.

My solution considers typing style for determining ease and uses words and rules for making them memorable. It keeps to the rules from the question of at least one upper case letter, one number, and one symbol.

Today was not a great day at work: I discovered that my work laptop was stolen over the weekend. Continue reading post "Work theft"

Wow, the highest cost (31) bcrypt hashing of a password with PHP's password_hash…

This idea is based on my Local + Proxy Remote Hosting for Personal Site idea, but attempts to mitigate some of its problems further.

I've been considering a new password storage method for a while now. Currently…

I've been working on the HTTP headers my site sends recently. I had been working on performance / cache related headers, but after seeing mention of a security header scanner built by Scott Helme, I decided to spend a little time implementing security related headers on my site. I don't really know these headers that well, so I added the headers it suggested and mostly went with the recommended values. I did read up a bit on what they mean though and modified the Content-Security-Policy as I saw fit.

I added most of the headers using a Symfony reponse event listener. This handles all of my HTML responses without sending the headers for other responses, where they aren't necessary. The exception is the X-Content-Type-Options, which should be set for all responses. I set that in Apache configuration.

Symfony provides a security component and bundle for managing authentication and authorization in an application. It is versatile and powerful, if not a bit complicated. You can toss as many mixes of authentication and authorization configuration as you want. The important parts of the configuration cannot be overridden or added to by multiple config files, though. This makes sense for one-off applications, where you can be sure that no bundles are messing with your security configuration. However, if you're building something like a CMS that will be used for multiple sites, where you want the CMS's bundle to manage security, setting the configuration within the bundle will block the application itself from adding its own configuration.

One way I've found to work around this is to have the security configuration set on your bundles configuration extension instead of the 'security' extension directly, and have your bundle merge all such configurations and set them on the 'security' extension in PHP. If you allow this configuration node to be overridden, any number of bundles can add to it and avoid the "cannot be overwritten" error.