The Twelve Days of Work-Life Balance

12 tips for working at home over the holidays

Disclaimer: the author refuses to take any blame for any resulting disciplinary or legal action taken against readers who follow any of the suggestions in this article.

There’s a good chance that things slow down for the holiday season at your organisation or company[1], and as they do, there’s a corresponding[2] chance that you may end up not going into the office for some of the upcoming days.  Some workplaces expect you to turn up to work in the office unless you’re officially on holiday, while others allow or encourage workers to be based at home and perform their duties there for all or some of the period.  It’s those people who will be spending time at home who are targeted by this article.

Working from home is an opportunity to bunk off and is a complete wheeze a privilege and responsibility to be taken seriously.  There are, however, some important techniques that you should take on board to ensure not only that you continue to be productive but, even more important, that you continue to be seen to be productive.  I’ve split my tips up into helpful headings for your ease of use.

Video calls

Tip 1 (for those who shave): you don’t need to.  Yes, the resolution on webcams has increased significantly, but who’s going to care if it looks like you’ve just rolled out of bed?  The fact that you’ve even bothered shows your commitment to the meeting you’re attending.

Tip 2 (for those who wear make-up): far be it from me to dictate whether you wear make-up or not to meetings.  But if you choose to, there’s no need to refresh last night’s make-up in the morning.  If you’ve staggered home late, you may not have got round to removing your party lipstick and mascara, and it may even have smudged or run a bit: don’t worry.  It’ll look “festive” in the morning, and will encourage a relaxed atmosphere at the meeting.

Tip 3 (for coffee drinkers): you may need an extra cup of coffee in the afternoon, to get you through the day.  Who’s going to know if you add a shot to it?  It’ll keep you warm, and possibly upright.  My wife swears by Baileys.  Or Irish Whiskey.  Or gin.  Pretty much anything, in fact.

Tip 4 (for non-coffee drinkers): cocktails are a no-no for video conferences, unless approved by management (sorry).  However, there are a number of other options to explore.  A Long Island Iced Tea looks like, well, and iced tea.  Whisky (or whiskey) can look like normal tea, and my personal favourite, cherry brandy, looks like a child’s fruit cordial that you didn’t dilute sufficiently.  And tastes fairly similar.

Tip 5 (for clothes wearers): few organisations (of which I’m aware, anyway) have adopted a non-clothing policy for video-calls.  Clothes are required.  My favourite option is to wear a festive jumper, but this is only fun if it has woven-in flashing lights which can distract your fellow participants[3].  Coordinating the periodicity of the flashing with colleagues gets you bonus points.

Tip 6 (also for clothes wearers): wear something on your bottom half.  I know you think you may not be getting up during the call, but when a small child vomits in the background, the postal worker arrives at the door, or you just need another cup of coffee or “beverage” (see tips 3 & 4) to get you through the next two hours, you’ll be grateful for this advice.

Teleconferences (non-video)

Tip 7: use a chat channel to have a side conversation with your peers. You can have hilarious discussions about the intellectual capacity and likely parentage of your management, or even better, play a game of meeting bingo.

Tip 8: the mute button is for cowards.  Yes, wind can be a problem after an over-indulgence at the pub, club or party the night before, and microphones can be quite sensitive these days, but who’s to know it’s you[4]?

Emails

Tip 9: the best time to respond to an email is when you receive it, right?  This will show everybody how devoted you are to your job.  So if it arrives after you’ve already partaken of a brew or two down the pub, or sampled the herbal opportunities recently decriminalised in your state in your bedroom, then replying immediately will almost certainly be considered responsible and professional.  And auto-correct will almost certainly act in your favour: after all, your boss really is a complete duck, yes?

Tip 10: pepper your emails with poor festive puns[5].  It’s just what you do.

Family

Tip 11: you may have agreed to “work” over this period as an excuse to avoid spending too much time with the family[6], but there’s always the chance that they will barge into your office, throw up in the hall (see tip 6), or just fall asleep on your keyboard[7].  Invest in a lock on your office door, or work somewhere out of range[8].  Your work is important, and you must guard against unwanted interruptions, such as being awoken from an important doze.

Productivity

Tip 12: it’s your responsibility, when working from home, to ensure that you maintain your productivity.  But breaks are important.  There’s a tricky balance here between protecting your time from the family (you don’t want them to notice that you’re not online 100% of the time) and taking sensible amounts of breaks.  Assuming that you’ve taken my advice about locking your office door, then placing an XBox or similar gaming console on your desk next to your work computer is a great way of allowing yourself some downtime without risking the wrath of your family (assuming careful monitor placement and controller handling).

