Last night I released what I hope will be the last beta release Crypt::HSXKPasswd before the first release to CPAN. You can download it from the project’s GitHub page (reminder, you can get installation instructions for the beta releases here).

The head-line change is the addition of a bundled command line app, bringing all the power of Crypt::HSXKPasswd to the terminal, shell scripts, and indeed programs and scripts written in any language with the ability to shell out.

In terms of lines of code the biggest change is a complete re-write of all data validation code. The project now contains a custom type library which exactly defines what it means to be a word, letter, symbol, symbol alphabet etc.. This has made the code much more robust, and has make it a lot easier to write consistent documentation. The type library is written using Type::Tiny, and all the custom type definitions contain customised validation error message functions to give users much more helpful feedback.

With the help of Allison Sheridan from the NosillaCast Mac Podcast, the warnings and error messages issued by the module have also become a lot more human-friendly.

The test suite has also been greatly expanded, making it easier to find and fix bugs going forward.

If you have an interest in this module, please install the beta and report any problems you find by opening issues on the project’s GitHub page. Or better still if you’re a developer, fixing the bug and sending me a pull request 🙂

Finally, I’m looking for help in the following areas:

  • Native German, French, Italian, Spanish, Dutch, and Portuguese speakers to sanitise the dictionary files for those languages, leaving only a few thousand common words – these dictionary files are simply too big at the moment, and they must be full of really obscure words to be this large!
  • People who are good at technical writing to help me give the documentation some spit and polish. I think all the relevant information is there, and I have run it all though a spell checker, but it could definitely do with some TLC from a copy editor!

Oh, and finally finally, if you find this module useful, please consider donating with the button below – I have literally put hundreds of hours into this code in the last few months, and given it all away for free.

*Download Beta 2 of Crypt::HSXKPasswd via GitHub*

Tagged with:

It’s been a while since I released a new version of, the open source Perl module that powers the secure memorable password generator at The main reason for the big gap is that I needed to learn some new skills to get the code to where I wanted it to be. There were three main problems I wanted solved:

  1. To get wide adoption, the Module needs to be available via CPAN
  2. The module needs unicode support to deal with non-English languages
  3. It needs to be easy to edit and tweak a config with the web interface, and then use it in your scripts.

While solving those problems, I also took the opportunity to tidy up some other odds and ends in the code base. It’s not that code was broken, it just that a few parts of it had a bit of a fishy smell – it seemed like there was probably a better way to do that, and there was!

So, here’s a summary of what’s changed from the the point of view of a user of the Module:

  • The Packaging – the module has a new name, and is now packaged with Module::Build, so it’s easier to install, and ready for distribution via CPAN.
  • Unicode Support – if it’s a unicode character, you can use it while generating passwords.
  • Redesigned Word Sources – more bundled with the module, and easier to create your own.
  • Redesigned Sources of Randomness – more bundled with the module, a better default, and easier to create you own.
  • A switch to Named Arguments (in both the constructor and functional interface).

I’ve put a lot of time and effort into developing this entirely free and open source module. If you find it useful, please consider making a donation:

*Download Beta of Crypt::HSXKPasswd via GitHub*

Read more

Tagged with:

This post is part 33 of 39 in the series Taming the Terminal

This is the final SSH instalment. So far we’ve learned how to securely execute terminal commands on remote computers, how to securely copy files across the network using SSH, how to add both security and convenience to both those operations with SSH key pairs, and how to tunnel just about anything through SSH. In this final instalment we’ll look two approaches for creating SSH bookmarks, SSH config files, and SSH GUIs.

Read more

Tagged with:

This post is part 32 of 39 in the series Taming the Terminal

This is the fourth SSH instalment. So far we’ve learned how to securely execute terminal commands on remote computers, how to securely copy files across the network using SSH, and how to add both security and convenience to both those operations with SSH key pairs.

As we saw in the previous instalment, SSH’s ability to provide a secure connection between two computers can be used in many different ways. In this instalment we’ll learn about three more ways to encapsulate other network traffic within an SSH connection, adding encryption to that traffic.

