OpenConnect

The organization I work for uses a Cisco ASA VPN network appliance for managing
remote VPN access to the internal network. This is a common and popular choice
for many organizations. When you access it remotely for the first time, it
wants to detect your platform and then download and install the AnyConnect
Secure Mobility Client. This client application is how you then connect and
authenticate your VPN connection. Our organization assumes that everyone in
the world uses Microsoft Windows all the time. Of course, why not?
Anyway, the Java-based client and installer do not work too well on Linux
for some reason. And our organization in particular is not too keen on helping
anyone who is not using Windows. They do not prohibit the use of Linux or other
operating systems, but they will not help you with them either.

So a couple years ago, whatever black magic they had been performing to make
Linux clients work stopped. Our team uses Linux and we were suddenly locked out
of VPN access. And they did not care despite out best pleading. In fact, their
final, formal answer on the matter was to "just use Windows". Nice. Thanks.

So we started digging around the interwebs and found that a lot of other Linux
users had the same story in regards to the Cisco AnyConnect client. And some of
them had gotten fed up enough to devise their own solution. We discovered a
project called 'openconnect'. This is an open-source program that is compatible
with the Cisco VPN appliance.

OpenConnect is not part of most Linux distros including RHEL, but you can now
get an rpm from EPEL. You can also build it from source if you desire.

OpenConnect uses OpenSSL which must be able to validate the signing chains on al
l the certificates involved. Our organization uses smart cards with security
certificates, so a VPN connection involves you presenting a client-side SSL
certificate. This means you need to have all the signing certificates up to the
root installed in your local store.

These go under the /etc/pki/ca-trust/source/anchors directory.
You simply copy the .cer certificate files there and then update using the
'update-ca-trust' command.

Then the command line to use openconnect looks like this.
You will need root privilege.

   sudo openconnect -c 'pkcs11:token=LAST.FIRST.MIDDLE.number;id=%02' https://vpn.foo.org

It prompts for the sudo password and then for the PIN on the smart card and
then it connects.

One tricky point is the 'pkcs11' parameter. You need to see exactly what your
token name and id number on the card are so you can reference them to the
openconnect command parameters.

With your card inserted, you can use 'p11tool' to get a list of all the
specific certificates on the card and their 'id' values.

   p11tool --list-tokens

   p11tool --list-all-certs pkcs11:token=LAST.FIRST.M.123456789

It should list some number of "objects", which are the certificates on your
card. If you don't know which one of these the VPN is expecting for
authentication, you can always use some trial-and-error experimenting.
There are not so many on there that this is prohibitive.

Now look at the 'ID' field for that object, e.g. "00:02".
You need to replace the "00:02" with "%02" in the 'id' portion of the pkcs11
string.

If you get the 'id=' syntax wrong, you will get some non-obvious errors from
openconnect and then a WebVPN cookie error and no connection.

We also ran into difficulty with some applications communicating over the VPN.
The problem is that the VPN tunnel uses DTLS over UDP. This requires a little
overhead for some protocol headers and starts eating up your MTU.
Your application has no idea it's using a somewhat limited connection and does
not account for this. So if its protocol also has some headers, you may have to
tweak the MTU down to account for that.

You can tweak the MTU on the tun0 device established by openconnect.

   sudo ip link set mtu 1402 dev tun0

An example is newer versions of OpenSSH whose key exchange algorithms have
rather large payloads. When these get fragmented over the DTLS/UDP connection
while communicating with an older version of OpenSSH on the server side,
something goes wrong, the key exchange stalls, times out and then fails.
You can edit the SSH config to not offer so many choices in the key exchange,
but it is simpler to bump the MTU down until it's happy. This is easily done by iterative experiments until it works.

Other authentication factors

In computer security, when we talk about authentication factors it is usually
the traditional "something you know", "something you have" and "something you
are" (i.e biometrics). There are other things being used as types of factors
more recently.

First up are behavioral factors, which are they way you do something.
This must be something that can be reasonably uniquely attributed to you and
only you. Some examples are your keyboard typing patterns, touch surface swiping
patterns, maybe how you typically interact with some graphical user interface.
The point is that, in theory, no two people use these interfaces exactly the
same way and that means the uniqueness can be used as a form of authentication.