Tip 12a (extra tip!): if you’re not careful, too much time hidden away from the family will get you in trouble.  My piece of advice here is to offer to help.  But on your own terms.  Rushing out of your office[9], looking harried and then announcing “I’ve got ten minutes until my next call, and I’m feeling guilty: is there anything I can do?” can gain you useful credit without the risk of your having to do anything too taxing.

Summary[10]

You can maintain a productive and professional workplace at home if called to do so by your organisation.  It is your responsibility to balance the needs of work with your needs and, of course, the needs of your family.

Have a Merry Christmas (or other festival) and a Happy New Year (whenever it falls for you)!


1 – this is generally a Judaeo-Christian set of holidays, but I hope that this article is relevant to most holidays: religious, national, regional or secular.

2 – and possibly correlateable, though check out one of my favourite XKCD comics: https://xkcd.com/552/.

3 – owners of luxuriant beards or heads of hair may prefer to weave flashing fairy lights into their hair for a similar effect.

4 – except for the small matter of the little indicator against each participant’s name which shows who’s “talking”.

5 – “Your presents is requested.”  “But wait—there’s myrrh.” You get the idea.

6 – “Sorry, darling, I know your parents are here, but a really critical bug came in, and I’m the only one who can look at it in time…”

7 – mainly a problem for owners of cats or teenagers.

8 – try searching for “Where’s a pub near me that’s open now?”.

9 – don’t forget to lock it again, in case a child notices and purloins that gaming console.

10 – in the Southern Hemisphere, at least.  Sorry: see [5].

 

What’s a certificate?

For want of a nail, the kingdom was lost.

There was a huge story in the UK last week about how an expired certificate basically brought an entire mobile phone network (O2) to its knees. But what is a certificate, why do they expire, and why would that have such a big impact? In order to understand, let’s step back a bit and look at why you need certificates in the first place.

Let’s assume that two people, Alice and Bob, want to exchange some secret information. Let’s go further, and say that Bob is actually Bobcorp, Alice’s bank, and she wants to be able send and receive her bank statements in encrypted form. There are well established ways to do this, and the easiest way is for them to agree on a shared key that they use to both encrypt and decrypt each others’ messages. How do they agrees this key? Luckily, there are some clever ways in which they can manage a “handshake” between they two of them, even if they’ve not communicated before, which ends in their both having a copy of the key, without the chance of anybody else getting hold of it.

The problem is that Alice can’t actually be sure that she’s talking to Bobcorp (or vice versa). Bobcorp probably doesn’t mind, at this point, because he can ask Alice to provide her login credentials, which will allow him to authenticate her. But Alice really does care: she certainly shouldn’t be handing her login details to somebody – let’s call her “Eve” – who’s just pretending to be Bob.

The solution to this problems comes in two parts: certificates and Certificate Authorities (CAs). A CA is a well-known and trusted party with whom Bobcorp has already established a relationship: typically by providing company details, website details and the like. Bobcorp also creates and sends the CA a special key and very specific information about itself (maybe including the business name, address and website information). The CA, having established Bobcorp’s bona fides, creates a certificate for Bobcorp, incorporating the information that was requested – in fact, some of the information that Bobcorp sends the CA is usually in the form of a “self-signed certificate”, so pretty much all that the CA needs to do is provide its own signature.

Astute readers will be asking themselves: “How did this help? Alice still needs to trust the CA, right?” The answer is that she does. But there will typically be a very small number of CAs in comparison to Bobcorp-type companies, so all Alice needs to do is ensure that she can trust a few CAs, and she’s now good to go. In a Web-browsing scenario, Alice will usually have downloaded a browser which already has appropriate trust relationships with the main CAs built in. She can now perform safe handshakes with lots of companies, and as long as she (or her browser) checks that they provide certificates signed by a CA that she trusts, she’s relatively safe.

But there’s a twist. The certificates that the CA issues to Bobcorp (and others) typically have an expiration date on them. This isn’t just to provide the CA with a recurring revenue stream – though I’m sure that’s a nice benefit – but also in case Bobcorp’s situation changes: what if it has gone bankrupt, for instance, or changed its country of business?[1] So after a period of time (typically in the time frame of a year or two, but maybe less or more), Bobcorp needs to reapply to get a new certificate.