Running commands and copying files are the kinds of things most people do, so the three SSH instalments to date have been quite generally applicable. That is not the case for this instalment. The three SSH features we’ll be discussing are all very useful to those who need them, but only a minority will have a use for any one of these features. However, even if you don’t need these features today, I would argue that it’s good to know these features exist, because they could well solve a problem you’ll have in the future.

There will be illustrations of the uses for these technologies, but not commands you type into your terminal to play along at home. That makes this an unusual instalment, but I hope you will still find it worthwhile.

Read more

Tagged with:

This post is part 30 of 39 in the series Taming the Terminal

In the previous instalment we saw how we can use SSH to execute a single command on a remote computer, or, to get a command shell on a remote computer. We also saw how SSH uses host keys to protect us from man-in-the-middle (MITM) attacks.

In this instalment we’re going to look at how we can improve both SSH security and convenience with SSH keys.

Read more

Tagged with:

This post is part 29 of 39 in the series Taming the Terminal

In the previous six instalments we looked in detail at how TCP/IP networks tick. In these instalments we worked our way up from the bottom of the four-layer TCP/IP network model to the top, finishing off with a look at two protocols in the Application Layer at the top of the stack. Those two protocols, DHCP & DNS exist in the top layer, but are different to most other top layer protools in that they can reasonably be described as forming part of the infrastructure of the internet. The email and web protocols may site within the same network layer, but they still rely on DNS to function.

For the remainder of the networking section in this series we’ve moving away from infrastructure-like protocols, and focusing on the user-facing Application Layer protocols. The first of these we’ll be looking at is the Secure Shell, or SSH. This protocol is one of the absolute work-horses of the internet, and a vital tool for all Linux, Unix, and OS X sysadmins.

At it’s simplest level SSH allows you to execute commands on a remote computer, but because it was designed around the concept of a secure tunnel between two systems, SSH has expanded to allow all kinds of advanced features. The least-generous description of this could be that SSH has become a kind of sysadmins fridgeoven. But I don’t buy that, I prefer the alternative interpretation – it simply makes sense not to re-invent the wheel, and to allow as much information as possible to flow throw the secure connection SSH provides between the two end-points.

Today we’re just going to start with the basics, but in future instalments we’ll move on to the more advanced features.

Read more

Tagged with: Updated

Filed Under Security, Computers & Tech on November 10, 2014 | 10 Comments

After quiet a few months of work, I’ve just re-launched my secure memorable password generator – The entire interface has been re-designed, and under the hood the site now uses version 2 of my perl module.

The interface has been completely re-designed with an eye to making it easier to understand what the various configuration settings mean. The configuration is sections, and each section is headed by an English description of the current settings. You can read down through the headings to get a very good understanding of the configuration. Additionally, there is now a diagram showing the structure of the password that will be generated, and whether or not it will contain mixed case, digits, and symbols.

You can now generate multiple passwords at once, people often like to generate a few and choose one that speaks to them, so while not make that easier! Once passwords are generated, their strength, or Entropy, is reported, and colour-coded – green is good 🙂

I’ll be adding some more features over the next few months. I’ll mainly be focusing on adding more dictionaries, and allowing users to create their own custom dictionaries by mixing and matching separate word lists. What I have in mind is a set of base language dictionaries like English, and French, and so on, and then a selection of special dictionaries like place names, scientific terms, scifi characters and places, animals, fore names, and so on. I’m also planning to add the ability to store your own custom presets locally using HTML5’s local storage feature.

If you have any comments or suggestions, please do share them.

Tagged with:

“Behind People’s Backs”

Filed Under Computers & Tech, Security on October 24, 2014 | 2 Comments

I’m fed up with people being dishonest about the new search feature in Yosemite. You can have reasonable discussions about the pros and cons of this feature, but for goodness sake enough with the fact-free hyperbole.

I’ve lost count of how many people insist Apple is sending this information back to Apple “behind people’s backs”. Sorry, but that is a fact-free assertion. The screenshot below shows the search feature in question:

Yosemite Spotlight Popover

Here it is again with the important aspects highlighted:

Yosemite Spotlight Popover (Anotated)

If that’s “behind people’s backs” then I’m the pope!

Something I will agree with critics on is that I think that link to instructions should be a button or checkbox to disable the feature. A link to instructions is nice, a button would be perfect!

