Skip to main content

Why do companies insist on putting a MAXIMUM length on passwords? Especially for important things like credit cards? How come my Twitter account gets to be more secure than Verified By Visa with their 15 char max? @Visa @VisaSecurity @AskRBC @RBC


Doing penetration testing and security scanning of an app I'm working on. Accidentally sent myself ~850 emails with more still coming in.


Day 19, Sleeping Security

They have been planning all day the best way to catch the kidnappers.  The plan was simply to stay up all night and wait for them to come for their cookies and milk, then jump on them and take them down with some well placed kicks to the face. (They were confident they could do so even if it turned out to be Jamie).

We set them up in the living room, directly adjacent to the dining room with a direct view of the table.  They took their pillows and blankets with them for comfort and started the stake-out.

Unfortunately it appears they both fell asleep at the post, as all the cookies and milk are gone, and they have a new note that reads:


Good. You’re learning.

There may be a chance for Elfie yet, but not until after Christmas.

We don’t like his spying ways, always watching people and reporting back to Santa.

Last year he must have said we were bad because we didn’t get any presents.

That will not happen again.

Tomorrow we may show our appreciation for your cooperation.


PS. Thanks for staying asleep!


- S & B


The note also has a taunting picture of them sleeping at their stake-out, and appears to be initialed (a clue?).  Whoever is behind this is Solid Snake level stealthy!


Day 8, do we need security?

What?!? A kidnapping in our house? This is very troubling. Unfortunately it looks like Elfie ran out of time before he could finish his note. We have so many questions... but first and foremost - are we in danger? How do we make sure it doesn't happen again?


New Plugin: Elgg Copy

Elgg Copy

A tool for cloning an elgg installation from a master installation (production?) to a development installation. The development installation will request all components of the installation from the master installation. They will be downloaded, configured, and replace the existing data on dev. This is useful when you need to get the latest code from a production site while trying to debug something.

Note that this uses some system commands such as mysqldump, gzip, curl, etc and will likely not work for windows. Who's using windows for dev anyway?


Clone/unzip the elgg_copy plugin to mod/elgg_copy on both the development install and the master install

On the settings page a "Request Key" will be generated. Copy the request key from the master installation to the plugin settings of dev. Enter the URL of the master installation in the plugin settings of dev.

Check the boxes corresponding to what should be copied from master - mod/data/database

No settings are required on the master installation.


A button will be added to the admin control widget. Clicking that button will initiate the sync from master.


Master will only provide the data to download on a hard-to guess URL based on a cryptographic request key. This key can be regenerated in the settings of master if there is reason to think it has been compromised. It is recommended, however, that this plugin should be disabled on master the majority of the time and only activated when a sync needs to happen.

The ability to sync the mod directory requires the mod directory of the dev environment to be writable by the server. This isn't recommended for production but should be fine for a local dev environment.

One additional note - the entire contents of the site will be transferred over standard http protocol, it is recommended that this only be used on production sites that are secured with ssl.

This is a tool of convenience, use at your own risk.


The database prefix must be the same on both installations


New Plugin: Elgg Copy

Vagrant based dev environment

7 min read

After having to start from a fresh OSX install I decided to base my dev environment on vagrant managed VMs.  I used to use XAMPP, but found it restrictive, and some of the projects I work with have special configuration requirements and it was hard to manage switching back and forth.

Vagrant managed VMs gives me the option to have a single standard dev virtual machine, then separate VMs for any projects that have special config requirements.

Earlier this year I played around with vagrant and created my first box which was just a simple CentOS 7 box with Solr configured as a service and an early version of Elgg 2.0 preinstalled.  This is what I used as the base for my dev environment.

CentOS 7 Elgg box

Once VirtualBox and Vagrant are installed it's very easy to get up and running.

vagrant init elgg/elgg; vagrant up --provider virtualbox

This will download the box, if necessary, and start it up.  Once up and running you can see it in action by visiting http://localhost:8080

