40

I've been worried about this password manager, PasswordBox that seems to be gathering quite a bit of steam lately.

They seem to have raised VC funding and are offering a free password management and storage tool. Their team does not seem to have extensive crypto experience.

What really worries me is that their Security page mentions:

All of your sensitive data is encrypted and decrypted on your computer by a master password > that only you know. This master password is NOT stored on our servers, so your secure data > can't be retrieved by anyone but you.

Meanwhile, their features page mentions that they can provide access to passwords to loved ones after a user dies (provided they have a death certificate). Detailed flow here

How can the key used to encrypt password data only be stored on the client and still allow a third party service the ability to decrypt the data in the event of a death. Why should anyone trust these guys?

CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
Mallory
  • 401
  • 4
  • 5

5 Answers5

22

Update:

PasswordBox responded to my inquiry on the subject. Personally, I couldn't really figure out what they're talking about. It could be a problem in my understanding. Below is a screenshot of their reply

enter image description here


This is a very interesting question. PasswordBox seem claim that they can never have access to your passwords. According to their FAQ page:

PasswordBox servers will NEVER see your decrypted data

PasswordBox never sees or stores your Master Password, so we can never gain access to your data

The only left possibility (that I can think of) is that half of the key might be stored in the client and other half is on their servers. So they truly cannot access your data, and when you request access to a loved one's account they have a way to send half of the key from their server to client (on the deceased person's computer or mobile) and thus the decrypted data is only on the client itself.

Please note that when I say "half of the key" it's because of my lack of knowledge in cryptography. There could be some way where two parties can share two parts of a key in a way that two parts are needed actually access the secret.

Update: Thanks to @DeerHunter's comment, it seems that there is indeed such a scheme, it's called Shamir's Secret Sharing Scheme. I've just downloaded the implementation and played with it a little. To me (again, very shallow cryptography knowledge) it seems like it could be a good candidate for the problem proposed in your question. You can try it for yourself.

SSSS-split(shares, threshold, secret)
SSSS-split(2, 2, "YOUR_KEY")

Shares = 2 (a piece for you, and a piece of the service)
Threshold = 2 (at least two of pieces are needed to recover the secret, here it means all the pieces)

Note: All of the answers (including this one) are just speculations. We still don't really know what is going on because PasswordBox aren't sharing much technical details. Lucas and I have already sent emails to PasswordBox and we're waiting for an answer. Once we receive a reply, the answers will be updated accordingly.

Adi
  • 43,808
  • 16
  • 135
  • 167
  • 6
    Shamir's Secret Sharing Scheme... – Deer Hunter Jun 12 '13 at 17:11
  • @DeerHunter now I've very curious. maybe if you explain in answer how shamir secret sharing scheme could be used in this context. the subject sound very interesting – John The Ripper Jun 12 '13 at 17:27
  • 2
    @JohnTheRipper - I was commenting on Adnan's idea of splitting the secret in two parts (2 of 2). For implementation, look at http://www.point-at-infinity.org/ssss/ – Deer Hunter Jun 12 '13 at 17:30
  • @DeerHunter Brilliant! I didn't know that there's such a straightforward implementation. – Adi Jun 12 '13 at 17:46
  • @Adnan this is cool. So it means that decryption key is split between PasswordBox, the User and the delegate (survivor). In the event of a death, PasswordBox combines its part of the secret with the delegate's and can therefore unlock the password. Did I get that right? – Mallory Jun 12 '13 at 17:49
  • 3
    @Mallory Please keep in mind that those are just speculations, we're still waiting for an answer from PasswordBox. Regarding this, the key could be split between PasswordBox and the client (the program installed on the deceased's mobile/computer). When an access is requested, PasswordBox would send its share of the key to the client, thus giving it the ability to reconstruct the full key and decrypt the data without needing the password. In this case, I'm assuming that PasswordBox are assuming that the son has access to his mother's mobile/computer. – Adi Jun 12 '13 at 17:53
  • @Mallory - we have no information on that. Let's wait for the results of Adnan's and Lucas' inquiries. – Deer Hunter Jun 12 '13 at 17:54
  • Just speculation, but the key could be split up into multiple partial keys that could be shared with survivors. For example, any 4 of your 7 chosen executors could together unencrypt. – emory Jun 12 '13 at 19:05
  • Adnan, I'm afraid you're not the only one to find the "explanation" incomprehensible. My BSometer is close to going off-scale. Will be interesting to hear others' thoughts. – Deer Hunter Jul 24 '13 at 18:35
10

Notice the phrase "This master password is NOT stored on our servers, so your secure data can't be retrieved by anyone but you." Actually, one does not necessarily mean the other, depending on the details.

Consider the following system: A symmetric key is generated on the client software by hashing your master password, hopefully with something reasonably strong like a sufficient number of PBKDF2 rounds. This key will be used to symmetrically encrypt your data, using something like AES-128 or AES-256 depending on how long a key they can generate from your password. That key is then encrypted asymmetrically (RSA, ECC) using a public key provided to your client by the storage service, and transmitted to them along with your encrypted data. The private key of that pair is physically secured in an HSM locked in a vault behind reinforced concrete, layers of authenticated access control and process rules to ensure no single person can ever get to it alone.

