There is a temptation in computer security circles to aim for the perfect. After all, we know that if there is a hole then it will be found and will be exploited. So we tend to build (hopefully! ahem OpenSSL) secure products that will withstand attacks… and then fail at usability
Let’s take a brief travel through…
Unix naming services
NIS
In the long distant past (the 1980s), Sun Microsystems created a system called NIS (Network Information Services)1. This was a massive step forward for large computer networks; it allowed a central password “map” rather than needing to distribute it to every computer; it provided a central control point (change one file and every client machine picks it up). Today this is expected, but in the 80s it was new and clever.
As time went on, though, we realised things weren’t as nice as we’d like.
People like Alex Muffett created
fast crack
routines. NIS exposed the raw crypt strings and so people could take
them and off-line attack and steal passwords. You didn’t even need to
have a login to steal this information; just access to the network.
Further, NIS was inherently based on network trust; someone on your network could fake a NIS server and convince your machine to talk to them; now they can login to your machine and become root. There were some small attempts to increase NIS security but, really, it was a security nightmare.
NIS+
So Sun next created NIS+. This solved many of the problems with NIS;
servers had keys so the communication could be trusted; data could be
protected (no more crypt string exposure); it even allowed for hierarchies
of servers, so tree based definitions could be created (eg at the top level
we could have SA accounts valid everywhere; the chemistry department could
run their own account system and only chemistry servers would know about
those accounts).
Nice! Well, not so much.
The problem with NIS+ was that the management of it was horrendous. For a headache, look at the procedure to change the root server’s IP address. There are 9 primary steps, each with multiple sub-steps, including a “wait 12 hours” period. WTF?
Running NIS+ at scale was just too complicated for many organisations. They stuck with NIS. The insecure, broken solution. Because it worked for them.
NIS+ was so bad that by the time Solaris 9 came out, mention of it had been dropped from the official Sun training courses. NIS was still mentioned; LDAP was the primary focus. But NIS+ had been dropped totally.
Compare to Microsoft NT Domains
If you look at the old NT domain model you’ll see a lot of similarities between this and the NIS+ model. After all, they’re trying to solve similar problems. The difference, though, is in usability. Let’s take the ‘change primary server IP address’ problem, from before. With NT this is pretty simple; any replica can be promoted to become a primary. NT cheats; every domain server (primary or replica) shares the same identity, so it’s easy to move the primary around.
NT has its own problems (mostly due to backward compatability - LANMAN hashes!) but it was massively easier to manage.
NIS+ lack of “ease of use” lead to failure for adoption. NT pretty GUIs made it easy to use.2
Today’s fight
The fight, as I type, is the same as last week; WhatsApp.
To summarise, the Grauniad wrote an article about how WhatsApp had a security backdoor. The security world went mad, with claims, counter-claims, rhetoric, demands to opensource the software, or use the Signal software.
Why is this important? Well, WhatsApp is meant to provide E2E (End To End) encryption of messages. Only the sending and receiving devices get to see the plain text. If someone manages to attack anywhere in the path (eg the central server) then they still can’t read the messages. So, clearly, a backdoor that breaks E2E is important.
The reality is that the backdoor isn’t anything of the sort; it’s a usability trade-off. Under specific circumstances (essentially; the receiver gets a new phone and generates a new key) the sender will automatically re-encrypt the message and send it. An alert is provided to the user. With Signal the user is prompted about the change and given the option to re-encrypt.
What is the risk? Only unsent messages are retransmitted. And there’s limited attack points; primarily the central servers and the recipients mobile network (de-register the legitimate device, register your own device, receive messages!). The latter is a potentially legitimate attack vector in some countries, with tight crack-downs on dissent.
The “perfect security” team claim the Signal approach is better, but don’t take into account user experience (“resend? Sure, I know Fred gets a new burner phone every week to avoid security forces”). The WhatsApp team believe that the vaste majority (99%) of rekeys will be due to standard “new phone” purchases.
So here we have a usability vs perfect security trade off.
Conclusion
“100% secure or go home” is a very binary view of the world. Now for a megabank or a government (or a target of a major government) then such a posture might be true. After all, who knows what compute resources the NSA can bring to bear on you :-)
But, really, most people don’t need perfect security; they just need “good enough” security. If you’re in a risky situation then this XKCD is your bigger risk than an attack against a theoretical weakness.
Both are a gazillion times better than SMS, which is what happened before!
As my girlfriend frequently reminds me, don’t let the perfect be the enemy of the good
- Originally “Yellow Pages” until British Telecom sued for trademark infringement; this is why the commands still begin
yp- e.g.ypcat[return] - Yes yes, there are other reasons why NT beat NIS+; desktop integration being a major one. But it was massively easier to manage an NT domain than a NIS+ one. [return]