This week I’ve had an interesting conversation with an organisation with which I’m involved*. My involvement is as a volunteer, and has nothing to do with my day job – in other words, I have nothing to do with the organisation’s security. However, I got an email from them telling me that in order to perform a particular action, I should now fill in an online form, which would then record the information that they needed.
So this week’s blog entry will be about entering information on an online form. One of the simplest tasks that you might want to design – and secure – for any website. I wish I could say that it’s going to be a happy tale.
I had look at this form, and then I looked at the URL they’d given me. It wasn’t a fully qualified URL, in that it had no protocol component, so I copied and pasted it into a browser to find out what would happen. I had a hope that it might automatically redirect to an https-served page. It didn’t. It was an http-served page.
Well, not necessarily so bad, except that … it wanted some personal information. Ah.
So, I cheated: I changed the http:// … to an https:// and tried again**. And got an error. The certificate was invalid. So even if they changed the URL, it wasn’t going to help.
So what did I do? I got in touch with my contact at the organisation, advising them that there was a possibility that they might be in breach of their obligations under Data Protection legislation.
I got a phone call a little later. Not from a technical person – though there was a techie in the background. They said that they’d spoken with the IT and security departments, and that there wasn’t a problem. I disagreed, and tried to explain.
The first argument was whether there was any confidential information being entered. They said that there was no linkage between the information being entered and the confidential information held in a separate system (I’m assuming database). So I stepped back, and asked about the first piece of information requested on the form: my name. I tried a question: “Could the fact that I’m a member of this organisation be considered confidential in any situation?”
“Yes, it could.”
So, that’s one issue out of the way.
But it turns out that the information is stored encrypted on the organisation’s systems. “Great,” I said, “but while it’s in transit, while it’s being transmitted to those systems, then somebody could read it.”
And this is where communication stopped. I tried to explain that unless the information from the form is transmitted over https, then people could read it. I tried to explain that if I sent it over my phone, then people at my mobile provider could read it. I tried a simple example: I tried to explain that if I transmitted it from a laptop in a Starbucks, then people who run the Starbucks systems – or even possibly other Starbucks customers – could see it. But I couldn’t get through.
In the end, I gave up. It turns out that I can avoid using the form if I want to. And the organisation is of the firm opinion that it’s not at risk: that all the data that is collected is safe. It was quite clear that I wasn’t going to have an opportunity to argue this with their IT or security people: although I did try to explain that this is an area in which I have some expertise, they’re not going to let any Tom, Dick or Harry*** bother their IT people****.
There’s no real end to this story, other than to say that sometimes it’s the small stuff we need to worry about. The issues that, as security professionals, we feel are cut and dried, are sometimes the places where there’s still lots of work to be done. I wish it weren’t the case, because frankly, I’d like to spend my time educating people on the really tricky things, and explaining complex concepts around cryptographic protocols, trust domains and identity, but I (re-)learned an important lesson this week: if you’re an attacker, start at the front door. It’s probably not even closed: let alone locked.
*I’m not going to identify the organisation: it wouldn’t be fair or appropriate. Suffice to say that they should know about this sort of issue.
**I know: all the skillz!
***Or “J. Random User”. Insert your preferred non-specific identifier here.
****I have some sympathy with this point of view: you don’t want to have all of their time taken up by random “experts”. The problem is when there really _are_ problems. And the people calling them maybe do know their thing.
One thought on “The simple things, sometimes…”