Let's Talk About Security
Anthony Eden
on
I'm sure you read the story about @n. I read the article too.
First let me say that what happened to Naoki is terrible. Being the victim of extortion and thievery is awful. Adding the lack of empathy from the facilitators of this extortion and theivery just adds insult to injury.
This can happen to anyone, so let's talk about security…
Security
Security is always about tradeoffs. You trade convenience and cost for layers of security.
Consider 2 factor auth (2FA), i.e. the requirement that access to something requires two separate authentication mechanisms (username and password plus a secure, generated token on a separate device for example). 2FA adds an additional layer of security on top of existing username/password combinations. It also adds an additional layer of cost and complexity: you must have your device on hand, you must be able to generate a token, and if you cannot generate a token you must not be able to access the service.
One suggestion that was made by Naoki:
If you are using your Google Apps email address to log into various websites, I strongly suggest you stop doing so. Use an @gmail.com for logins.
Unfortunately, this can be problematic as well, and may be a worse alternative than using your own domain. The issue here is that you can lose control of your Gmail account as well. You have no control over how Google runs its service and if they decide to disable your account, they're well within their right to do so, and unless you are using a custom domain you cannot switch to another provider easily. If, on the other hand, you use your own domain then you can change providers, but you have to ensure that the domain remains secure. You could even run your own email server, but then you need to ensure that you can receive emails properly, that your own email system is secure, so on and so forth. More tradeoffs.
Humans
Let's just say you're willing to tradeoff some convenience for more security through the power of technology. You've enabled 2FA on as many services you use that you can. You use a password generator for each service. You don't provide obvious answers to verification questions.
You are still at the mercy of the humans that run all of these services, and humans are fairly well known to be error prone.
What should you be looking for then in the service? How do you know the humans at the service will not allow someone to change account details on someone's behalf based just on something like the last 4 digits of a credit card. For many customer service representatives, and the managers who define the policies they follow, it seems totally legitimate to accept the last 4 digits of your card on file as verification that you are who you say you are. Clearly this can not be trusted. So how then is a customer support rep supposed to differentiate a customer with legitimate problems accessing their account from an attacker who is trying to manipulate them?
The Answer
The answer is that for each layer you add, for each tradeoff you make, you may be decreasing the likelihood your account will be compromised, but you cannot remove the possibility completely.
What I don't understand is this: when we at DNSimple handle a customer support issue, we keep a history of it. We also communicate with each other - the minute something like this shows up we would lock down the account and begin going through all of the available data we have to figure out what happened. The real question is how come this problem was so easily brushed aside by the services involved?
My point is this: you can't always stop maliciousness, but you damn sure can make more of an effort to sort it out correctly when it happens. Not every company seems to care about this, but I assure you, we do.
So find companies that empower their employees to empathize with you, to find solutions to problems. Don't do business with companies where empathy is not allowed.
Anthony Eden
I break things so Simone continues to have plenty to do. I occasionally have useful ideas, like building a domain and DNS provider that doesn't suck.
We think domain management should be easy.
That's why we continue building DNSimple.
