Chameth.com - posts like shoring-up-sshd, utility-user-stories but not why-you-should-be-using-https

On the utility of user stories

2021-10-16T00:00:00Z

User stories are a staple of most agile methodologies. You’d be hard-pressed to find an experienced software developer that’s not come across them at some point in their career. In case you haven’t, they look something like this:

As a frequent customer,
I want to be able to browse my previous orders,
So that I can quickly re-order products.

They provide a persona (in this case “a frequent customer”), a goal (“browse my previous orders”) and a reason (“so that I can quickly re-order products”). This fictitious user story would probably rank among one of the better ones I’ve seen. More typically you end up with something like:

As a user,
I want to be able to login,
So that I can browse while logged in.

This doesn’t really provide a persona or any proper reasoning. It’s just a straight-forward task pretending to be a user story. If this is written in an issue then it provides no extra information over one that simply says “Allow users to login”. In fact, because it’s expressed so awkwardly I’d argue that it’s worse.

This kind of task-disguised-as-a-user-story problem becomes more obvious when people try to write technical tasks in the same way:

As a developer,
I want to refactor the JobFactory,
So that I can work with it more efficiently in the future.

This just says “Refactor the JobFactory”. If you wrote that in a ticket you’d probably feel bad for not describing it very well, but somehow when it’s dressed up as a user story it feels more valuable.

Does the user really want that?

One thing that really irks me about user stories is that it lets you twist your business objectives into sounding like they’re the user’s idea: the story becomes a post-hoc justification for a task you decided was required.

Say you’re making a mobile app for an online book store, and your team for whatever reason has a target of increasing the number of users who view the daily book-of-the-day offer. Maybe you do some interviews and users tell you they forget to check in each day to see what the offer is. How can you funnel more users there?

As a mobile app user,
I want to receive a push notification whenever a new book-of-the-day is available,
So that I have the chance to buy the book.

Some users probably do want such a thing, but I’d argue the vast majority of them do not. Imagine if every app on your phone alerted you whenever there was a new deal, or popped up a dialog whenever you went near a physical shop they had vouchers for…

Obviously in the cold reality of capitalism businesses make money by doing things not strictly in the interests of users¹. When written up like this it becomes so painfully disingenuous, though. Despite writing a user story that starts with the words “As a user”, you’re not really putting yourself in the user’s shoes.

Who even is the user?

One of the big benefits of user stories comes from using personas to describe users. It’s also one of the things that’s rarely actually done, at least in my experience. Looking at Google Trends you can see the rise of searches for “user story” as agile slowly takes over the world, but the movement in searches about personas is very slight:

Graph showing relative search frequency for user stories against user personas

A lot of the time stories are just written with “As a user”, or have some adjectives tacked on to the start (“as a mobile user”, “as a logged-in user”). The best I’ve ever seen in the wild was specifying the class of user like in the example at the start: “as a frequent customer”, or “as a visually impaired user”.

The problem with using these classes is it requires you to come up with them when you’re writing the story. Maybe one day you think about visually impaired users, but the next you don’t. Maybe Bob thinks about certain classes of users, but Alice concentrates on different ones.

The ideal way to solve this is to come up with personas that all the team understand. For example:

Kiera is addicted to books. She reads across genres, and often buys books to gift to her friends and family. She has piles and piles of books to read, but that doesn’t stop her ordering more if she sees a good deal. She likes receiving new books almost as much as reading them, and opts for the fastest delivery available.
Sharon is a slow, methodical reader. She buys one book at a time when she’s close to finishing her current one, and gifts or resells her old books. She almost exclusively reads Science Fiction, and will generally read complete series from start to finish. She’s short-sighted and often struggles when using mobile phones or computers.

You’d probably want 2-4 personas that collectively represent most facets of your userbase. They can be a lot more fleshed out than these - if you search for example user personas you’ll find many beautifully presented examples that have complete backgrounds including hobbies, education levels, and so on. Even with this minimal level of detail, though, I’d argue they’re more useful than just writing things in a standard user story form.

Thinking back to the story about push notifications, writing it to use one of these two personas forces you to think about the trade-offs involved. Kiera probably would like a notification, but it would annoy and possibly confuse Sharon. This then leads you down the path of considering how to accommodate both types of user — maybe adding it as an option, or doing some fancy machine learning, etc. The conversation is now focused around the users, rather than steamrolling over them to reach a business objective.

You’re holding it wrong

The problems I’ve described are not a problem with user stories per se, but rather common issues with how they’re used. But there’s only so many times you can tell people they’re holding a tool wrong before you have to accept that maybe the tool was badly designed.

Considering features from the perspective of multiple personas is the single best thing you can possibly do to ensure you’re providing value to your users. You don’t even need to write things in the typical user story style to benefit from this.

Tacking “As a user,” to the start of all your JIRA tickets isn’t being agile, and isn’t good for users, even if it lets you tick a box somewhere. In some cases this lip-service to users is actively detrimental to them. We should be valuing users and personas over stilted templates and check-box exercises (remind you of anything?).

As a user, I want to pay more money for the things that I buy, so that the company’s CEO can afford to go to space. ↩︎

Shoring up SSHd configuration

2016-10-18T00:00:00Z

I recently came across a useful tool on GitHub called ssh-audit. It’s a small Python script that connects to an SSH server, gathers a bunch of information, and then highlights any problems it has detected. The problems it reports range from potentially weak algorithms right up to know remote code execution vulnerabilities.

