2FA FTW

This morning brought yet another story of identity theft (ID Theft in three steps: 'Adequate' Telstra and telco identity checks questioned) by the all-too-easy technique of finding an individual's name, home address and date of birth. These are all things that are on the public record and quite easy to discover; they should not be used as an authenticator. The US has a related problem with Social Security numbers which should also be regarded as an identifier, not an authenticator.

One of the most important steps in identity theft is getting access to the victim's email account. This is because the attacker does not know the password for the victim's bank, PayPal, eBay or other accounts, but the most common technique for password reset is to email a link to the user. In other words, the email account is used as yet another authenticator in a chain of trust. This means that email account mismanagement poses an extreme risk for user - it is both highly likely to be targeted, and also leads to severe consequences if compromised.

The weak link in all of this is the use of passwords; human beings being human and of bounded rationality, we tend to choose bad passwords that are easily guessable or discoverable. Even worse, we reuse passwords - confronted with the need to memorise the passwords for 20 or 30 different accounts, we understandably fail. Not everybody knows about password safes, for example. Inevitably, however, one of the sites we use gets compromised, the password hashes are stolen and posted on pastebin, and within minutes, a Rainbow Tables attack (or even quite mundane dictionary attack) reveals that favourite password, along with the email address, to the Bad Guy. And if the same password was used for the email account, it's Game Over.

I long ago determined that my email account had to use a unique and painfully complex passphrase, since the security of so many other assets depended upon it. It might be a pain in the ass to pause for a while as I hunt and peck my way through a long near-random string, but it's the price I pay for peace of mind.

And a few years ago, I decided that it was time to move to two-factor authentication for my email account. I'd had enough of running my own email servers and moved my email, etc. to Google Apps for Work, and Google was starting to offer two-factor authentication. I'm not a starry-eyed believer in 2FA - in many cases, there are better alternatives and a more sophisticated risk-based approach to the problem should reveal them - but to rely purely on passwords for such an important application is inviting disaster.

Enabling two-factor authentication is a fairly straightforward process, and Google nicely provides several alternative approaches. The most obvious is to rely on a mobile phone number and send an SMS (or voice message) to it - what banking systems call a mobile Transaction Authentication Number (mTAN). But that won't always work for me - some places I work are screened so that a mobile phone signal can't reach them. Once nice alternative is a Security Key - a small device that plugs into a USB port and provides cryptographic authentication; this will work with any software that supports the FIDO (Fast Identity Online) U2F (Universal 2nd Factor) specification, such as Chrome (but not Firefox, unfortunately). And there's the Google Authenticator, a smartphone and tablet app (technically, a soft token) which generates a unique six-digit number each minute. Any of these can be combined with the passphrase to allow a successful login.

A Yubikey Neo - a "security key" which also supports NFC (near-field communications)

This will overcome what I suspect is the biggest obstacle for many people contemplating the switch to two-factor authentication for Gmail, etc. - the fear that they will be locked out of their account if they lose their phone or another device or simply don't have it to hand. With a little extra setup, there's always an alternative available.

Setting up two-factor authentication is done by going to https://myaccount.google.com/security/signinoptions/two-step-verification or just clicking on your avatar at top right of a Gmail or other Google page, then choosing "My Account", then under "Sign-in & security", selecting "Signing in to Google" and on that page, under "Password & sign-in method" clicking on "2-step Verification". Unsurprisingly, you'll be prompted for your login ID and password before getting access to this page.

Turning on 2-step verification will start by sending a verification code to your recovery phone number. If you receive this successfully then 2-step verification will be turned on. At this point, any other sessions and devices you may have logged in to this Google account will be effectively logged out, and you will need to log in again, using 2-step verification. However, you may want to delay that until you have set up your security key or authenticator app.

Security keys, such as the Yubikey, are inexpensive and widely available - I got mine from Amazon. Adding the security key to a Google account is very easy - on the 2-step Verification page, just click on "ADD SECURITY KEY"and you will prompted to insert your key and tap on its button if required. A second or two later, it will have been recognised and added to your account.

Setting up Google Authenticator is almost as easy. The 2-step Verification page prompts you to install the app (versions are available for both iPhone and Android) and then tap "Set up account". This will allow you to scan a QR code which presumably seeds the pseudo-random number generator in the Authenticator app. And that's it - from this time on, opening the Authenticator app displays a six-digit number, changing every minute, which you can use to authenticate to Google.

Google Authenticator

Google selects the second factor in a priority order - first (default) choice for me is the security key, then comes the Google Authenticator app, and only if those aren't available does it fall back on SMS authentication codes.

Logging In