Some systems are even using this as a means of "continuous authentication".
After your initial access to the system, the behavior is tracked throughout
use and if it suddenly doesn't look like you any more, then you could be asked
to reauthenticate. I have to wonder how robust this really is. Unlike a
cryptographically strong hash, we don't have any way to prove anything about it.
I think it's just too new for that yet. But I do agree that it is a promising
approach. The overly paranoid might not like it. It could be seen as yet another
intrusion into their privacy and another way they could be tracked or
identified. The EFF has a project that demonstrates just how unique a
fingerprint your web browser presents regardless of which site or page you are
visiting. If multiple sites started sharing and correlating behavioral
measurements, that is one more way you can be tracked across multiple systems
to build a bigger profile of you.

Another factor is location. This could be a geographical location or a logical
network location (i.e. only from certain IP addresses or networks). These days,
a lot of computers either have GPS or an estimate of position based on knowing
where your general area your IP address is in. I play Blizzard games through
their Battle.net site and if they see me come in from a different IP address
than I usually do (maybe I'm visiting relatives and using their computer),
it will challenge me for extra authentication to make sure someone else has not
hacked my account. Of course, it is possible to spoof these mechanisms if you
can hack your local device to report the expected location or spoof the IP
address.

A slight variation on this is the "remember this device" mechanism.
You go through a full authentication once and then tell the site that this
device is a trusted device. Future logins do not ask for all the authentication
factors. This is a convenience for your home computer, tablet, phone, etc.
You assume the risk by protecting access to your devices in trade for more
convenient access. Once again we see the balance between usability and security.
I have had difficulty with this mechanism over time. The "remembering" tends
to fail under various circumstances like software upgrades, maybe an eventual
timeout and so on. This tends to happen with no notice and after you got used
to the convenience it is a jarring pothole in the usability road.

Multi-factor Identification

In the security realm, we talk a lot about multi-factor authentication, but you
can also use multiple factors for identification. Why would we care about that?
If a guy shows up and claims to be "Joe", we take his word for it as long as he
can successfully authenticate using Joe's password, token, biometric, etc.
In other words anyone possessing matching authentication factors is assumed to
be Joe. But maybe he stole Joe's factors? Even some biometrics have been stolen
in both fiction and the real world. Remember Wesley Snipes stealing a guy's
eyeball in the movie Demolition Man? He holds it up to the iris scanner on a
ball-point pen. Nice. And a couple years back, I recall an article about some
thieves cutting off a guy's finger to steal his car whose locks and/or ignition
were biometric fingerprint scanners. So much for convenience. A key can be
replaced. Just saying.

In some applications, we only care about proper authentication and just take the
identification for granted. This is the case when logging into any computer
system, web site, and so forth. But in other cases, it may be really important
to correctly identify someone. In fact, there may not even be any authentication
involved if it's not a security situation. A family member was recently
hospitalized and during the admission process we discovered the hospital had
recently upgraded their check in process with a palm vein scanner. My first
instinct was to figure it had to do with authorizing access to health records.
No, it was to be used in any future admissions for positive and more accurate
patient identification. I thought why not use a fingerprint or something?

It turns out that the palm vein scanning is particularly useful in a medical
environment. The scanner works by using an infrared wavelength to record a
picture of the vein pattern in your palm. This pattern remains the same
throughout your life and can be read even through damaged skin (cut, burned, etc
). And a biometric works even if you are unconscious and there's no one else
present who knows you. So unless your entire hand is damaged, it makes a really
good choice. This particular scanner worked only on the right hand. I asked the
admissions person what about people who were missing their right hand? She sort
of stumbled on that and said they would "figure something out". :)

From a security perspective, it is highly unlikely that someone would want to
obtain a false admission to the hospital. Do you know why Joe was supposed to
be checking in? Maybe you're about to have your heart replaced. Yeah, I don't
see anyone abusing this. And you really don't need multi-factor identification
in a computer application. It would really just end up serving as yet another
authentication factor. Suppose you had to present a user name and biometric first
and then give the authentication factors associated with that pair. How is that
any different from giving only a user name and then one more authentication
factor? It's not. So identification is about getting the correct record, not
about whether you should or shouldn't. In the hospital case, the admissions
person already has permission, so they don't need you to authenticate anything.