What if Bobcorp forgets? Well, when Alice visits Bobcorp’s site and the browser notices an expired certificate, it should want her not to proceed, and she shouldn’t give them any information until it’s renewed. This sounds like a pain, and it is: Bobcorp and its customers are going to be severely inconvenienced. Somebody within Bobcorp whose job it was to renew the certificate is going to be in trouble.

Life is even worse in the case where no actual people are involved. If, instead of Alice, we have an automated system A, and instead of Bob, we have an automated system, B. A still needs to trust that it’s talking to the real B in case an evil system E is pretending to be B, so certificates are still required. In this case, if, B’s certificate expires, A should quite rightly refuse to connect to it. This seems to have been what happened to cause the mobile data outage that O2 is blaming on Ericsson, one of its suppliers. There was no easy way to fix the problem, or tell the many, many A-type systems that may have been trying to communicate with the B system(s) to carry on regardless. And so, for want of a nail, the kingdom was lost.

The lesson? Avoid single points of failure, think about fall-back modes. And be ready to move to remedy unexpected errors. Quickly.


1 – there are also various mechanisms to revoke, or cancel, certificates but hey they are typically complex, ill-implemented in many cases, and consequently little-used.

On conversation and the benefits of boasting

On Monday and Tuesday this week I’m attending DevSecCon in Boston – a city which is much more pleasant when it’s not raining or snowing, which it often seems to be doing while I’m here.  There are a bunch of interesting talks[1] and workshops, and I was asked, at the last minute, to facilitate an “Open Space Discussion” at the end of the first day (as two people hadn’t arrived as expected).  Facilitating discussions is about not talking all the time, but encouraging other people to talk[2]: my approach to this is to tell a story, and then encourage them to share stories.

People enjoy listening to stories, and people enjoy telling stories, and there is a type of story that is particularly useful and important in the world of work: “war-stories”.  Within the IT industry, at least, this refers to stories about experiences – usually bad experiences – from our day-to-day working lives.  They are often used to illustrate a point or lend experiential weight to an opinion being put forward. But they are also great learning experiences.

What I learned yesterday – or re-learned – is the immense value of conversation with our peers in a neutral setting, with no formal bounds or difference in “rank”.  We had at least one participant who was only two years out of college, participants with 25-30 years of experience, a CISO of a major healthcare provider, a CEO, DevOps engineers, customer-facing people, security people, non-security people, people with Humanities[4] degrees, people with Computer Science degrees.  We were about twelve people, and everybody contributed, to greater or lesser degrees.  I hope that we managed to maintain a conversation where age and numbers of years in the industry were unimportant, but the experiences shared were.

And I learned about other people’s opinions, their viewpoints, their experiences, their tips for what works – and doesn’t work – and made, I hope, some new friends.  Certainly some new peers.  What we talked about isn’t vitally important to this article[5]: the important thing was the conversation, and the stories they told that brought their shared wisdom to the table.  I felt, by the end of the session, that we had added something to the commonwealth of knowledge within the industry

I was looking for a way to close the session as we were moving to the end, and hit upon something which seemed to work: I encouraged everybody to spend 30 seconds or so to tell the group about an incident in their career that they are proud of.  We got some great stories, and not only did we learn from them, but I think it’s really important that we get the chance to express our pride in the things that we’ve done.  We rarely get the chance to boast, or to let people outside our general circle know why we think we should be valued.  There’s nothing wrong with being proud of the things we’ve done, but we’re often – usually – discouraged from doing so.  It was great to have people share their various experiences of personal expertise, and to think about how they would use them to further their career.  I didn’t force everybody to speak – and was thanked by one of the silent participants later – and it’s important to realise that not everybody will be happy doing so.  But I think that the rapport that we’d built as a group meant that more people were happy to contribute something than would have considered it at the beginning of the session.  I left with a respect for all of the participants, and a realisation of the importance of shared experience.

 


1 – I gave a talk based on my blog article Why I love technical debtI found it interesting…

2 – based on this definition, it may surprise regular readers – and people who know me IRL[3] – that I’d even consider participating, let alone facilitating.

3 – does anybody use this term anymore?

4 – Liberal Arts/Social Sciences.

5 – but included:

  • the impact of different open source licences
  • how legal teams engage with open source questions
  • how to encourage more conversation between technical and legal folks
  • the importance of systems engineering
  • how to talk to customers and vendors
  • how to build teams through social participation[6]
  • the NIST 800 series and other models to consider security
  • risk: how to talk about it, measure it, discuss it with other functions within the organisation.

