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() function is quite safe from brute force attacks from my laptop: It ran for almost 282 CPU minutes trying to compute one hash before I stopped it.
This idea is based on my Local + Proxy Remote Hosting for Personal Site idea, but attempts to mitigate some of its problems further.Continue reading post "Ideas: Remotely hosted personal site with home data store that syncs as client"
I’ve been considering a new password storage method for a while now. Currently, I have a system where I compose passwords of pieces of several different values that I have memorized. Each value has a key that I have associated in my head to the value, and I have a file with the keys for each site. Lately, I’ve also been doing part of the password as something derived from the name of the site. This has helped somewhat with making the passwords memorable, but I still frequently have to look at my password file. If someone got a hold of this file, it would take some dedication and knowledge of me, or at least access to the plain texts of some of the passwords, to crack the system. Nevertheless, I’ve been looking for something easier to use and preferably more secure at the same time.
I’ve been looking at options like YubiKeys and 1password, but they have their issues. Today, I came across a cool option wherein passwords are algorithmically derived from a single password and the site name. This is sort of like what I’m doing in my head for some of my newer passwords, but much more advanced, able to produce hash passwords of a desired length and even with character constraints. I read about the idea from a post by Tab Atkins, who has his own solution freely available to use. The comments on his post also led me to SuperGenPass, a similar idea.
Both are of these options built purely using web technologies, making them easy to use anywhere. Both are open source, so I can check their code, verify they are doing what I want, and modify them so they can be slightly different. Neither need to store anything (unless you change the config for SuperGenPass) or require accounts. They have an option to work as a single-page file that can work even offline, wherein you type your master password and the name of the site, and they will give you the password in plain-text to copy elsewhere. SuperGenPass also has a bookmarklet option that can be run from the page you are entering the password on (obviously web only) by using an iframe (requires a third-party server) that can put the password directly into the password field, bypassing the need to copy the password at all.
So these are definitely interesting options to make working with passwords much easier, and the passwords I have for each site can be more complicated and theoretically secure than what I use currently. The biggest danger would be, if someone figures out my master password and what settings I’ve used for the generators, they will have access to any passwords I’ve created. I would probably do multiple master passwords, at least a normal one and an extra-secure one, just to limit the number of accounts they could access. I could even throw in a simple modification to the master password derived from the site name to make it even less of a problem.
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.Continue reading post "Additive overwriting of Symfony security configuration"