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.

Password Managers

In recent years, online password managers have become a thing. Most of us
have so many online accounts for banking, shopping, and any number of other
types of sites. My personal account list numbers in the two hundred range.
A lot of those were maybe one time things so far, but the point is that I
had to register an account and establish a password. And if I need to use
it again later, would rather not have to go through the lost password
procedure every single time.

In a previous post, I detailed my use of a password managing application.
I use Keepass to maintain all of this information. This means I need to have
access to my database file and the Keepass application wherever I want to
use it. That's not so bad for my home PC which is only one computer and where
I do the vast majority of my online access requiring passwords. But what about
the occasional access from an iPad, a smartphone or someone else's computer like
when visiting relatives perhaps? Maybe you carry it around on a USB stick too?
Now you have a bit of a logistical nightmare to keep the file synced across the
various places. So you either spend time periodically copying the "master" file
to the other devices or find yet another service to automatically sync it for you.

You may consider using a cloud-based storage service to solve this, but that just
puts the file in your hands. You still need to install the application to access
it. And once you do get into the file, you have to copy/paste the passwords to
the web browser or other application. That's easy on a full PC with a keyboard
and mouse, but becomes a usability nightmare on touch-based devices like tablets
and phones.

So some folks have developed applications to specifically address this situation.
One of the most popular and the one I happened to choose is LastPass.
You still have to install the LastPass application on each device, but after that,
it's very simple. Your account and password information is stored in the cloud
and thus automatically synced. The application has explicit support for helping
you more easily copy your information and automatically fill in related information
particularly in web browsers which is the most frequent type of use. This is
especially useful on the touch devices.

So why would you not just automatically choose this? Security. Look at the track
record of so many major stores of online data (merchants, credit cards, the OPM)
and we see a trend of no confidence. So you have to trust that the password
managing application's site and storage do not get hacked. If they do, someone
could possibly get all your account names and passwords. That is far worse than
losing one site to a hack where all they have is what you stored there. They
now have *all* your sites with legitimate access. No further hacking required.

My personal choice is a hybrid strategy. I make a reasonable gamble by only use
LastPass for a small number of sites that I tend to want to access from the other
devices. The vast majority are only in the local Keepass file on my PC.

In a following post, I will talk about improving security by enabling two-factor
authentication on both of these applications using a Yubikey.