Digital Estates

I think most people are familiar with the notion of creating wills, powers of attorney, trusts and such to manage their physical and financial estate in the event of their incapacitation or demise. Written instructions carry legal weight for your survivors which minimizes uncertainty of ownership and helps keep the vultures from stealing your hard-earned loot from your family. In modern times, there is another factor to consider, your digital estate. What is that?

The days, we may have a large number of online accounts established for banking and other financial institutions, Facebook, Amazon and so forth where a wealth of information about us resides. Some of them may be access to large collections of digital media (books, movies, music, etc). If you cease to be, what happens to all that stuff? To some, it could be just as important as that baseball card collection. But unlike the baseball cards, it's not something you left in boxes at the house. Your successors will need access to all those online treasure troves.

So somehow, you need to leave them a list of accounts along with the usernames, passwords and any second authentication factors. The first, best step is to use a password manager as detailed in previous posts on this blog. This keeps the entire list in one place along with all the supporting information. Unlike the baseball cards, however, this presents some additional challenges.

First, consider that while you're still here, you will be updating this database periodically with new accounts, changed passwords and so forth. So you cannot just put a copy on a CD and put that in a safe or tell the relatives to hang on to it "just in case". It will go stale and some of it may become useless. So you need to document where the latest version should be along with the location of any backups of it. And it is not just the content of the database that may change. Good security practice is to change the master password occasionally. So you cannot just tell them where the file is and hand them a copy of the password even if it is encrypted or otherwise obfuscated.

Second, consider anything that uses two-factor authentication. What are the second factors? Yubikeys, perhaps authenticator apps on your cell phone, some other OTP token and so forth. You can document what to use in the database, but they have to lay hands on it. Where did it go? And if it cannot be found, is there an access recovery procedure that can be followed? Document it. Make sure all relevant information like security questions and answers are documented in the database too.

So the strategy I chose was to establish a second password database whose sole purpose was to hold the master password of the main database. The password for this database is extremely strong as a maximum length, randomly generated string. So I can change the master password of the primary database and just remember to update the secondary database. This secondary database password was printed as part of a letter stored with my estate attorney. If I did want to change this password, it just takes an update to the letter as well. This second database still requires the same second factor of the Yubikey. So I trust the lawyer to a point and if anything untoward happened, he would be the first suspect reported to the police. And he does not possess a copy of either database or the second factor. The family can get this key and with instructions start unraveling the puzzle to get full access to everything. In the event of loss of the Yubikey, there is a separate recovery passcode stored in a separate, secure location (i.e. not even with the lawyer), but documented for the family.

This may all seem a bit extreme or paranoid-ish, but I think it's a reasonable way to leave access without compromising my living, daily use.

Financial Aggregators and Security

A lot of us like to use software to manage our financial accounts, budgets and/or investments. It helps keep track of bills, loan, the current value of assets, spending vs income, your current net worth and so forth. This software comes in two basic forms. You either have a local software application or you use some manner of web-based service.

Long before the advent of the web, there were just standalone applications. Intuit's Quicken and Microsoft's Money were the big two with some other less capable things on the fringe. When common, public internet access came around in the early-to-mid 90s, these applications started adding "online access". In order to access your bank or other financial account, there had to be some kind of standardized protocol. So along comes the Open Financial Exchange (OFX) which was precisely that. These programs adopted it and now you could have them download your checking account transactions directly from the bank instead of you having to enter them all manually. Nice and convenient.

In order for this to work, your financial institution had to have already granted you online web access to your account which meant establishing a username and password. And in order for your application to do its thing, you had to enter them there so it could use them. That was no less secure than you typing them in your web browser. In this respect, you can think of the financial application as a very specialized "browser". In both cases, you are running the application on your local, (hopefully) personal computer. Assuming the program and the site use appropriate encryption protocols, you have not leaked your authentication credentials to anyone else.

Moving forward to more recent years, Microsoft finally gave up on Money and retired it. Intuit has put Quicken up for sale, but it still exists and is the only reasonably functional program left for managing investment accounts. All the other applications are just budget managers watching your checking account and credit cards. During the more recent web era, a variety of web sites have come about offering aggregation of your accounts for that big picture view just like the older applications did. Quicken spun off the Mint site, for example. For investors with enough accounts to need help but not enough wealth to have a personal CPA on staff, there are some options like Personal Capital.