This data is not being sent for no reason, it’s being sent to offer people a richer search experience, and Apple were actually playing catchup in this regard. Here’s what Microsoft say Windows 8.1 does:

By default, the Search charm searches the apps, files, and settings on your PC and OneDrive, plus the web.

The real question is whether or not Apple have thought about our privacy when implementing this feature, and whether or not they have designed the feature well. Here is what Apple say they do:

We are absolutely committed to protecting our users’ privacy and have built privacy right into our products. For Spotlight Suggestions we minimize the amount of information sent to Apple. Apple doesn’t retain IP addresses from users’ devices. Spotlight blurs the location on the device so it never sends an exact location to Apple. Spotlight doesn’t use a persistent identifier, so a user’s search history can’t be created by Apple or anyone else. Apple devices only use a temporary anonymous session ID for a 15-minute period before the ID is discarded.
We also worked closely with Microsoft to protect our users’ privacy. Apple forwards only commonly searched terms and only city-level location information to Bing. Microsoft does not store search queries or receive users’ IP addresses.
You can also easily opt out of Spotlight Suggestions, Bing or Location Services for Spotlight.

So, your searches are not tied to your Apple ID or any other persistent ID, instead, your device creates a new random identifier every 15 minutes, so your searches are anonymous, and most importantly, they can’t be profiled because the IDs are ephemeral. The fact that the device fuzzes the location before sending it on is also very good. The fact that IP details are not logged is also good. Finally, the fact that only a sub-set of the request is sent on to Bing is great.

I do not believe Apple would blatantly lie to users. For a start, as a publicly traded company that would almost certainly be criminal, but even leaving that aside, it would be spectacularly damaging for Apple to be caught lying about stuff like this.

Bottom line, Apple have been very open about this, Apple have implemented this feature with privacy in mind, and this feature is not unique to Apple OSes. Finally, if you want to opt-out, you can.

If this really is such a scandal, why is Windows 8.1 not coming under the same fire? *cough* link bait *cough*

Tagged with:

It’s hard to believe, but it’s been nearly three years since I released my first attempt at a Perl library for generating secure memorable passwords. The original spark of inspiration came when Steve Gibson released and talked about his Password Haystacks page at around the same time as the now famous correct horse battery staple XKCD comic was released. Take the idea of using words as the basis for passwords from XKCD, add computers to introduce real randomness (we humans are terrible at being random), and season with come well-chosen and intuitively placed symbols and digits to increase the size of your haystack, and voila, passwords are are both human-friendly and secure!

The first version of the library worked, as evidenced by it’s years of service powering That’s not a bad start. But, it was a first attempt at solving the problem, and, I was still a Perl padawan back then. Some of my early design decisions resulted in a less than ideal API making the library a lot less developer-friendly than it could have been, and I’ve learned a lot about Perl, and Perl best practices since 2011!

I’ve spent the past half year or so re-implementing the same basic idea from scratch. In terms of functionality very little has changed, there are a few additions, but the big change is in the API. Basically, the old API was a mess – you needed one config hashref to instantiate the object, then a different config hashref to call the password generation function. Nonsense! That’s not intuitive, not obvious, and not efficient! The new API allows you to achieve the same result with less code, and the code you will have will be easier to read and understand.

You’ll find the project page for the new library at the link below – this page provides links for downloading the code, and links to the module’s very detailed documentation.

XKPasswd 2 Project Page (

Read more

Tagged with:

I sometimes take some stick for having a very defensive coding style. When ever I find myself making an assumption I throw in code to test it. “This function will only ever be called with a positive number”, OK, then add a test to throw an exception should a negative number be passed. You don’t want bad data ricocheting through your code because goodness knows what damage it will do! Similarly, my style is to always use explicit syntax, and, to avoid syntax shortcuts – sure, the ternary operator takes up less space on the screen, but there’s a price to pay for that terseness – it makes your code harder to read and hence to debug and maintain.

However, one of my very biggest bug-bears is the failure to brace control statements like conditionals and loops when they’re operating on a single line of code. This is the trap Apple fell into so spectacularly this week.

Read more

« go backkeep looking »