As mentioned above, setting up 2-step verification effectively logs you out on other devices and sessions, so you'll need to log in again. Your phone may pop up a dialog requesting an authentication code, especially if you have the Google Device Policy app installed for remote management. In my case, I tapped the button requesting Google to send an authentication code, and a second later the SMS arrived - but after I'd viewed the SMS and written down the code, I couldn't get back to the authorization dialog. Since the phone is still logged in and hasn't skipped a beat, I can only presume that the Device Policy app was able to directly read the SMS and didn't need me to manually enter the code.

When I booted my Chromebook and logged in, it initially accepted just the password but then gave me a notification message that said I should log out and in again. This time, it prompted me to insert my security key and tap its button, after which I was logged in.

Chrome on Windows can be a bit confusing, because it requires a log in to the browser itself, independently of any web sites you may log in to (this is because Chrome syncs your bookmarks and other data to your Google account). So you may get a couple of prompts to authenticate when you first launch Chrome and log in to a Google page such as Gmail.

Firefox does not yet support security keys - there's a Bugzilla page where you can track development progress at https://bugzilla.mozilla.org/show_bug.cgi?id=1065729. However, you can use Google Authenticator to log in to Google, as shown:

Thunderbird shares code with Firefox and also does not support security keys. In fact, if you've been relying on "Normal password" authentication for IMAP access to your Gmail account, it's now time to change. Right-click on your account in Thunderbird and choose "Settings", then click on "Server Settings" and change the "Authentication method" to OAuth2. Click on "OK", and then click on "Get messages" to force authentication. You'll get a password prompt and then a dialog like the one above, allowing you to authenticate using Google Authenticator or an SMS code. Once that's done, Thunderbird will be happy for the foreseeable future. If you're using the Provider for Google Calendar plugin, that should also prompt for re-authentication.

Third-party Sites

One of the beauties of adopting this technology is that it can eliminate the need for passwords for other web sites and applications. The OAuth2 protocol referred to above allows Google to function as an identity provider for other relying web sites - part of an underlying technology called federated identity management. I use this as part of my own systems - for example, I no longer use a password when logging in to my own web site, but instead have configured the content management system (in this case, Moodle) to use OAuth2 to get Google to confirm my identity. Not only can the site be more confident this really is me - I've used two-factor authentication to prove it - but I don't have to type in a password.

My own web site now supports login with Google credentials

Many other sites also use two-factor authentication or federated identity management; for example DropBox now supports security keys, as does Github, Salesforce and many other sites. You can set up Facebook to use Google Authenticator by going to your settings, then choosing "Security", then clicking on "Code Generator" and clicking on "Set up another way to get security codes" and scanning the resultant QR code. The Facebook app on your phone can also be used as a generator.

You can log in to The Guardian, O'Reilly Media and many other sites using federated identity management with Google, Facebook, LinkedIn or Twitter acting as identity providers. Of course, social media networks are keen to have you use them as identity providers since then they can track you across other sites, although they have other ways of doing that anyway. However, as a Google Apps user I am a Google customer, rather than a consumer of free services, so I prefer to use only my Google ID for authentication.

Summary

Email accounts are too valuable to protect with only a password, especially a weak or reused password. Two-factor authentication providers better security and lowers the risk of identity theft. It takes only a few minutes to set up and rarely inconvenient thereafter. Use it.

Modeling Attacks in Prolog

I've been tinkering this week with the use of first-order logic as a way of modeling network attacks. It turns out not to be too difficult at all, if you know a language like Prolog. In my case, it's been over 20 years since I'd programmed in that language - and I hadn't done anything serious in it back then anyway - so I had to pull out the textbooks and start banging the axons and dendrites together. It turns out that two of my old Prolog books relate to LPA MicroProlog (which I used to run on CP/M!) and the third is the second edition of Clocksin & Mellish from 1984. I discovered that the language has changed a bit since then. I also found a copy of Borland Turbo Prolog, but since I don't have a 5 1/4" drive in a machine, I'm not even going to bother.

