I posted on this a while ago and was quite impressed with some of the replies.
We are taking on board many of the comments, and have this week been working on the some changes. The status posts go in to some detail, but I thought I would explain more.
Firstly, there is more than can, and will be done over time, but as with all security it is all about having the right level of inconvenience for the risk.
So what is happening?
Well, for a start, we have used hashes for storing passwords in various places for some time. This means we do not know the password, but we can check it. We make the same hash from the attempted password and check against the hash we have stored.
One of the improvements that has been made is salted hashes where, in addition to the password, a salt is used (random data) when making the hash. This means two people with the same password do not have the same hash, and means you cannot make a huge dictionary of common passwords and combinations of dictionary words with pre-calculated hashes (rainbow tables).
However, sadly, some systems work in such a way that we have to know the "plain text" password. This applies to CHAP (Challenge Handshake Authentication Protocol) and similar systems used for VoIP. To check the password we have to know it. However, the systems that allow control and management and even visibility of such passwords can be locked down under systems that can hash the password.
This is the main change we are making... Our "control pages" (called "clueless") were originally for DSL lines, and that was it. We needed plain text passwords for the CHAP login, and that was the only password.
However, over time, things have become more complex. We now allow control of VoIP logins which can be used to make lots of calls and run up bills, using the control pages login. We also allow visibility of call logs. So we need to beef up security a bit.
Salted hashes where we can.
The first step is to ensure salted hashes are used, not only on our accounts system but also on the control pages. We are changing them so the control pages login is a salted hash, and the line login is a separate line password. The latter is just for DSL/L2TP/SIM login and is often ignored if we have a valid login and circuit ID anyway.
These changes will soon be visible, allowing DSL passwords on lines to be seen/changed, but passwords on the login pages to be set using a password change process with https and no plain text passwords in emails and no way for staff, or anyone else, to see the password.
Making a system that allows improvement.
Doing this has meant we have the opportunity to make new password generation and checking code in common libraries used over many systems. These functions will check a salted hash, but they also have the ability to report that the correct login used an old hash of some sort and provide a new hash. The systems allowing logins then update the hash on the next login.
This allows us to improve things in the future.
For today we are using a salted SHA1. This is not ideal as SHA1 is considered a bit quick and efficient for a password hash, but it is a good starting point. There is a competition for password hashing algorithms running now, and the plan is to move to a new best practice password hash in due course. As it happens, FireBricks are moving to heavily salted SHA256 for now.
Having a system library to handle this means that when we upgrade, it will happen automatically. Using the new hash for all new passwords, and updating the hash on existing logins when used.
Of course, ultimately, these libraries may allow OTP and two factor logic to be deployed where sensible.
Part of the library is a single place to manage the creation of passwords. We now have a function allowing a password to be generated with specified min/max lengths and entropy. This tries to use XKCD/936 style passwords where possible, or words and numbers, or letters and numbers or just and letters/numbers/symbols, as needed to meet the specified size and entropy.
We also try to encourage people to use easy to remember passwords that are system generated and random. This avoids many of the common mistakes of passwords, including: re-using the same password; picking easy passwords; and having to write down passwords.
This does mean a few changes. For many passwords you will see the familiar four word passwords that are long, easy to remember and of the order of 48 bits of entropy, but for some things like WiFi passwords you will see a couple of words and several digits to meet space and entropy requirements.
However, as ever, comments welcome...