6 – the word “beer” came up.  From somebody else, on this occasion.

 

My brush with GDPR

I ended up reporting a possible breach of data. My data

Since the first appearance of GDPR[1], I’ve strenuously avoided any direct interaction with it if at all possible.  In particular, I’ve been careful to ensure that nobody is under any illusion that my role involves any responsibility for our company’s implementation of GDPR.  In this I have been largely successful.  I say largely, because the people who send spam don’t seem to have noticed[2]: I suspect that anybody with the word “security” in their title has had a similar experience.

Of course, I have a decent idea what GDPR is supposed to be about: making sure that data that organisations hold about people is only used as it should be, is kept up to date, and that people can find out what exactly what information relating to them exactly is held[3].

This week, I got more involved GDPR than I’d expected: I ended up reporting a possible breach of data.  My data.  As it happens, my experience with the process was pretty good: so good, in fact, that I think it’s worth giving it as an example.

Breach!

A bit of scene-setting.  I live in the UK, which is (curently[4]) in the EU, and which means that, like pretty much all companies and organisations here, it is subject to the GDPR.  Last week, I had occasion to email a department within local government about an issue around services in my area.  Their website had suggested that they’d get back to me within 21 days or so, so I was slightly (and pleasantly) surprised when they replied within 5.

The email started so well: the title referred to the village in which I live.

It went downhill from there.  “Dear Mr Benedict[5]”, it ran.  I should be clear that I had used my actual name (which is not Benedict) for the purposes of this enquiry, so this was something of a surprise.  “Oh, well,” I thought to myself, “they’ve failed to mail merge the name field properly.” I read on.  “Here is the information you have requested about Ambridge…[5][6]”.  I do not live in Ambridge.  So far, this was just annoying: clearly the department had responded to the wrong query.  But it got worse.  “In particular regards to your residence, Willow Farm, Ambridge…[5]”

The department had sent me information which allowed me to identify Mr Benedict and his place of residence.  They had also failed to send me the information that I had requested.  What worried me more was that this might well not be an isolated event.  There was every chance that my name and address details had been sent to somebody else, and even that there was a cascade effect of private details being sent to email address after email address.  I mentioned this in annoyance to my wife – and she was the one to point out that it was a likely breach of GDPR.  “You should report it,” she said.

So I went to the local government office website and had a quick look around it.  Nothing obvious for reporting GDPR breaches.  I phoned the main number and got through to enquiries.  “I’d like to report a possible data breach, please,” I said.  “Could you put me through to whoever covers GDPR?”

To be honest, this was where I thought it would all go wrong.  It didn’t.  The person on the enquiries desk asked for more information.  I explained what department it was, about the email, and the fact that somebody else’s details had been exposed to me, I strongly suspected in breach of GDPR.

“Let me just see if I can find someone in our data team,” she said, and put me on hold.

I don’t know if you’ve ever been put on hold by someone in a local government office, but it’s rarely an event that should be greeted with rejoicing.  I prepared myself for a long wait, and was surprised when I was put through to someone fairly quickly.

The man to whom I spoke knew what he was doing.  In fact, he did an excellent job.  He took my details, he took details of the possible breach, he reassured me that this would be investigated.  He was polite, and seemed keen to get to the bottom of the affair.  He also immediately grasped what the problem was, and agreed that it needed to be investigated.  I’m not sure whether I was the first person ever to call up and so this was an adrenaline-fuelled roller coaster ride into uncharted territory[8] for him, or whether this was a routine conversation in the office, but he pitched his questions and responses at exactly the right level.  I offered to forward the relevant email to him so that he had the data himself.  He accepted.  The last point was the one that impressed me the most.  “Could you please delete the email from your system?” he asked.  This was absolutely the right request.  I agreed and did so.

And how slowly do the wheels of local government grind?  How long would it take me to get a response to my query?

I received a response the next day, from the department concerned.  They assured me that this was a one-off problem, that my personal data had not been compromised, and that there had not been a widespread breach, as I had feared.  They even sent me the information I had initially requested.

