How secure is Lazarus Sync?

Short Answer: Really Secure. 

All data sent to our servers is encrypted before it leaves your machine using a unique key derived from your passphrase. Neither your password or the derived SyncKey is ever sent to our servers.

The encryption used is AES 192, which is certified for encryption of  Top Secret material by the US Govt, and generally considered absolutely unbreakable if you use a long enough password. On the other hand...

Short or common passwords are vulnerable to brute force and dictionary attacks. Pick a passkey over 12 characters long that isn't easily guessable, and you'll never have to worry about the data on the sync server -- unless someone is able to access your local machine, in which case all bets are off. We'll do a little more to protect against that unpleasant  scenario in the future, but obviously we can't protect against every possible scenario. 

Local copies of your forms will not be encrypted until you set a form recovery password, which we highly recommend, but don't enforce, because some people feel they already have enough security and passwords on their machines. 

Long Answer: We're really quite serious about this whole security thing. 

Again, the important thing is that the Lazarus Sync protocol data is encrypted before it leaves your machine, and using a cryptographic algorithm currently considered unbreakable within the lifetime of the universe - unless you use a really short password / passphrase. 

You only have to enter your sync passphrase once on each installation of Lazarus, so we recommend choosing an easy to remember "Pass Phrase" that nobody else would be likely to use. If instead you use a very short password, then you may be vulnerable to brute force attacks that try every letter, or "dictionary attacks" that leverage a list of common passwords people use. For a detailed explanation of how and why to pick a strong passphrase, see here.

Furthermore, to significantly reduce the danger from brute force and dictionary attacks, Lazarus hardens your Sync Password/Passphrase with the PBKDF2 key derivation algo, and it is the thus derived hardened PassKey that is stored for future use in the Lazarus Sync encryption and decryption steps. 

A SyncKey is then derived via 1-way hash from the PassKey. The SyncKey is simply used to let the Sync Server know your Lazarus has the right derived PassKey, without actually transmitting the PassKey to the server.

Some extra details

For PassKey stretching we use the PDBKDF2 algorithm, with your email address as the salt and 10,000 rounds of SHA256 hashing. In future versions we will add an option to let you increase the hashing level, and/or add an option to use the recently introduced scrypt password stretching algo, which increases brute forcing protection against massively parallel hardware attacks. 

As an encryption codebase we use the highly respected Stanford Javascript Cryptographic Library.

For what it's worth,javascript encryption has actually been described as a "bad idea" in the past - and the reasons for that assertion have generally been: 

(a) javascript is too slow - which is no longer true, javascript engines in modern browsers are now really fast.

(b) that it's fundamentally insecure, because the javascript on a webpage has to be downloaded via a potentially insecure channel. However, Lazarus is a browser add-on, not a script on a website, The code comes in a download  cryptographically signed by us, and the encryption code executes in a sandbox protected from any meddling by scripts on websites. So the usual objections vs javascript based encryption do not apply to Lazarus.  

In fact, your data is vastly more secure this way than it would be if it was only protected in transit over a secure channel to be stored on the server side. In that (highly typical) scenario you have to trust the service provider to run a completely secure server environment - and in case you've missed the headlines - even very large companies often fail to do that. 

Seriously, could something go wrong? 

Not to belabor the point, but even if our servers do get compromised, your data is encrypted before it leaves your machine, so an attacker would need to know your sync password / PassKey in order to decrypt it, and your PassKey is only stored in the browser datastore, never sent to our server. 

Likewise, intercepting the data in transit (man-in-the-middle attacks) could only result in the attacker gaining the data after it has already been encrypted on your machine, and thus, they would need your password in order to read it. 

But there are going to be scenarios where yes, something could go wrong, but we'll do our best to keep improving. Just for instance;

You could download something that looked like Lazarus, but wasn't. That's highly unlikely, and our updates are signed by us before you get them, but you might want to check the name attached to them in your extensions list if you're rally worried. 

If an attacker was to gain physical access to your machine then they could right-click and restore forms just like you can, and there is not a lot we can do about that. However, even this can easily be prevented by setting a Lazarus password so that each individual entry is encrypted locally as well, before being encrypted again for the Sync. 

We obviously can't protect you from Rootkits, Keyloggers, or someone looking over your shoulder while you type in your password. But you knew that, right? 

About the strength of AES 192 encryption:

At the time of writing (18-Mar-2012) the 192 bit AES encryption methods we use for encrypting the sync key and each individual piece of data are secure enough for the U.S. National Security Agency to state:

The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths.

And for some pundits to speculate that they are essentially unbreakable. Quoting the CTO of PGP Corporation:

"Imagine a computer that is the size of a grain of sand that can test keys against some encrypted data. Also imagine that it can test a key in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 meter. The cluster of computers would crack a 128-bit key on average in 1,000 years."