Second-Guessing the CISO in an Emergency
Don’t do it.
Look, I know it’s personally gratifying, but just don’t do it. It’s easy to look at what appears to be a badly secured situation and say, “Why didn’t they just do X?” But I’d like to show an example of the kinds of constraints that organizations have to work with, and why they may make decisions that you don’t understand from the outside.
Let’s say that as a state or local government entity, you have to put together and launch a website on short notice. Something has come up, and citizens need to be able to sign up for an important and potentially life-saving … resource. Service. I’m being vague here.
Setting Up an Instant Registration Database
You don’t know who’s going to sign up and register, and you don’t have time to integrate it with any databases you have with citizen data in order to uniquely identify and authenticate them. Besides, if you don’t need to verify their identities in order to get them this resource, you shouldn’t try to get fancy, because uniquely identifying citizens of all ages is harder than it sounds, and you’re in a hurry. All you know, and can maybe ask for, is one piece of data that won’t cost your citizen anything extra, can be used to contact them, and is hopefully used only by them. Yep, we’re asking for an email address.
So, quick and cheap: we ask for an email address and full name, and we register that citizen, using the email address as the user name. That’s a very standard procedure; we’re not going to assign the citizen a different login name, because generating millions of unique login names and building a logic flow to email their forgotten username to their email address is too onerous for the layer of supposed protection it gives. (Ask me how I know this.)
Setting Up an Instant Unique Login
Then we want to set a password for that registered citizen account, because in order to deliver the service, we are asking for some personally identifiable information (PII) that we now need to protect as best we can. We can’t force the citizen to choose a “good” password, because again, once you go down the rabbit hole of enforcing password quality, you’re going to introduce more friction in front of a potentially life-saving resource, and you’ll have annoyed citizens calling a help desk that does not scale to a sudden flood of ALL your citizens.
So we do the next best thing: we email the address of record after the account is created, and give them the necessary information to come back and set their own password. This does a bit of authentication by proving possession of the email address that was registered. (Yes, we know they’re probably going to reuse the password they remember best. It’s a natural law at this point.)
I hear you asking: what about multi-factor authentication (MFA)? Shouldn’t we be setting that up if there’s citizen PII being protected? We can’t, because we can’t assume that every citizen has their own phone (for SMS messages or an app), and we certainly don’t have the time or budget to mail out a token, a smart card, or even a PIN on a piece of paper.
Think of adults who are trying to register their parents in nursing homes; think of parents trying to register their children.
You can imagine that one person — the only one in a family comfortable with technology — might be sitting there registering all their family members one by one, directing them all back to the same email address. This isn’t good if you’re trying to index these registrants by email address, but if I were the “designated registrar” in the family, that’s totally how I would do it. If I have to come up with a throwaway email account for my five-year-old, I’m going to be annoyed.
So, yikes! Can we do anything else to protect the citizen from having their access to this resource stolen through account takeover attacks? Email addresses are easy to find and guess and brute force; we know the passwords they choose aren’t going to be that great. Anything?
The Problems With Email as a Unique Identifier
Well, let’s try obfuscating the email address a little bit by adding some characters to the end of the login name. Not randomly; we’ll add the same characters to all of them so that we know to snip them off when we’re actually sending an email to that address.
I did start to scream a little inside my own head when I saw this technique being used. It requires the citizen to pay close attention to the email confirming their registration, because otherwise they’ll be assuming their login name is exactly the same as their email address. They’re going to have trouble logging in, assume it’s that the password is wrong, and they’ll end up calling that poor beleaguered help desk.
And the obfuscation is only going to work for as long as it takes an attacker to register themselves at this site, see how the login name is transformed, and then go back to brute-forcing. On the other hand, if the user does call in for support and does know the full login name, the extra characters might be used to tell the help desk which application they’re trying to log into. If you squint, you can almost see the logic behind that.
I squinted. And then I thought: well, how would I have done this myself? How do you protect citizen data in an ad-hoc registration system, and protect against account takeover attacks, without having any ability to use MFA or strengthen any of the other authentication factors?
Without spending extra budget that was never planned for this, and without blocking swift access to potentially life-saving services? How do you reach the maximum number of people, who have varying levels of poverty, Internet access, and technical knowledge, and stand up this service by next week?
Sometimes “Good Enough” Wins
Sometimes “good enough” is the best that you can do in a pinch. I can well imagine the design discussions that went on in a hurry -- over phone lines or video calls or text messages -- to model threats, mitigate risks, and simplify the user experience while saving taxpayer money and working to an impossibly short deadline. There were probably other constraints that I don’t know about and never will (“the only server we have available for this is running Windows 2000”). We live on to fight the good fight another day.
I’ll just raise a glass to the team that managed to get it operating. You should too.
Try Duo For Free
With our free 30-day trial and see how easy it is to get started with Duo and secure your workforce, from anywhere and on any device.