Digital Society is Swiss Cheese

It's still too easy to be a bad guy. Digital Society is still conducting itself (itselves?) in a patchwork of half attempts at security woven in and around the occasional serious security system, and often right along side some woefully easy wide open doors.

This begins with a story. Recently I learned something so mind-bogglingly 18th century I had to laugh at the sheer absurdity of how, with all our advances in absorbing technology and all that it offers us, that we can't *just* do this one thing.

And that is: you cannot truly have a non-cheque bank account. 

Disclaimer, I'm sure there are institutions somewhere that are doing this at least sort of properly. But I came across a bank recently that confessed that there is actually no such thing as a no-cheque account. This means that your savings, digital, telephone, hybrid, any other bank account product name you can think of; every single one of them -- will accept a cheque drawn against it. Even if it is presented as a no-cheque style account, it will still process a cheque.

Listen: digBiz Podcast ep 13 | What is Truth? What is Fake? With guest Steve Prentice.

"What?! What the $%$# century is this?" I said to myself, and then out loud. To be fair I do find myself saying this several times a week about all sorts of things: business, communications, transportation, politics, laundry, basically about anything to do with humans, but I digress.

This cheque situation underscores a key problem. We have not done enough to remove 18th century thought process from our lives. With increasingly sophisticated and powerful computing, this is leaving a growing chasm for bad actors with half a brain and some tenacity to watch, learn, test, fail, then partially succeed with very little cost, and a difficult trail to find them with. A bank can't "turn off" its ability to choose how it accepts, processes, and restricts incoming cheques. An email service can't get customers to adopt two-factor authentication instead of using just a single password to login. A medical institution still verifies prescriptions via fax. For every legacy, ancient, thought process we apply to our digital lives and transactional interactions, we give the bad actors a gaping swiss cheese hole to drill away at until they come away with something valuable.

"What?! What the $%$# century is this?"

Our 18th century version of convenience is costing us. For every approximation of interaction with our fellow humans, we have jumped on the most convenient 21st century digitized version we could think of and pay for; or pretend we're not paying for (oh but we are).  While two factor authentication -- sometimes known as 2FA or MFA (multi-factor authentication) -- isn't perfect, it is an important step in identity validation and security. With 2FA live on forever? Of course not, there are already deeper and better models already coming, even so, while general adoption has grown to over 50% (which we were surprised at), that leaves 40+% as a tantalizing gaping hole of vulnerability for bad actors to jump on. It's a powerful economic motivator for bad guys.

 These two stories paint the picture we encounter every day. A corporate elephant that can't, won't, or can barely lumber awkwardly towards re-thinking their products, validation, and security models (the aforementioned bank still uses only SMS for 2FA, and even then, not available for login) outside of the 18th century context.

At the same time, with billions of people not driving their own security expectations down the throats of aforementioned companies, they will continue to slog it haphazardly at best, terribly at worst. With the best of intentions, organizations will iterate patchwork-style -- little by little, semi-success by semi-failure plugging the 18th century rowboat with little bits of chewing gum.

The Critique

Inconsistently applying enhanced validation is resulting in all manners of confusion, failures as a result of that confusion, and terrible customer experience. Once you get that, then you have customers balking at any methods or protocols you try to use, because they're basically no longer confident.  

Example 1, eggs in one basket implementation

1. financial institution uses 1FA only for primary login (user ID and password only with no additional security)
2. for some higher level transactions will them request 2FA
   1. but only using SMS short code which can be problematic with some telco providers, especially internationally
3. SMS is already a public-facing protocol, similar to email which is designed to receive messages from anywhere. The moment you use this model for validation, you instantly provide an open door for bad actors to exploit it.

This model already has built-in friction for adoption, failure, and fraud. At the very least, a pain.

Example 2, multiple protocols inconsistently applied 

1. Financial institution uses 2FA for primary login
   1. I​​​​​ncludes two 2FA technology methods; this does include SMS which we consider a bridge technology to help adoption, so for now, given that authenticator app is the second, we will give a provisional thumbs up
2. A customer chooses to use authenticator app for login; configured, and locked in with their account, great!
   1. Customer needs to perform a higher level task on their account requiring in-session extra validation to make sure they are the appropriate person to make higher level changes. Good, right?
   2. Wrong. Turns out for this, you cannot use your authenticator integrated ID for this; why? Nobody knows.
   3. For this purpose you need to fall back to SMS 2FA (which you have already chosen not to use) and have no choice. This brings up the SMS short code conundrum of built-in guaranteed failure for a portion of customers 
   4. Remember the "eggs in one basket" scenario from before? Welcome to chicken-or-the-egg land.

Am I being too hard on these companies? Maybe a little. But it really does feel like each little piece of an organization's ecosystem are evolving however each little piece's department or authority decides to work it.

Instead of determining the protocols that will be used to validate:

• default suggestion to 2FA primarily promoting using authenticator app
• default global business use of SMS standard phone numbers and not short codes, thereby making SMS as universal as possible
• all ecosystem applications must use the same authentication "stack" to ensure user experience is universal and easy to repeat

 The Iteration

Giving latitude, let's cut them some slack. Let's say these implementations take time to make work; it's true, they do. Even so, there are built in failure that suggest things aren't always truly iterating in the same direction.

• SMS 2FA works using universal 10-digits for login which works, but then changes to short codes for additional validation which then fails
• Authenticator 2FA is used properly for login, then is simply not used for additional validation and can only use SMS

Why We Need to Push: Security and Confidence

Our vendor-partners are evolving. They'd better be. It's all understandable. We still need to push for a more solid experience because our security is at stake. The more these experiences fall short, the fewer people will adopt them; it will just be too difficult and confusing for many, technically problematic or not possible for others.

There are already models using 2FA over QR code scanning, using biometric scanning. And my favourite flavour of the month: leveraging multiple devices with either mobile code scanning or biometric. These create closed-loop, well-understood, and private (meaning all protocols use non-public-facing interactions such as SMS) sessions that cannot be replicated or faked by simply sending an email, phone call, or SMS message.

This confidence is where we need to push next. Public-facing protocols are just encouraging bad actors to try and try and try to flood our lives with confusion decisions and wasted attention simply because we're inviting it.