My conclusions from this?  They’re two-fold:

  1. From an individual’s point of view: yes, it is worth reporting breaches.  Action can, and should be taken.  If you don’t get a good response, you may need to escalate, but you have rights, and organisations have responsibilities: exercise those rights, and hold the organisations to account.  You may be pleasantly surprised by the outcome, as I was.
  2. From an organisation’s point of view: make sure that people within your organisation know what to do if someone contacts them about a data breach, whether it’s covered by statutory regulations (like GDPR) or not.  This should include whoever it is answers your main enquiry line or receives messages to generic company email accounts, and not just your IT or legal departments.  Educate everybody in the basics, and make sure that those tasked with dealing with issues are as well-trained and ready to respond as the people I encountered.

1 – General Data Protection Regulation, wouldn’t it be more fun if it were something like “Good Dogs Pee Regularly?”

2 – though GDPR does seem to have reduced the amount of spam, I think.

3 – if you’re looking for more information, I did write an article about this on Opensource.com earlier this year: Being open about data privacy.

4 – don’t start me.

5 – I’ve changed this information, for reasons which I hope are obvious.

6 – “dum-di-dum-di-dum-di-dum, dum-di-dum-di-da-da”[7]

7 – if you get this, then you either live in the UK (and probably listen to Radio 4), or you’re a serious Anglophile.

8 – hopefully not so uncharted for the designers and builders of the metaphorical roller coaster.

Jargon – a force for good or ill?

Distinguish an electrical engineer from a humanities graduate: ask them how many syllables are in the word “coax”.

I was involved in an interesting discussion with colleagues recently about the joys or otherwise or jargon.  It stemmed from a section I wrote in a recent article, How to talk to security people: a guide for the rest of us.  In it, I suggested that jargon “has at least two uses:

  1. as an exclusionary mechanism for groups to keep non-members in the dark;
  2. as a short-hand to exchange information between ‘in-the-know’ people so that they don’t need to explain everything in exhaustive detail every time.”

Given the discussion that arose, I thought it was worth delving more deeply into this question.  It’s more than an idle interest, as well, as I think that there are important lessons around our use of jargon that impact on how we interact with our colleagues and peers, and which deserve some careful thought.  These lessons apply particularly to my chosen field of security.