This is the kind of output you get when running ssh-audit. In this particular example, I’m looking at GitHub’s SSH server and have filtered the output to just warnings and failures:

Output of ssh-audit pointing at GitHub’s SSH servers

GitHub’s a bit of a special case, as they’re trying to cope with scores of developers pushing code: they can’t disable weaker algorithms without also stopping lots of people being able to use their service. Still, from the output you can see that ssh-audit has spotted a known vulnerability (CVE-2016-076) and has a lot to say about the various types of supported algorithms.

Background: crypto algorithms used by SSH

Establishing an SSH connection is a moderately complex endeavour, and various parts involve the use of a number of different cryptographic algorithms:

The first such algorithm is the key exchange algorithm. This is the process by which the client and the server agree on a shared key that will be used later. Next comes the host-key algorithm; this is how the server proves its identity to the client. Most SSH users will be familiar with warnings like the following:

$ ssh server.example.com
The authenticity of host 'server.example.com (11.22.33.444)' can't be established.
ED25519 key fingerprint is SHA256:rPVMho1fhEkJqvgce/8iAl353dX5QkGT9F3uCFndsa.
Are you sure you want to continue connecting (yes/no)?

The warning means that the SSH client doesn’t recognise the server’s key, and is asking the user to confirm it. If the key changes later, the SSH client will refuse to connect. In the warning above you can see the algorithm used by the server was ED25519.

Next up is the encryption algorithm, which handles actually encrypting the data sent over the connection. Finally comes the message authentication code algorithm, commonly referred to as ‘mac’. The mac algorithm is effectively responsible for signing each message as a proof that it came from the other party.

Following the recommendations

ssh-audit’s recommendations are pretty easy to follow. It points and shouts at a particular algorithm, and you configure SSHd to not allow it. This is a snippet from my new SSHd config, which gets no complaints from ssh-audit:

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

What’s more interesting is the reasoning behind some of the algorithms removed. The ecdh-sha2-nistp series of key exchange algorithms are subject to a sidechannel attack described in a paper in 2014. Some people are also concerned about the involvement of NIST, and the potential for backdoors. Various other key exchange algorithms use too small a number of bits in the key exchange (e.g. diffie-hellman-group1-sha1, which uses 1024). Others still use known-bad hash algorithms (e.g. diffie-hellman-group14-sha1, which uses an acceptable 2048 bit modulus, but relies on SHA1 hashes). ssh-audit only treats the use of SHA1 as a warning, but there’s no compelling reason to keep it around if you’re using remotely modern clients to connect. Similarly the host-key DSA algorithm uses a 1024 bit key, so should be disabled.

Many of the rejected encryption algorithms use basically-broken algorithms (3des-cbc and arcfour for example). Some of the remaining are block ciphers with small block sizes, which makes them weak (e.g. blockfish-cbc uses a block size of 64 bits).

Many of these concerns also apply to mac algorithms (e.g. eliminating hmac-md5, hmac-sha1-etm@openssh.com, etc, as they use weak hash algos). Of particular note, OpenSSH supports the hmac-ripemd160 and hmac-ripemd160-etm@openssh.com algorithms. RIPEMD160 isn’t that common but, like SHA1, is considered to be weak. One other concern with mac algorithms is the order in which the encryption and mac attachment are performed. Encrypt-then-mac is the preferred way of doing it (i.e., the message is encrypted, then a MAC of the ciphertext is attached). The default used in SSH is encrypt-and-mac, where the mac of the plaintext is attached after encryption. Attaching the plaintext mac potentially leaks information (a mac is designed to provide integrity, not confidentiality, after all). The encrypt-then-mac algorithms are indicated by the -etm suffix.

Other changes

In addition to the ssh-audit inspired changes, I took the time to review the rest of my standard SSH configuration. The config touches on a few areas; I’m only going to highlight a couple of them:

  PubkeyAuthentication yes
  RhostsRSAAuthentication no
  HostbasedAuthentication no
  ChallengeResponseAuthentication no
  PasswordAuthentication no

Here all authentication methods other than public key are disabled. A decent key (used in combination with good crypto algorithms!) is drastically harder to brute force than a very good password. It’s also less prone to accidentally being copied into the wrong place, provided to the wrong server, etc.

- UsePrivilegeSeparation yes
+ UsePrivilegeSeparation sandbox

Switching UsePrivilegeSeparation from ‘yes’ to ‘sandbox’ tells OpenSSH to employ kernel sandbox mechanisms on the unprivileged process. This adds another layer of defence in case there’s a severe exploit in OpenSSH itself.

An unexpected side effect

After reconfiguring OpenSSH, all of my servers stopped reporting SSH brute force attempts. Every day prior to the change saw hundreds of connections and, after rate limiting and automatic banning blocked a fair chunk, about two dozen unsuccessful login attempts. With the new algorithm selections in place, there were still hundreds of connections, but no failed login attempts at all. A closer look at the logs showed this:

fatal: Unable to negotiate with 1.2.3.4 port 55025:
  no matching key exchange method found. Their offer:
    diffie-hellman-group14-sha1,
    diffie-hellman-group-exchange-sha1,
    diffie-hellman-group1-sha1

Apparently not a single one of the clients trying to bruteforce their way in supported the one key exchange algorithm I now allow. I guess at some point they’ll be updated with a modern crypto stack, but until then it’s going to be oddly peaceful…