To decrypt your data normally, your master password must be re-hashed in the client software to obtain the symmetric key. If your password is not available because you've taken it to the grave, your next of kin must present your death certificate to the company representatives, who then retrieve a data dump of your account information and stored data from their servers to something portable. They take that into a secured room with access to the HSM vault, pull out the HSM, plug it into the computer, and run your encrypted symmetric key through it, then use the asymmetrically-decrypted key to symmetrically decrypt your data and give it to your family.

Your master password, therefore, is never stored on their servers, true to their word. Similarly, the key needed to decrypt yours is also technically not stored on their servers; it's kept offline to ensure that physical access to the device is required. So, normally, you are the only person who can get to your data. But, in the event of your death, through an audited process, your family can have the storage company retrieve your data.

EDIT FROM COMMENTS: This is just one possibility, and as the comments infer, may be assuming more about the company's actual internal processes than actually exist. The OP asked about the possibility of a system that could have client-side encryption while allowing server-side data recovery and still protecting the user's secret password. This is one such possibility, and I neither assert nor deny that PasswordBox is using anything like it.

KeithS
  • 6,678
  • 1
  • 22
  • 38
  • If they had secure reinforced concrete vaults and audited processes, they would advertise them. Otherwise they don't gain anything over keeping the private keys in the top drawer of the filing cabinet. Apart from that, this is the same answer as Adnan's - both a key on the server and a key on the client are needed to decrypt the information. – RoundTower Jun 13 '13 at 11:49
  • No. *Either* a key on the server and a key on the client can be used in the scheme I described, which is simpler than Adman's SSSS. The server never knows the password used to generate the key, nor the private key that can obtain it from the recovery key data it stores, but the user and the company have access to each. And the fact that the family has to present a death certificate is evidence in itself that the recovery mechanism has at least somewhat more process to it than storing the recovery key in a thumb drive in the top drawer. – KeithS Jun 13 '13 at 15:45
  • Companies that give a flip about IT security don't advertise a lot of the security measures they take. Why make it that much easier for an attacker to identify potential holes? – KeithS Jun 13 '13 at 15:46
7

The flow provided is remarkably lacking in technical detail. It provides the personnel process, but not the technical one. Hard to say, seeing it, what it means.

My original thought reading the FAQ was that the password is something a human can remember, but the "master password" is an inscruitable number built from the password and a process of salting it. That's used to encrypt the client side data prior to transport.

I'm assuming either:

  • the beneficiary can get a copy of the original password (not the master) and then using the original owner's machine, the beneficiary can unlock the master password getting client side access.

  • they are totally inconsistent and there's a way to decrypt the client data from the server.

I'll add a small rant here - I see this a lot with "security' services made for normal people. Either the effort to boil it down so the regular consumer feels safe renders the information technically meaningless, or they just don't put in enough thought to their design. Either way, it makes me crazy that a reasonably proficient technical person can't get a straight answer.

bethlakshmi
  • 11,606
  • 1
  • 27
  • 58
6

Note that there might a difference between the password and the encryption key!

The first statements says that there is no way that they would be able to decrypt your stuff without having your password. Considering the second statement, I believe that they are probably encrypting either an encryption key or all your files (duplicate) with their own master key/password. Which means they CAN decrypt your stuff and there is no confidentiality.

If they can decrypt it, it means they have some way of getting either your (encrypted) key (not your password) or they have a master key. Regardless they do have a way of accessing your data as they are storing the key (they have to if they want to decrypt the data if someone dies).

It can also be that you need to provide the key of the person after he died (if you can find it). Or another plausible scenario is that the encryption key itself is encrypted with the mother's password. When the mother requests to assign a heir, the son needs to provide a password which will then also encrypt the mother's decryption key. Now the decryption/encryption key is stored on their servers, but the key itself is encrypted with a password (so technically they can't get the key).

Now personally I'd prefer the files to be encrypred locally (completely) and then sent off to the service rather than the service holding my decryption key encrypted with my password. Because they would STILL have a access to the decryption key (albeit it's encrypted). I mean what would hold them from implementing a function that stores a copy of your key encrypted with their password?

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
2

I seem to be unable to comment so instead an answer, with a simple method how that can be achieved:

  1. The long and incredibly hard master password is generated.
  2. The software additionally creates a completely random (long) symmetric key. Let's call this symmetric key the DeathKey (basically a long random byte chunk).
  3. The software uses the DeathKey to encrypt your master password and sends this encrypted master password to PasswordBox.

Now PasswordBox is not able to "guess" your master password, because for that they would need the DeathKey (so you should never send this DeathKey to PasswordBox).

If you die, then PasswordBox gives the encrypted master password to your relative, who then uses the DeathKey stored on your computer to decrypt the encrypted master password.

Voila: Your relative now has the master password.

As for security:

  • The DeathKey is useless, as long as no one gets access to the encrypted master password stored at PasswordBox. After all it is just a completely random byte chunk.
  • The encrypted master password without the DeathKey is also useless. So as long as PasswordBox does not get access to your DeathKey, they can do nothing with it.

As already mentioned this is also just a simple algorithm how to do it; it is pure speculation if PasswordBox is using this algorithm.

Note: Of course you could also do it the other way round; you store the encrypted master password on your computer (encrypted with the DeathKey) and instead send this DeathKey to PasswordBox; once this is done, the DeathKey is completely erased from your computer. Now you have an encrypted master password on your computer, but the decryption key is stored at PasswordBox. This makes even more sense, because with this scenario PasswordBox just stores a random byte chunk (the DeathKey), which really has nothing to do with your master password.