Before we start, there should be some definition.  It’s always nice to have two conflicting versions, so here we go:

  1. Special words or expressions used by a profession or group that are difficult for others to understand. (Oxford dictionaries – https://en.oxforddictionaries.com/definition/jargon)
  2. Without qualifier, denotes informal ‘slangy’ language peculiar to or predominantly found among hackers. (The Jargon File – http://catb.org/jargon/html/distinctions.html)

I should start by pointing out that the Jargon File (which was published in paper form in at least two versions as The Hacker’s Dictionary (ed. Steele) and the New Hacker’s Dictionary (ed. Raymond)) has a pretty special place in my heart.  When I decided that I wanted to “take up” geekery properly[1][2], I read my copy of the the New Hacker’s Dictionary from cover to cover, several times, and when a new edition came out, I bought that and did the same.  In fact, for many of the more technical readers of this blog, I suspect that a fair amount of your cultural background is expressed within the covers (paper or virtual) of the same, even if you’re not aware of it.  If you’re interested in delving deeper and like the feel of paper in your hands, then I encourage you to purchase a copy, but be careful to get the right one: there are some expensive versions which seem just to be print-outs of the Jargon File, rather than properly typeset and edited versions[3].

But let’s get onto the meat of this article: is jargon a force for good or ill?

The case against jargon – ambiguity

You would think that jargon would serve to provide agreed terms within a particular discipline, and help ambiguity around contexts.  It may be a surprise, then, that first problem that we often run into with jargon is name-space clashes.  Consider the following.  There’s an old joke about how to distinguish an electrical engineer from a humanities[3] graduate: ask them how many syllables are in the word “coax”.  The point here, of course, is that they come from different disciplines.  But there are lots of words – and particularly abbreviations – which have different meanings or expansions depending on context, and where disciplines and contexts may collide.  What do these mean to you[5]?

  • scheduling (kernel level CPU allocation to processes OR placement of workloads by an orchestration component)
  • comms (I/O in a computer system OR marketing/analyst communications)
  • layer (OSI model OR IP suite layer OR other architectural abstraction layer such as host or workload)
  • SME (subject matter expert OR small/medium enterprise)
  • SMB (small/medium business OR small message block)
  • TLS (Transport Layer Security OR Times Literary Supplement)
  • IP (Internet Protocol OR Intellectual Property OR Intellectual Property as expressed as a silicon component block)
  • FFS (For Further Study OR …[6])

One of the interesting things is that quite a lot of my background is betrayed by the various options that present themselves to me: I wonder how many of the readers of this will have thought of the Times Literary Supplement, for example. I’m also more likely to think of SME as the term relating to organisations, because that’s the favoured form in Europe, whereas I believe that the US tends to SMB.  I’m sure that your experiences will all be different – which rather makes my point for me.

That’s the first problem.  In a context where jargon is often praised as a way of short-cutting lengthy explanations, it can actually be a significant ambiguating force.

The case against jargon – exclusion

Intentionally or not – and sometimes it is intentional – groups define themselves through use of specific terminology.  Once this terminology becomes opaque to those outside the group, it becomes “jargon”, as per our first definition above.  “Good” use of jargon generally allows those within the group to converse using shared context around concepts that do not need to be explained in detail every time they are used.  An example would be a “smoke test” – a quick test to check that basic functionality is performing correctly (see the Jargon File’s definition for more).  If everyone within the group understands what this means, then why go into more detail?  But if you are joined at a stand-up meeting[7] by a member of marketing who wants to know whether a particular build is ready for release, and you say “well, no – it’s only been smoke-tested so far”, then it’s likely that you’ll need to explain.

Another enduring and complex piece of jargon is the use of “free” in relation to software.  In fact, the term is so ambiguous that different terms have evolved to describe some variants – “open source”, “FOSS” – and even phrases such as “free as in speech, not as in beer”.

The problem is that there are occasions when jargon can be excluding from others, whether that usage is intended or not.  There have been times for most of us, I’m sure, when we want to show that we’re part of group and so use terms that we know another person won’t understand.  On other occasions, the term may be so ingrained in our practice that we use it without thinking, and the other person is unintentionally excluded.  I would argue that we need to be careful to avoid both of these usages.  Intentional exclusion is rarely helpful, but unintentional exclusion can be just as damaging – in ways more so, as it is typically unremarked and is therefore difficult to remedy.

The security world seems particularly prone to this behaviour, I feel.  It may be that many security folks have a sound enough grounding in other spheres – especially those in which they’re working with others – that the overlap in the other direction is less noticeable.  The other issue is that there’s a certain elitism with security folks which is both laudable – you want the best people, with the best training, to be leading the field – and lamentable – elitism tends to lead to exclusion of members of other groups.

A quick paragraph in praise of jargon

It’s not all bad, however.  We need jargon, as I noted above, to enable us to discuss concepts, and the use of terms in normal language – like scheduling – as jargon leads to some interesting metaphors which guide us in our practice[8].  We absolutely need shared practice, and for that we need shared language – and some of that language is bound, over time, to become jargon.  But consider a lexicon, or a FAQ, or other ways to allow your colleagues to participate: be inclusive, not exclusive.


1 – “properly” – really?  Although I’m not sure “improperly” is any better.

2 – oh, remember that I actually studied English Literature and Theology at university, so this was a conscious decision to embrace a rather different culture.

3 – or “Liberal Arts”.

4 – the most recent “real” edition of which I’m aware is Raymond, Eric S., 1996, The New Hacker’s Dictionary, 3rd ed., MIT University Press, Cambridge, Mass.

5 – I’ve added the first options that spring to mind when I come across them – I’m aware there are almost certainly others.

6 – believe me, when I saw this abbreviation in a research paper for the first time, I was most confused, and actually had to look it up.

7 – oh, look: jargon…

8 – though metaphors can themselves be constraining as they tend to push us to thinking in a particular way, even if that way isn’t entirely applicable in this context.

The gift that keeps on giving: passwords

A Father’s Day special

There’s an old saying: “if you give a man a fish, he’ll eat for a day, but if you teach a man to fish, he’ll eat for a lifetime.”  There are some cruel alternatives with endings like “he’ll buy a silly hat and sit outside in the rain”, but the general idea is that it’s better to teach someone something rather than just giving them something.

With Father’s Day coming up this Sunday in many parts of the world, I’d like to suggest the same for passwords.  Many people’s password practices are terrible.  There are three things that people really don’t get about passwords:

  1. what they should look like
  2. how they should be stored
  3. how they should be communicated.

Let’s go through each of these in turn, and I’ll try to give brief tips that you can pass onto your father (or, indeed, mother, broader family, friends or colleagues) to help them with password safety.

What should passwords look like?

There’s a famous xkcd comic called password strength which aims to help you find a useful password.  This is great advice if you only have a few passwords, but about twenty years ago I got above ten, and then started re-using passwords for certain levels of security.  This was terrible at the time, and even worse now.  Look at the the number of times a week we see news about information being lost when companies or organisations are hacked.  If you share passwords between accounts, there’s a decent chance that your login details for one will be exposed, which means that all your other accounts that share that set are compromised.

I know some people who used to have permutations of passwords.  Let’s say the base was “p4ssw0rd”: they would then add a suffix for the website or account, such as “p4ssw0rdNetflix”.  This might be fine if we believed that all passwords are stored in hashed form, but, well, we know they’re not, so don’t do this, either.  Extrapolating from one account to another is too easy.

What does a good password look like, then?  Here’s one: “W9#!=_twXhRb”  And another?  This one is 16 characters long: “*Wdb_%|#N^X6CR_b”  What are the chances of a human guessing these?  Pretty slim.  And a computer?  Not much better, to be honest.  They are randomly generated by software, and as long as I use a different one for each account, I’m pretty safe against password-guessing attacks.

“But,” you say, “how am I supposed to remember them?  I’ve got dozens of accounts, and I can’t remember one of those, let alone fifty!”

How should you store passwords?

Well, you shouldn’t try to remember passwords, in the same way that you shouldn’t try to generate them.  Oh, there will be a handful that you might remember – maybe low-importance ones like the wifi key to your home AP – but most of them you should trust to a password manager.  These are nifty pieces of software that will generate and then remember hundreds of passwords for you.  Some of them will even automatically fill website fields for you if you ask them to.  The best ones are open source, which means that people have pored over their code (hopefully) to check they’re trustworthy, and that if you’re not entirely sure, then you can pore of their code, too.  And make changes and improvements and generally improve the world bit by bit.

You will need to remember one password, though, and that’s the one to unlock the password manager.  Make it really, really strong: it’s about the only one you mustn’t lose (though most websites will help you reset a password if you forget it, so it’s just a matter of going through each of the several hundred until they’re done…).  Use the advice from the xkcd cartoon, or another strong password algorithm that’s easy to remember.

To make things more safe, store the (password protected) key store somewhere that is not easily accessed by other people – not a shared drive at work, for instance, but maybe on your phone or on some cloud-based storage that you can get to if you lose your phone.  Always set the password manager to auto-lock itself after some time, in case you leave your computer logged on, or your phone gets stolen.

How to communicate passwords

Would you send a password via email?  What about by SMS?  Is post[2] better?  Is it acceptable to reveal a password over the phone in a crowded train carriage[4]?  Would you give your laptop password to a random person conducting a survey on a railway station for the prize of a chocolate bar?

In an ideal world, we would never share passwords, but there are times when we need to – and times when it’s worthwhile for material rewards[5].  There are some accounts which are shared – TV or film streaming accounts for the family – or that you’ve set up for somebody else, or which somebody urgently needs to access because you’re on holiday, for instance.  So you may need to give out passwords from time to time.  What’s the best mechanism?  What’s the worst?

This may sound surprising, but I’d generally say that the worst (marginally) is post.  What you’re trying to avoid happening is a Bad Person[tm] from marrying two pieces of information: the username and the password.  If someone has access to your post, then there’s a good chance that they might be able to work out enough information about you that they can guess the account name.  The others?  Well, they’re OK as long as you’re not also sending the username via the same channel.  That, in fact, is the key test: you should never provide the two pieces of information in such a way that a person with access to one channel can put them together.   So, telling someone a password in a crowded train carriage may be rude in relation to all of the other people in the carriage[6], but it may be very secure in terms of account safety.

The reason I posed the question about the survey is that every few months a survey company in the UK asks people at mainline railway stations to tell them their password in exchange for a chocolate bar, and then write a headline about how awful it is that many people will give them their password.  This is a stupid headline, for a stupid survey, for two reasons:

  1. I’d happily lie and tell them a false password in order to get a free chocolate bar AND
  2. even if I gave them the correct password, how are they going to marry that with my account details?

Conclusion

If you’re the sort of person reading there’s a fairly high chance that you’re the sort of person who’s asked to clear up the mess what family, friends or colleagues get their accounts compromised[7].  Here are four rules for password security:

  1. don’t reuse passwords – use a different one for every single account
  2. don’t think up your own passwords – get a password manager to generate them for you
  3. use a password manager to store your passwords – if they’re strong enough in the first place, you won’t be able to remember them
  4. never send usernames and passwords over the same channel – you want to avoid the situation where an attacker has access to both and can use them.

I’ll add a fifth one for luck: feel free to use underhand tactics to get chocolate bars from people performing poorly-designed surveys on railway stations.


1 – I thought about changing the order, as they do impact on each other, but it made my head hurt, so I stopped.

2 – note for younger readers: there used to be something called “snail mail”.  It’s nearly dead[3].

3 – unless you forget to turn on “electronic statements” for your bank account.  Then you’ll get loads of it.

4 – whatever the answer to this is from a security point of view, the correct answer is “no”, because a) you’re going to annoy me by shouting it repeatedly down the phone because reception is so bad on the train that the recipient can’t hear it and b) because reception is so bad on the train that the recipient can’t hear it (see b)).

