There are many schools of thought around how to create 'secure' passwords. While they differ in the various ways to assess if a password is secure or not, they are all united in their goal of making it harder for both pesky humans and super-powerful computers to guess your passwords. In addition, the ways of storing passwords vary depending on desired security levels.

Before we discuss ways to make secure passwords, let's take a moment to consider something called entropy. To properly understand entropy can take years, so here's a brief précis… In essence, and for our purposes, entropy is a measure of how "random" your password is. Entropy is a measure of information and, for passwords, we want as much entropy as possible since that makes it harder for an adversary to guess. Sadly there's no trivial way to estimate how much entropy is present in a password because a computer cannot know all possible context around the person setting or using the password. This is the crux of the arguments around password policies, qualities, etc.

Bruce Schneier, who is a well respected security expert, wrote a nice article on passwords.

The hard-for-humans password

"A good password consists of between ten and forty characters, with a mix of upper- and lower-case letters, numbers, and symbols."

The "alphabet" of characters which may be part of a password can be as large, or as small, as you like. One school of thought says that (a) the alphabet should be as large as possible and (b) that passwords should be mandated to have at least one of each class of characters in the alphabet.

These passwords are often very hard for humans to guess if constructed entirely randomly. Sadly humans are very bad at remembering well constructed passwords of this kind and as such they tend not to be well constructed. For example, on the face of it, 94Pr!LOR;Fq. might be an excellent looking password. Sadly if you knew that my birthday is the 9th April, you might guess the first half, and the second half is an inversion of shift state combined with a down/right migration on a UK qwerty keyboard. The first half is context which a human might guess and the second is the kind of translation which a computer will likely try quickly and easily.

However, for a moment let's consider the possibility that it were a good password, let's estimate the entropy in it. We'll be naïve and generous in our estimation... The 'alphabet' has somewhere around 100 elements, let's assume it has 128 elements and as such each character is, generously, seven bits of entropy. Our 10 character password is thus 70 bits of entropy, but we might halve that because of the repetition, giving 35 bits of useful entropy. By comparison the smallest of possible keys which computers might use these days are 256 bits so we puny humans are nowhere near and we're finding it hard to be there.

Correct Horse Battery Staple

Another stable of thought (yes, pun intended) is that a longer but more easily memorised password would be more secure. There are around 100,000 words in the standard word list on my laptop (/usr/share/dict/words) so picking one of those is, in theory, around 16 bits of entropy but let's be conservative and call it 11 bits. Four words, chosen at random, therefore have 44 bits of entropy. If you add in some capitalisation tweaking to make that estimate a little more reasonable; and then add two or three more words and bring the entropy estimate way above anything you might manage to memorise from a random password above.

Keeping passwords securely

Sadly, two parties need to keep passwords if they are to be a mechanism of authentication. The person who is being authenticated (you) and the entity who is doing the authentication (some website for example). In order to reduce the impact of a data breach, passwords will be stored hashed by sites which care. Algorithms to do this are designed to make it mathematically improbable that you can find a password purely by knowing the hash of it. In addition they are often designed to be computationally expensive to calculate in order to reduce the ease by which computers might test guesses. There are a number of algorithms which are considered good for this, such as scrypt or bcrypt which require a reasonable chunk of non-parallelisable CPU time and a non-trivial amount of memory to compute.

Sadly you can't use the same algorithms to store your passwords safely because you won't be able to recover them. We'll consider ways you can do that in a future article.

It's perfectly OK to have a personal project that only you yourself work on. In fact, most free software projects are like that. A project with only one contributor, or only a couple, can be quite limited however. A larger group tends to get more done and, more importantly, they do different things. A more diverse group brings in more points of view which tends to make the project better suited to a larger group of users.

Attracting contributors to a project you've started can be tricky. Your humble author asked on Twitter and Mastodon for advice on this very topic, and wrote up a summary on his own blog.

The condensation of the summary is:

Get people over the hump of making their first contribution, by making it easy and removing all unnecessary obstacles. Make contributing into a rewarding experience.

Obstacles can be things like making it difficult to install, run, or use the software, making it difficult to find, retrieve, or understand the source code, not having public discussion forums (mailing lists, IRC channels, etc), or not having a public ticketing system.

There're a number of ways of keeping your passwords as safe as can be. One very old-school way is to write each password down in a book, and keep that book physically secure. On the assumption that you can't remember the passwords without the book, this is a reasonable way to improve your security. Sadly it doesn't scale well and can make it quite hard to keep things up-to-date.

More usefully, in today's multi-computer and multi-device world, there are programs called 'password managers' and as with anything even vaguely interesting there are a number of them to choose from. Some names you may already be familiar with include Keepassx, 1Password, and LastPass.

Password managers offer you a way to effectively protect all your passwords with a single token, often allowing you to sync and manage your passwords without needing lots of knowledge of how things work. They're usually also integrated with your web browser, your phone, etc, to allow you a seamless experience.

If you're a little more paranoid than the normal geek though, and you're prepared to sacrifice a bit of simplicity for a bit more ease-of-mind, then you could try Password Store (pass) which is written in Bash and uses GnuPG. I personally use pass and have my GnuPG key stored in a Yubikey which I keep around my neck. (There's also the Gnuk which can, I believe, do a similar job) With the need of the physical token and also the PIN to unlock it, this is a multifactor authentication system which I then can use to secure my passwords etc. I then have it backed onto my own Git server where I can keep an eye on the content safely.

I strongly suggest that if you're not using a password safe of some kind, that you get one set up and start using it. In fact, if you've not got one, go and do it now and I'll see you next time...

(Oh yeah, and if you look at multifactor authentication, be aware that your intrinsic factor today is simply your adversary's posession factor tomorrow)

Free software development always has an ethical dimension. We develop free software instead of proprietary software to allow people, the users of our software, to not be as controlled by vendors of proprietary software as they might otherwise be.

Software freedom is, however, only one ethical dimension. Free software can also be unethical, for example by doing things that hurt people. As an extreme example, a free software implementation of ransomware would be quite problematic, under any licence. It doesn't matter if the program is, say, under the GPL licence, if it attacks people's computers, and encrypts their data and refuses to decrypt it until the author of the program has paid a ransom. Not even if the program installs its own source code on the computer when it encrypts all other data would it be considered ethical.

When you write software you should consider the ethics, the morality, and the impact on everyone. For example:

• Does it promote racism, sexism, or violence, directly or indirectly? For example, if it's an "AI" that tries to guess if someone will commit a crime in the future, is it effectively only based their race?

• Does it use bandwidth unneccessarily? Bandwidth is an expensive luxury in some parts of the worlds, so wasting it discrimnates against people in those parts of the world.

• Does it "call home", such as report usage to the developers? This violates user privacy. Gathering usage statistics can be very useful to the developers in more ways than one, but to do so without requesting permission remains a violation of privacy.

Have you encountered ethically problematic software? Or perhaps have you found some exemplar of ethical software development? Why not give an example in the comments below...