So I downloaded SWI-Prolog (http://www.swi-prolog.com) and installed it on both Linux and Windows systems. A few experiments and a couple of days of head-scratching later (most of it down to using a hyphen in a term in one place, and an underscore in another - doh!) I'm making some progress. Here's a simple example:

We define information assets as being managed by program/products which have vulnerabilities. An attacker can use an exploit against these vulnerabilities. Controls (patches, firewalls, IPS, etc.) remove or defend against the vulnerabilities and protect the programs. Now it becomes quite easy to state some facts and rules:

%% Facts
%% A more sophisticated approach would build these from CVE

%% Example: X11.org X font server has three vulns
%% has_vulnerability(Program, Vuln)
has_vulnerability(xfs,cve-2007-2103).
has_vulnerability(xfs,cve-2007-4568).
has_vulnerability(xfs,cve-2007-4990).

%% Postulate some exploits for these vulns
%% exploits(Vuln,Exploit)
exploits(cve-2007-2103, attack-tool-1).
exploits(cve-2007-4568, attack-tool-2).
exploits(cve-2007-4990, attack-tool-3).
exploits(cve-1000-0001, attack-tool-4).

%% Some controls, safeguards, (patches?)
%% removes_vulnerability(Control, Vuln)
removes_vulnerability(patch-xfs-1, cve-2007-2103).
removes_vulnerability(patch-xfs-2, cve-2007-4568).

%% Programs are protected by controls or patches
%% protects(Control, Program)
protects(patch-xfs-1, xfs).

%% Assets are managed by programs
%% manages(Program, Asset)
manages(xfs,fonts).

%% Some rules
%% An asset A is vulnerable to an exploit E if
%% the asset is managed by a product X which has vulnerability Y
%% and exploit E exploits vulnerability Y
%% and the program is protected by control C which remove vulnerability Y

vulnerable(Asset,Exploit) :-
manages(Program,Asset),
exploits(Vuln,Exploit),
has_vulnerability(Program,Vuln),
protects(Control, Program),
not(removes_vulnerability(Control, Vuln)).

Loading this into SWI-Prolog, one can now ask some questions, like:

22 ?- [approach4].
% approach4 compiled 0.00 sec, 0 bytes

Yes
23 ?- vulnerable(fonts,X).

X = attack-tool-2 ;

X = attack-tool-3 ;

No

This indicates that the fonts (a slightly silly asset, but I just happened to pick three vulnerabilities in xfs) are vulnerable to attack-tool-2 and attack-tool-3. Attack-tool-1 cannot exploit cve-2007-2103 because there's a (hypothetical) patch for it.

This approach needs to be extended quite a lot to be useful. The two obvious first extensions are a) an automatic loading of program/product vulnerabilities and exploits, perhaps from CVE and b) a model of the system under examination, perhaps as a graph relating assets, program/products and the controls which defend them. It would then be possible to have the system identify which controls are redundant or which patches need to be applied.

Another extension relates to the fact that some controls are themselves programs/products which may have their own vulnerabilities. An attack could therefore consist of a sequence of exploits which defeat or disable multiple levels of controls.

I guess now it's time to hit the books and coax SWI-Prolog into reading CVE from the XML, as well as representing the system as a graph.

Big Babies

Perhaps not required reading, but certainly an interesting little volume for security practitioners: "Big Babies, or: Why can't we just grow up?", by Michael Bywater (Granta, 2006).

Bywater, now a Cambridge academic, first grabbed my attention through his acerbic "Bargepole" column in Punch magazine, back in the 90's. His latest epistle advances the notion that politicians, media and Big Business all conspire to keep us in a state of infantilism; we Want It Now, we want what celebrities have, we want to be like celebrities, hell, we want to be celebrities. Our culture, the Mummyverse, requires not much more of us than to be silent, consume and die, and is happy to invoke various bogeymen - mostly recently, the spectre of The Terrorist - in order to get us to Shut Up And Do What We Are Told.

Bywater touches on subjects of interest to infosec professionals: privacy, the "new religion" of risk assessment, transport security, advertising copy for software. He reaches a climax with a list of 50 ways Not To Be a Big Baby, many of which have long been among my own favourite rants (and to which I will probably return, in due course), such as:

"27. Cultivate commensality. The art of dining together is one of the great cornerstones of civilization.

"28. Never do business with a company offering 'solutions'. It is a pernicious weasel-word, not just because it is pompous and self-aggrandizing . . . but also because it is telling us that we have a problem. That, since we are grown-ups, is for us to decide.

"30. Demand - and display - good manners."

The book is an over-the-top polemic, of course, but that's its best feature. But as you chortle, it is hard not to realise Bywater is providing an insight into your own uneasy feelings about the changes in our culture. A hefty six-page bibliography confirms that this is not just a stream-of-consciousness rant but the product of some serious research and thinking.

Still, it's funny as hell, and enormously satisfying.

On Naked Emperors

A spat has blown up on the Linux Kernel Mailing List over the merging of SMACK and/or AppArmor into the kernel, vs SELinux's use of Pluggable Security Modules. The NSA's Stephen Smalley asked Linus Torvalds:

You argued against pluggable schedulers, right?
Why is security different?

which prompted this reply from Linus:

Schedulers can be objectively tested. There's
this thing called "performance", that can
generally be quantified on a load basis.

Yes, you can have crazy ideas in both schedulers
and security. Yes, you can simplify both for a
particular load. Yes, you can make mistakes in
both. But the *discussion* on security seems to
never get down to real numbers.

So the difference between them is simple: one
is "hard science". The other one is "people
wanking around with their opinions".

(For the whole exchange, see http://kerneltrap.org/Linux/Pluggable_Security).

Once again, information security proponents get blasted for being unable to objectively back up their cases. We have got to get away from basing so much of what we do on opinion; so often, when called on this, we end up looking like an emperor who just lost his clothes. And it's happening more and more often.