5 – I like chocolate.

6 – I’m not a big fan of phone conversations in railway carriages, to be honest.

7 – Or you’ve been sent a link to this because you are one of those family, friends or colleagues, and the person who sent you the link is sick and tired of doing all of your IT dirty work for you.

The most important link: unsubscribe me

No more (semi-)unsolicited emails from that source.

Over the past few days, the much-vaunted[1] GDPR has come into force.  In case you missed this[2], GDPR is a set of rules around managing user data that all organisations with data about European citizens must follow for those citizens.  Which basically means that it’s cheaper to apply the same rules across all of your users.

Here’s my favourite GDPR joke[3].

Me: Do you know a good GDPR consultant?

Colleague: Yes.

Me: Can you give me their email address.

Colleague: No.

The fact that this is the best of the jokes out there (there’s another one around Santa checking lists which isn’t that bad either) tells you something about how fascinating the whole subject is.

So I thought that I’d talk about something different today.  I’m sure that over the past few weeks, because of the new GDPR regulations,  you’ve received a flurry[4] of emails that fall into one of two categories:

  1. please click here to let us know what uses we can make of your data (the proactive approach);
  2. we’ve changed our data usage and privacy policy: please check here to review it (the reactive approach).

I’ve come across[5] suggestions that the proactive approach is overkill, and generally not required, but I can see what people are doing it: it’s easier to prove that you’re doing the right thing.  The reactive approach means that it’s quicker just to delete the email, which is at least a kind of win.