All these sites work just like the older applications with one major difference. They store your information in  the cloud instead of on your local hard drive. So now you have an order of magnitude larger security risk. In order for these aggregator sites to do their thing, you have to give them your usernames and passwords to all your financial accounts. Yikes! Rather than you entering this information, you give it to them and they use it for you. It's sold as "convenient". But now you have to trust that they don't get hacked either internally from an insider threat or externally by some other bad actor. And a compromise would give the malefactor direct access to your finances. They could transfer money or sell your assets. And unlike simple credit card purchase fraud, no one is going to cover you for this oops. I'll bet if you find and read the EULA, they are not responsible if anything goes wrong.

Even if you assume this risk, there are some technical limitations. I once ran into a problem with Quicken and the OFX interface. You used the same username and password for both the web site login and the OFX, but they had different password policies and the OFX was significantly less robust, so you had to go with the lesser of the two and weaken your overall security. The problem seemed to me like some lazy programmer who didn't want to figure out how to escape all the possible special characters on the keyboard. You could only use a very small subset via OFX, but all of them on the web site.

Another limitation is two-factor authentication. First, a lot of the financial institution sites do not support it. At least not yet. For the ones that do, the applications and aggregation sites do not. If they did, that would still work out for a local application that could query your token or biometric somehow, but not the aggregator sites. And even if you could somehow give them a copy of your second factor, now they have that too which largely defeats the purpose, security-wise.

So while everyone is in a mad rush to webify and cloudify things, this is one area where a local application with local storage and local use of authentication still makes a lot of sense to me. Unfortunately, that's not where we're headed. I personally still limp along with Quicken as best I can but it's far from perfect any more. The last good version was in 1995. Maybe one day I'll get frustrated enough to add a huge module to Gnu Cash and build what I need.

Data Breaches and Credit Monitoring

Data breaches have become so frequent as to be commonplace. We almost expect
them to happen now. The typical response for saving corporate face is to issue
a somber apology and then offer a year of free credit monitoring.
"Sorry some hackers got your data because we suck, but in recompense, we'll pay
some third party to 'monitor' your credit for a while".
Well, gee whiz, that fixes the problem, doesn't it?

So there are two assumptions being made here. The first one is that the only
thing the thief will do with your information is try to establish a new line of
credit in your name. The second one is that if they have not exploited this
within one year, they probably are not going to.

The first assumption does not account for basic credit card purchase fraud,
which I have to believe is more probable than someone trying to buy a new
washing machine and dryer with it.

The second assumption seems somewhat reasonable. In this day and age, online
data can have a very short shelf life and would more likely be exploited sooner
than later.  Of course, it depends on what information was acquired.
Suppose it was Amazon.com. What are you out? Name, date of birth, address,
credit card data, and a lot of marketing data about your buying and browsing
habits. But what about something like the US government's OPM breach? Now you
are out pretty much everything including long-term data about past residences,
your finances, etc that could be exploited far later and have far greater
consequences. In that case, the bad actor is presumed to have been a foreign
government who would be looking for security holes like blackmail targets rather
than trying to buy clothes at the Gap for free with your credit card.
My point is that credit monitoring will do nothing against any of this. It only
works if the thief tries to get a new card in your name or buy something really
big with financing where they merchant will run a credit check on you.
And even then, you merely get notified after the fact. Hopefully you are paying
attention to their communication back to you but the initial damage is already
done and happening and now you have to try and clean it up.

A post by Brian Krebs explored this issue and offered some excellent advice.
He pointed out that monitoring is reactive, not proactive. You can voluntarily
freeze your credit reports (there are 4 different companies) and then everyone
including you, the thief and all merchants are denied access to check your
report. And that prevents any new illicit lines of credit from being established.
Something that would be really nice is if you could combine the freezing and
monitoring so that you get notified that someone tried to check it and was
denied due to the freeze. I don't think that happens because the freeze prevents
the check, so there's nothing to report so to speak.

