This blog post contains affiliate links. Click here to learn more.
In part 1 of this post we covered some basics of cryptography. This post is going to make many references to part 1, so if you haven’t read part 1, proceed at your own peril. We’re now going to build on the basics to understand how Personal Capital solves two of (many) security problems:
Problem 1: How do they ensure that you can securely log into your account?
Problem 2: You give them the keys to your kingdom. How do they store these keys securely and protect them from hacks?
Logging in Securely
When you create an account with Personal Capital, you choose a password and you will use that password every time you log in to view your accounts. The password is how Personal Capital knows that you are you, and decides to give you access. Every time you log in that password has to travel from your device to Personal Capital over an insecure channel with lots of snoopy snoopers looking on.
What does Personal Capital do? The smart thing. They establish a secure channel of communication and send your password on the secure channel. What makes a channel secure? You guessed it: encryption. Remember that quote from the Personal Capital security web page? “Our servers prefer TLS 1.2”. That is the protocol to establish and use a secure encrypted channel. So Personal Capital wants to encrypt your password and send it to their servers to compare with the password that they have previously stored for you. A most excellent idea. However, in order to do that, they need a secret key.
How are they to establish this secret key between your device and their servers without anyone else knowing what the key is? A bit of a chicken and egg problem here – they need to send your secret password to their servers without anyone seeing it, so they need to encrypt it. To encrypt it they need a secret key, but how do they establish that shared secret with your device without anyone else knowing?
Their solution is “We use ECDHE key exchange for Perfect Forward Secrecy”.
ECDHE stands for the Elliptic Curve Diffie-Hellman Ephemeral key exchange. Remember the hard math problems we talked about in part 1? Elliptic Curve Cryptography (ECC) is based on such a problem. Let’s start with an analogy to try and understand the wonderful world of elliptic curves.
You have an urn (what do you mean you don’t? Doesn’t everyone? So handy for wine swilling), and a marble. You throw the marble into the urn at an angle, so that it hits the wall of the urn, ping pongs around a bit, and eventually comes to rest on the bottom. A difficult problem
would be having to predict exactly where the marble would come to rest. Even if I told you exactly where and at what angle I threw the marble into the urn, and what its final resting place was, you would be hard pressed to come up with exactly what path it took and how many times it ping-ponged around before settling down. This is the essence of ECC.
If analogies don’t cut it for you (or you are just bitter because you are urn-less), read Nick Sullivan’s most excellent primer on ECC.
For those of you that did not click on that link (was that wise? You will now be subjected to my explanation instead of Sullivan’s excellent write up), here is what an elliptic curve looks like:
This odd looking curve has some very interesting properties. One of them is that a non-vertical line will intersect this curve in exactly three places. So, if you pick two points A and B on the curve, and draw a line to connect them, and extend the line in either direction, that line will only hit the curve in one more place. From that third location, C, if you drop a vertical line down, you’ll get point D on the curve. Getting from A -> D is the elliptic curve equivalent of one bounce of the marble in our urn analogy. So, in the most non-mathematical way possible,
A bounce B = D
If we now draw a line from D to A it would intersect the curve at exactly one point, E. Dropping down (well, up, strictly speaking) a line from E would give us F.
D bounce A = F
We could then continue with
F bounce D = H
H bounce F = J and so on and so forth.
When we were finally done bouncing, we would have a ‘final’ point on the curve (the resting place for our marble), say V.
How does all of this bouncing around help us to generate a shared secret for encryption?
Personal Capital and your Device will start with a publicly available ‘curve’, so the shape of the curve is known to both of you (and everyone else in the world). You also pick a well known ‘starting point’ on the curve (points A and B). Hackers, pens in hand, take note of these points.
Now Personal Capital picks a large random number, r1, and ‘bounces’ starting at (A, B) r1 times to reach some point on the curve, say T. Personal Capital sends T to Device. Obviously, anyone snooping can see T as well. Let them!
Similarly Device picks a large random number, r2, and bounces starting at (A, B) r2 times to reach a point U on the curve. Device sends U to Personal Capital. The snoopers see U as well.
Personal Capital now takes U and bounces it r1 times. Device takes T and bounces it r2 times. (And there we have two sentences I’d never have predicted I would write in a personal finance related blog post).
They both end up at point X on the curve. X is now the ‘shared secret’, the key that can be used to encrypt your Personal Capital password and send it across the wire. Even though the snoopers know the starting points and the shape of the curve, and carefully copied down the other publicly exchanged points T and U, thanks to the magic of the ‘bounce’ math nobody can figure out ‘r1’ and ‘r2’ (the equivalent of guessing the the number of bounces of the marble in the urn), and therefore nobody else can get at X.
I fucking love math. Even math I don’t fully understand. This is some seriously cool shit right here.
Personal Capital aren’t the only folks around to think that ECC is the bee’s knees. ECC is used to establish ownership of bitcoins, in Apple iMessage, and many other well known technologies. Chances are you are already relying on ECC for your security and just didn’t know it.
Wait, you say, that was pretty cool, but aren’t you forgetting something? The full quote off Personal Capital’s website was “ECDHE key exchange for Perfect Forward Secrecy”. What was that bit about Perfect Forward Secrecy?
I am glad you asked, young Padawan.
Let us imagine that instead of relying on ECDHE, Personal Capital sent a man to your home (said man will of course be dressed in a suit and be wearing shades). You and the man agree on a secret key X and then used that to encrypt all your communications to each other from that day forth. If X was ever stolen, all your communication from the first day you ever spoke a word to Personal Capital would become public knowledge.
But you and Personal Capital are too smart for that. You used ECDHE to establish X. And if that wasn’t magical enough, you will generate a new X every single time you talk (hence the last E in that acronym, ephemeral) using the method described above. Once you are done encrypting and decrypting that particular session, you can both just throw X away. X is never stored anywhere, and never reused. This is Perfect Forward Secrecy.
Securely Storing all your Passwords
We now turn our attention to problem no. 2: for Personal Capital to be an effective tool you have to entrust it with the keys to the kingdom. You have to give the access credentials to your various bank accounts and financial institutions to Personal Capital. In the previous section of this article we covered techniques that Personal Capital can use to safely encrypt and transmit those passwords when needed. But what about the rest of the time? How does Personal Capital safely store all your precious banking related passwords (and please God let the answer not be ‘recorded in a dusty ledger in the back room filing cabinet’)?
Once more, we refer back to the sound bytes on their website. “Data is encrypted with AES-256 with multi-layer key management, including rotating user-specific keys and salts.” Let us break that down.
What is AES-256?
From Wikipedia: The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001.
The NIST held a public competition to search for the algorithm that would become the next encryption gold standard. Fifteen competing designs by cryptographers and mathematicians worldwide were rigorously analyzed over a five year period and AES was the winner. The best part? None of this was behind close doors. The designs and algorithms were kept open to public (well, at least that tiny fraction of the public that did actually understand all that math) criticism and attack.
The 256 in the name is the length of the key in bits (i.e. ones and zeros). Other variants of the algorithm exist with different key lengths; Personal Capital is indicating that they use the the 256-bit variant, which also happens to be the longest (and therefore most secure) key.
If you want to delve into the math behind AES, you can’t do better than this fabulous cartoon series.
AES is what the US government uses to protect documents classified as Top Secret. How hard is it to break AES 256? Lenstra et. al computed how much energy is needed to break a cryptographic algorithm and then determine how much water one could bring to a boil using the same amount of energy. To quote from their paper “Boiling all water on the planet (including all starfish) amounts to about 224 lakes of Geneva and leads to global security: 114-bit symmetric cryptosystems, 228-bit cryptographic hashes, and 2380-bit RSA. This needs to be done 16 thousand times to break AES-128, SHA-256, or 3064-bit RSA.” It bears repeating. All the water on Earth 16 thousand times to break AES-128. And we’re talking about AES-256 here.
So Personal Capital uses AES to encrypt all your data and then stores this data encrypted on disk. This means that if someone gains access to those disks, they are going to be a sad panda because all that they will get their hands on a bunch of indecipherable, unbreakable ciphertext.
The alert reader (I hope that this is you. If it isn’t, go get some coffee, and then Go to Start. Go Directly to Start. Do Not Pass Go. Do Not Collect $200) will now ask “But what key do they use to encrypt all my data using the fabulous AES algorithm?”
They don’t say, but I can make an intelligent guess. The typical thing to do is to use a Hardware Security Module (HSM).
An HSM is a device that specializes in key generation and key management. Think of it as a Fort Knox for keys. The keys live in and are controlled by the HSM. They never leave the HSM and are therefore never visible to the outside world. The HSM is typically tamper-resistant. It may, e.g. automatically wipe all keys if it detects evidence of physical tampering.
This diagram shows how an HSM might be used for key management by Personal Capital.
Step 1: Personal Capital wants to log in to a bank on your behalf. They fetch your encrypted bank credentials from disk.
Step 2: They pass these credentials into the HSM. The HSM uses the key corresponding to this user and decrypts the credentials.
Step 3: The decrypted credentials are sent back to the Personal Capital server.
Step 4: Personal Capital uses TLS and ECDHE as described above to establish a secure channel and use that to send your credentials to the bank.
And what in the world are salts?
The tail end of the quote from the Personal Capital website was “…..including rotating user-specific keys and salts.”
To understand salts we first have to understand a little bit about a cryptographic technique called hashing. Think of hashing as one way encryption that doesn’t require a key. Hashes are designed to be one-way functions. So you can convert A to B by hashing but there is no way to get from B to A. Hashing is used as a secure way to store a password. Remember that password that you created to log in to Personal Capital? Well, Personal Capital has to store it somewhere in order to compare it with what you enter when you log in. They can’t store it in plain text because that would be insecure and irresponsible. They could encrypt it, but then they have to find a safe place to store that encryption key. Mo’ keys, mo’ problems. So, what can they do? They can hash your password and store the hashed password on disk. Now, when you log in, they can hash what you sent them and compare that with what they have stored to see if they have a match.
Hackers have, over the years, built up an arsenal of tools they can use when attacking a system. Imagine a system that was storing passwords, hashed of course. Hackers gain access to this system. We have already established that attempting to reverse the hashing algorithm to yield the password is probably going to result in much failure and sadness. However, social engineering (i.e. taking advantage of the weaknesses of being human) tends to be very successful. So what can an enterprising hacker do? Rely on the fact that most people use very insecure passwords.
Consider lovemydog123 as a password. The hashed version of this password is say $acc32pnga5x. Hackers could build a table that simply tells them that
$acc32pnga5x = lovemydog123
They could, and have, over time built up enormous tables with commonly used passwords and their hashed values. So to crack a password, they don’t try to break the algorithm, they simply look up their table and see if they can find a convenient match.
Enter salts. Salting is a way to slow down and thwart these sorts of hacks.
A salt is random sequence of characters appended to a password in order to turn your short, predictable password into a long, random password.
Going back to our example, instead of hashing lovemydog123, Personal Capital could add 67ab as a salt to your password that declares your undying devotion to your dog. They will hash lovemydog123 + 67ab and store that hashed value, say 9bcd1a7ngg4d. They can store 67ab in plain text next to the encrypted password, so that when you log in they can add this salt to the password you sent them and recompute the hash for a match.
This salting foils the kind of lookup attack described above because with the added salt, none of the passwords are ‘common’ any more. The hash 9bcd1a7ngg4d will not appear in hacker tables because it does not correspond to a ‘common’ password lovemydog123, it corresponds to the not so common password lovemydog12367ab. Now, in order to attack Personal Capital’s password hash table, hackers can’t use their convenient precomputed table. They will have to take each common password in their enormous table, attach the salt to it, recompute the hash and then do a hash comparison. This will significantly slow down the attack, and may even be enough to foil the attack.
Change your Passwords Sometimes
I want you to trust Personal Capital’s security, but not to the point that you get so comfy that you never ever change your password. Every time you use your password, whether it’s your Personal Capital password, or your bank password stored on their systems, there is always a chance that somehow a mistake is made and someone gets their hands on it. The good news is that the bad actor might not be able to use your password for a long time, either because they need to decrypt them, or maybe because they just don’t bother; they’re keeping a bunch of them for later. If you are lucky enough to change your password in that time window, the bad actor has nothing now.
Suppose some genius figures out a way to break TLS or ECDHE or AES-256 so that it only takes 15 years instead of an eternity to decrypt your password. If you change your passwords once a year, you won’t even be affected by one of a biggest breakthroughs in mathematics.
That’s why you should change your passwords periodically, and you should not reuse passwords. It protects you from all sorts of cases where someone does get your password, but can’t or won’t use it immediately.
(I see you. I see you dancing for joy because you finally, finally reached the end. Stop it. Stop it at once. I’m warning you, if you don’t stop I’ll launch into another three thousand words explaining Trust Models and Certificates).
The cryptographic methods used by Personal Capital and others like it are, based on our current understanding of number theory and the computational power available to us at this time, unbreakable. That is not to say that they are impossible to hack. How so? The weak links can and will be attacked. People are weak links everywhere. People are careless with their passwords and tend to choose bad passwords because they are easier to remember. People can be bribed and threatened. Implementations can be weak and flawed. In other words the math behind ECC is solid gold, but if the software developer responsible for converting that math into actual code isn’t particularly bright, or didn’t down enough coffee before a night of coding, there could be flaws in the implementation that allow the system to be hacked.
On the whole though, the beauty of the numbers holds me in thrall. In the balance of things, I choose to trust these systems and welcome the convenience this trust affords me.
“Nothing in life is to be feared, it is only to be understood. Now is the time to understand more, so that we may fear less.” – Marie Curie
When we understand something, we cease to fear it. I hope I’ve helped increase your understanding and put you on the path to using tools that will will help you to track and tame your finances. If you sign up for Personal Capital, I’ll make some money. At the very least you can probably thank me for curing that bout of insomnia that has been plaguing you for months.
Disclaimer time: I don’t work for Personal Capital. I have not audited their security systems. I have not shared a coffee and some gossip with their lead developer. All I have to go on their publicly available website containing some marketing quotes about their security and I’ve made a few (hopefully intelligent) guesses based on that about how they might be deploying well known cryptographic methods to protect our data.