What I’ve found interesting, however, is the number of times that I’ve got an email of type 1 from a company, and I’ve thought: “You have my data?  Really?”  It turns out that more companies have information about me than I’d thought[6], and this has allowed me to click through and actually tell them that I want them to delete my data completely, and unsubscribe me from their email lists.  This then led me to thinking, “you know what, although I bought something from this company five years ago, or had an interest in something they were selling, at least, I now have no interest in them at all, or in receiving marketing emails from them,” and then performing the same function: telling them to delete and unsubscribe me.

But it didn’t stop there.  I’ve decided to have a clean out.  Now, when an email comes in from a company, I take a moment to decide whether:

  • I care about them or their product; OR
  • I’m happy for them to have my information in the first place.

If the answer to either of these questions is “no”, then I scroll down.  There, at the bottom of each mail, should be a link which says something like “subscription details” or “unsubscribe me”.  This has, I believe, been a legal requirement in many jurisdictions for quite a few years.  The whole process is quite liberating: I click on the link, and I’m either magically unsubscribed, or sometimes I have to scroll down the page a little to choose the relevant option, and “Bang!”, I’m done.  No more (semi-)unsolicited emails from that source.

I see this as a security issue: the fewer companies that have data about me, the fewer chances of misuse, and the lower the change of leakage.  One warning, however: phishing.  As I admitted in this blog last week, I got phished recently  (I got phished this week: what did I do?), and as more people take to unsubscribing by default, I can see this link actually being used for nefarious purposes, so do be careful before you click on it that it actually goes to where you think it should.  This can be difficult, because companies often use a third-party provider to manage their email services.  Be careful, then, that you don’t get duped into entering account details: there should be no need to log into your account to be deleted from a service.  If you want to change your mailing preferences for a company, then that may require you to log into your account: never do this from an email, always type go to the organisation’s website directly.


1 – I’ve always wanted to write that.

2 – well done, by the way.

3 – I’d provide attribution, but I’m not sure where it originated.

4 – or maybe a slurry?

5 – again, I can’t remember where.

6 – though I’m not that surprised.