Doing this does have some downsides. If you want to legitimately apply for new
credit, you will have to temporarily lift the freeze before the merchant makes
the check. That does not happen instantly and involves large PIN numbers you
are given when you place the freeze. Also, most merchants either do not know or
will not tell you which company they are going to use for the check.
Perhaps they will use more than one? So you have to unfreeze all four of them.
That's probably not a huge deal because how often does the average person apply
for new credit?  And you probably don't do that on a whim unless it's a
department store card offered at the time of checkout so you can save an extra
10% today just for signing up. So freezing your reports is a form of self-denial
of service. A loss of availability and a usability problem.

Another problem is something called "knowledge-based authentication". Sometime
when applying for something online, they want further assurance of your identity.
One relatively common technique is to probe your credit report and invent
questions about past residences or loans that, in theory, only you would know
the correct answer to. Which one of these addresses have you previously lived
at? Which company held the mortgage for your first home? The correct answer
pulled from your credit report is inserted along with three bogus answers for a
multiple choice quiz. Unfortunately, in order for them to generate the
questions, they have to access your credit report which is frozen so the whole
process fails.

One breach I was involved in tried to use this technique to verify my identity
before setting up the free credit monitoring. The freeze resulted in an
unexpected error code requiring me to call them for resolution. I ended up
opting out of the monitoring and half-jokingly told them that it did not matter
because I was already being monitored from about three other breaches and
another one was sure to come along before those expired.

The problem with this technique is that it relies on the flimsy assumption that
only I would know the correct answers. First, it's a 4-option multiple choice
quiz. Not that hard to guess correctly by sheer luck.
Second, that information could have been obtained via some other breach
(e.g. OPM, IRS, etc).  So this becomes a circular problem of trying to use the
stolen goods to protect the stolen goods from further stealing... hmmm.

Two-Factor Authentication with Yubikey

In a previous post, I talked about using password managers, both local files
and cloud-based applications. In both cases, they default to having a single,
master password. This is the one (and, theoretically, only) password you need
to memorize now because you cannot use the application to access itself.
This password carries more weight because it leads to all your other credentials.
So you want a strong and memorable password which is easy enough, but still only
a single factor, something you know. Can we strengthen the security of this
important and potentially weak link in the chain?

Of course we can. You can use a variety of mechanisms to introduce a second
factor. I chose to use a Yubikey NEO from Yubico. They Yubikey is a USB device
that interfaces as a keyboard and has a single touch button for activation.
You can read all about it for yourself, but the NEO supports two separate
security functions. Using its utility program, I configured the second slot
to use the HMAC-SHA1 challenge-response function.

For my main password database, there is a Keepass plugin called KeeChallenge.
It was designed specifically to work with the HMAC-SHA1 challenge-response in
the Yubikey.  By installing this, you can configure your database file to
require a second factor that uses the Yubikey to provide the challenge response.

You install the KeeChallenge plugin by simply copying all of its few files on
top of the Keepass installation. Then in Keepass, on the login dialog, you have
to select the second-factor combo box and choose the challenge-response.
It defaults to using the built-in "select a local file" option.

Quick side-bar. Using some arbitrary file (more likely it's hash) as part of a
composite password seems neat. As a hacker, what file was chosen? You have no
idea. So you would have to brute force it. But now you would have to drag around
both the database and the secret file. Then you'd have to store more stuff along
with both files as camouflage so someone guessing at the use of a secret file
has to try all of them. But that's not difficult if you have already hacked the
master password. Anyway...

For the online database using LastPass, you have to pay for their premium service
which is a very inexpensive $12 per year. This allows you to use a variety of
second factors including Yubikey support. It also lets you sync your database
across any number of devices.

Now both applications require both knowledge of the master password and the
physical presence of the Yubikey to access the database.

The NEO is a particularly good choice for smartphones because it also supports
NFC. There may be some kind of adapter dongle that you could plug into the
micro-USB port meant for the charger, but what a usability mess that would be.
Instead, you can just wave the Yubikey across the NFC sensor when the application
requests it.

On an Apple iPad, the LastPass application has support for the TouchID sensor.
In LastPass, you can choose to substitute that for the Yubikey as your second
factor. Technically that's a biometric using your fingerprint(s) which still
qualifies as a different type of factor than the password.