Now that’s strong!

1. The maskerkey is generated randomly in the browser
2. The masterkey is encrypted using a 256-bit derivation of the Packing Key
3. The encrypted masterkey is sent to the server
4. The server send it to the remote service that encrypts it again
5. The final double-encrypted masterkey is finally saved.

So all depends on the Packing Key. Since the Packing Key is hashed in the browser and only the hash is sent to the server, the process is Host-proof Hosting.
Obviously, as Ivan says, we can performe a brute force attack to our system. But… why we should do it?

@Ivan, I think that the best solution is always to put your data not in only one place. In 2008 we introduced Passpack Desktop in order to offer a desktop application that can be used stand-alone or like a full local backup of the online account. It is a must, in my opinion. But, unfortunately, only a small percentage of the users seems to use it.

It seems like you’ve eliminated the Host-proof Hosting.

Well, I actually thought that the Packing Key couldn’t still be changed at all (I tried to some years ago, and didn’t check back lately).

Anyway you’re right, I overrated the security of having the Pack encrypted with a key which is never known in any of its derivations by the server. After all, running a brute force attack against the Pack (or the Master Key) to discover the “private” encryption key wouldn’t be harder than running an attack against the hashed Packing Key (actually, I guess that thanks to Spino the latter could be even harder).

But still I thought that you could use such an option for “political” reasons.

You could say that it makes your system verifiably host-proof (everybody could verify the javascript and audition what’s being sent), and that even if you were an evil organisation which is able to somehow mystically reverse all its hashes (don’t take me wrong, I know you can’t), there would still be something that you had no way to know.
Of course, if you were so evil you could run a brute force attack against the encrypted pack, but if the password was strong enough the pack would be safe from your wicked hands.

Also, it could have been a good answer in cases like this, to all the superficial “don’t trust the cloud” criticism from LifeHacker and other media.
You could have said that even if the cloud collapses, your whole system gets compromised, all the databases lost to attackers, and all hashes reversed, there would still be something that has never been in the cloud… and their passwords pack would be left encrypted in just the same status as it would have been if they used the desktop password managers which they love so much.

BUT, your gramps gave you some terrible advice. He should have thought you about self defense and self reliance because when the ‘big friend’ is gone you are now again exposed all over again.
All it does is postpones the inevitable and gives the opposing side more time to even more carefully plan an attack. Don’t pass this advice to your kids and don’t let them hide in shadows of others…teach about better passwords :o

@Ivan, you write:

But wouldn’t it be possible to have a Packing Key (maybe a third one?) which is never sent to or known by the server, but only validated client-side by checking if it can decrypt the Pack?

It was so until the version 4 of Passpack. But this was not so secure how you can imagine. Because your security is a concept that has many shades.

For example, people often forget their Packing Key after having changed it. In this case we can roll back the keys set of the user and he is safe. With the old approach your pack would have been definitely lost.

Instead, now we can recover it because all the entries (and the other data in your pack) aren’t encrypted directly with the Packing Key, but with a set of several keys, depending on a lot of factors. This basic keys set is encrypted using a Master Key. In turn, this Master Key is encrypted using a derivation of the Packing Key.

So when you change your Packing Key, a new Master Key record is created in the database. This allows to recover the old record, and it is able to recover the basic keys set if you have the old Packing Key.

Anyway, imagine that we would validate the Packing Key trying to decrypt the Master Key on the client-side, also an attacker that raise access to the database can try to discover the Packing Key with a brute force dictionary attack to the encrypted Master Key. This would be harder, but it would be possible.

How to avoid this? The solution — as you can guess — is a Spino’s brother that receives the Master Key encrypted by the browser, encrypts it again with a secret key and returns the double-encrypted Master Key so that it can be saved in the database.

Using a customised hashing iteration function could sound a bit of security-through-obscurity, but I can see that by iterating for an odd amount of times and adding some odd value to the salt (and maybe something which is variable in some way) in line 21 would build up a whole hashing function which would be so hard to reconstruct for an attacker, even by knowing existing plaintext/hash couples.

What I wonder about is why you’d need to store an hash of the Packing Key at all.

Actually I thought you used a totally different approach from LastPass, since from the “Data Privacy” page it looks like the Packing Key is never sent to the server but used only locally to decrypt the Pack.

Now by analysing the traffic it looks like the Pack is sent to the client only after verifying the Packing Key server-side, which is anyway a good move for not giving away too easily Packs, even if they are encrypted.

But wouldn’t it be possible to have a Packing Key (maybe a third one?) which is never sent to or known by the server, but only validated client-side by checking if it can decrypt the Pack? Wouldn’t it add an ultimate layer of security?