I live in an area where car parking is scarce, and as such, myself and my girlfriend rent a parking space in a small, unsecured car park nearby. We pay about £150/month for the privilege, and are currently able to swap which car is in our space as and when we like. In an ideal world, we’d share a car; but for us, this isn’t an ideal solution – our schedules sometimes conflict, and there are times where we both need our cars, or when having a specific car closer to the house is beneficial (I’m a guitarist, so if I may need to be temporarily close to the house to load up my car for a gig, for example).

With this system, we’re also afforded the ability to find rare on-street parking in advance of having a visitor with reduced mobility, so we can at least make sure our visitors can park near our house!

Recently, our letting agent installed a CAME parking/”boom” barrier at the gate of our car park, without contacting us. On a piece of A4 paper attached to the barrier was a notice in small text, advising that this barrier would be active from 1st May – I use my car fairly regularly, and first noticed this in early April, so not a huge amount of notice. The paper went on to advise that we must visit the letting agent’s office to retrieve a key fob for the gate before this date.

Problem 1 – Lack of contact, timescale – ignorance

We are still currently in the throes of a pandemic, despite an increasing amount of the world now acting as if we are not. If I, as a young, fairly observant, healthy person, who uses their car regularly, only noticed this change by chance within 2-3 weeks until the date required, imagine the following user stories:

1. A (potentially elderly) person who uses their car sparingly

2. Someone who stores a classic car or motorcycle in one of the garages within the car park, only using it when the weather and their schedule suits.

3. Someone who is off island for a relatively long holiday, bearing in mind that travel hasn’t been possible for many for over two years, and we have had a decent run of bank holidays that would make this an attractive idea at this time of year.

4. Someone who has contracted COVID-19 and has to self isolate for ~two weeks.

With any of these use cases, due to not being contacted directly, the user would likely arrive to use their vehicle past the “cut-off date” to find that they cannot leave or enter the car park, their vehicle effectively trapped.

This is the equivalent of forcing two-factor authorisation to login to your website, without directly notifying existing users of the change – assuming that they would attempt to login within a two-week window of making this change AND notice the small print on their account page, AND be in a position to accommodate this fairly immediately.

Problem 2 – Security being implemented without consideration of impact

I am all for increased security, particularly in software. But developers see this kind of half-baked thinking all the time – security being bulldozed into a solution/platform without consideration for the impact on all facets of the business, use cases, or essential work. A security solution should be put in place in a way that has clearly considered these aspects, and the impacts of such a change. Want to introduce a restricted “jump server” so that engineers cannot directly connect to production systems? Sure, makes sense from a cybersecurity sense! We don’t want anyone who has been able to access an internal account to directly connect to production, or rogue internal actors to steal sensitive data (or, we want to make sure such actions are difficult/auditable). Totally get that – so you’d probably want to restrict access to the internet, along with ability to copy data to and from the jump server. Fine – get it implemented. Sounds great – until something major goes wrong in production, and a developer needs to urgently run some code against the live system to fix it – in an ideal world, this wouldn’t happen, but this is a pretty big crisis and solutions need to be quick. How would they get the code onto the jump server without the ability to copy data? Perhaps they could retrieve it from source control – until you realise that internet access has also been locked down. You must consider these cases and have solutions in place that toe the line between security and usability/agility, before the security solution is chucked in – otherwise, users will just find hacky, unsecure ways around your security, defeating the purpose – the alternative is that users will be unable to do their job, potentially with a greater financial detriment than the security measures would prevent.

I’m certainly not saying that security should be ignored, or backdoors implemented to make certain people’s lives easier – but a balance must be struck and at the least, well understood and thought-out processes must be in place before security implementation (that allow a team to work at least similarly quickly to before restrictions are implemented).

Anyway – onto the parking barrier! As I mentioned earlier, my use case involves using the parking space for multiple vehicles, as I believe is the case for other car park users. This is at best a mild inconvenience, but it’s a good example of a real-world haphazard security implementation: we are only given one key fob per parking space! It’s not always easy/possible to hand-over the fob prior to another user using the space – if I am currently using the space, and have a limited timeframe to move my car before my girlfriend needs to use the space, I would usually just need to find a road parking space nearby, and the space is all hers. Not so now – I now need to factor in a hand over of the fob between myself moving my car, and her arriving in hers – or wait around the car park to open it for her. This isn’t always possible due to the conflicting schedules mentioned above, or what if the person holding the fob is currently far away when the space is needed – sure, I could drive to her and hand her the fob then, but that’s just not always possible! Perhaps she could pick it up from the house – but that would rely on one or both of us being able to find a space close enough to not be an inconvenience, and for situations like the current fob-holder not needing to drive elsewhere and requiring the space when they return. There are solutions, but they are a little clunky compared to the previous use we enjoyed for £150/month.

These fobs cost approximately £5-10, and require a couple of minutes of pressing a button to pair with the gate – so I assumed that our letting agent may have considered this eventuality. Surely they can just provide us with a spare fob?

Nope! One fob, one parking space. If we want a spare, or lose our current fob, we are held to ransom to the tune of an additional one month rental (so, £150 for a £5 fob and two minutes of pairing). They have clearly not considered all use cases and are either blatantly overcharging people, or have bought the bare minimum of fobs, thus requiring some contractor to overcharge them for the pairing of a new one.

Like any mischievous developer would in a situation like this, my first thought was: how can I overcome this annoyance? I’m getting a worse, less convenient service for the same price, and I find it frankly insulting to be told a cheaply made, tiny circuit board + two minutes of labour will cost me the same as one month of in-demand parking, just to achieve a similar freedom to that which we once enjoyed. I opened up the fob, checked the board online to see if it can be easily cloned – hoping the fob was a “fixed code” (i.e. easily cloneable) so I could get my own copies for a couple of quid. Sigh… It’s a rolling code system, based on the HCS301 microchip. More secure, but pretty unnecessary for a parking barrier in this use case (where someone malicious could simply walk around it) in a car park with about 30 spaces. I find it hard to believe anyone would clone the fixed code to use a parking space without paying for it, given that the main thing they are trying to stop is opportunistic drivers spotting an empty space there among the lack of on-street parking… So, these systems are technically cloneable, but the cloned code would only work once (as a new code is generated with each use, using a rolling code), or, if you were able to clone the entire chip/serial to produce basically an identical copy of the code sequence, one fob would always be out of sequence with the other, requiring multiple button presses before the other fob was actually “in sync” with the code that the barrier was expecting. If the letting agent had used a fixed code, it would be less secure, but the deterrent of a barrier would be there for presumably the main reason that it exists (to stop opportunistic parkers who can’t find street parking in the area from using these spaces) – and the letting agent themselves could produce extra fobs easily, cheaply, and without anyone needing to physically visit the barrier.

This has been quite a long rant for such a minor inconvenience, but I think it illustrates a pretty big gripe of mine in the software dev world, with a real-world example – the best security solution must consider context, risk level of the thing you are protecting, use cases, and have plans in place for users to complete the same actions as before (provided they are allowed) – BEFORE implementation!