Where you ran the vagrant init you will see there is now a text file there called Vagrantfile, this holds any custom configuration options for the VM, and the directory where this is found is mounted in the VM under the /vagrant path.  This is where I put my project files, so they're accessible both from my Mac and from the VM.  This lets me edit them in my IDE on the host Mac, and execute them in the VM.

My directory looks something like:



From the vagrant directory - in this case /Users/mbeckett/sites/elgg you can ssh into the VM

vagrant ssh

The box is designed to be a dev box, so there's really no security to speak of.  You are logged in as the vagrant user with password-less sudo.  Mysql is installed/configured, username: root, password: root

The next step is to configure the VM to serve each project from its own subdomain.

While logged into the VM create the following file: /etc/httpd/conf.d/httpd-vhosts.config

Here is mine:

# Restart apache after changing this file
# systemctl restart  httpd.service

<VirtualHost *:80>
	ServerName project1.localhost
	DocumentRoot "/vagrant/project1/docroot"

	DirectoryIndex index.html index.php

	ErrorLog "/vagrant/project1/logs/error_log"
	CustomLog "/vagrant/project1/logs/access_log" common

	<Directory "/vagrant/project1/docroot">
		Options Indexes FollowSymLinks Includes ExecCGI
		AllowOverride All
		Require all granted

<VirtualHost *:80>
	ServerName project2.localhost
	DocumentRoot "/vagrant/project2/docroot"

	DirectoryIndex index.html index.php

	ErrorLog "/vagrant/project2/logs/error_log"
	CustomLog "/vagrant/project2/logs/access_log" common

	<Directory "/vagrant/project2/docroot">
		Options Indexes FollowSymLinks Includes ExecCGI
		AllowOverride All
		Require all granted

Each new project you start can be added as new entry in this file.  After changing the file remember to restart apache as per the note at the top.  Now you can access each project at its own subdomain.



The last thing that was an issue for me was file permissions on the mounted /vagrant directories.  This seems to be a bit of a pain point with vagrant and took some googling to find a solution.  The problem was the directories weren't writeable for the Elgg cache, though it was really inconsistent.  I was able to get around this by setting the config in the Vagrantfile to mount that directory as being owned by apache.

config.vm.synced_folder "./", "/vagrant", id: "vagrant-root",	owner: "apache", group: "apache", mount_options: ["dmode=775,fmode=664"]

To make it remount with these permissions the simplest thing to do is restart the VM.

vagrant halt
vagrant up

Hopefully this is helpful to someone, including my future self, because I'll likely forget all of this the next time I need to set it up.


[Update 11/13/2015]

Unfortunately on restart of the VM the httpd service doesn't start correctly because the /vagrant directory is not yet mounted when the vhosts conf file is checked so the initial attempt at starting apache errors out.  You can log in and manually start it up after the VM has booted, but that's annoying.  Fortunately there's a solution to that using the provisioner system of vagrant.

Here is my current VagrantFile

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at

  # Every Vagrant development environment requires a box. You can search for
  # boxes at = "elgg/elgg"

  # Disable automatic box update checking. If you disable this, then
  # boxes will only be checked for updates when the user runs
  # `vagrant box outdated`. This is not recommended.
  # config.vm.box_check_update = false

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  # "forwarded_port", guest: 80, host: 8080

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # "private_network", ip: ""

  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # "public_network"

  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"
  config.vm.synced_folder "./", "/vagrant", id: "vagrant-root",	owner: "apache", group: "apache", mount_options: ["dmode=775,fmode=664"]

  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  # Example for VirtualBox:
  # config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
  #   vb.gui = true
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  # end
  # View the documentation for the provider you are using for more
  # information on available options.

  # Define a Vagrant Push strategy for pushing to Atlas. Other push strategies
  # such as FTP and Heroku are also available. See the documentation at
  # for more information.
  # config.push.define "atlas" do |push|
  # end

  # Enable provisioning with a shell script. Additional provisioners such as
  # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   sudo apt-get update
  #   sudo apt-get install -y apache2
  config.vm.provision "shell",
    inline: "systemctl start httpd.service",
    run: "always",
    privileged: true


[update 02/12/2016]

Found some performance tweaks - detailed them here: