Forums Bugs & issues Can't open existing Axcrypt files with latest version of Axcrypt Reply To: Can't open existing Axcrypt files with latest version of Axcrypt

#3277 Reply

Svante
Spectator

Hello Robert!

No, it’s not a stupid question… But the answer is important. So where we go.

In the good old days (and scarily enough even today in way too many cases), log in to sites was done by storing your password as you type it, typically in a column in a database or a in key-value text file.

Then as it was realized this was a bad idea, a hash of the password was stored instead. This is still the most common form. The idea is that it’s computationally impossible to reverse a hash, so you can verify a password, but not figure out what it is from the data stored on the server.

Then, as computers got faster and memory larger, people figured out they could precompute huge tables with potential passwords and hashes, and then do a quick reverse look-up. This was about 40 years ago, in the early 1970’s and the good people at AT&T developing Unix incorporated the idea of a salt, a non-secret random quantity added to the hasing process along with the password, making pre-computing more or less infeasible. What’s really scary is that this basic technique is over 40 years old, and still probably over half of the systems today including newly developed (for example Linked In up until 2012) still don’t use this elementary technique!

All of the above store the password or a direct computation from the password on the server.

What AxCrypt does is subtly different. Here’s the thing: What is AxCrypt made for? It’s made so that if an attacker gains access to an encrypted file, the only recourse is brute force (trying each and every possible password) and that is actively made more difficult by an iterative process.

What we *do* store on the server, are one (possibly a few) encrypted files, one AxCrypt-encrypted file and one XML-encrypted file (for historical reasons, we’ll migrate to AxCrypt for that as well). These encrypted files contain the secret part of a RSA key-pair, which is the technique we use to implement key sharing (sharing of encrypted files among users, who use their own passwords) and optionally passwords stored using the password manager.

So, while we do not store your password on the server, we do store data encrypted with your password. In one sense this is similar to storing password hashes, but in another important aspect it is very different.

Our assumption when describing the security model of AxCrypt is that an attacker has access to your files, our specifications and our code. I.e. – nothing is secret except the password.

Thus, assuming an attacker would gain access to the server and export a file encrypted with your password, nothing has changed. We already assume that an attacker has that access, since that’s what AxCrypt is made for – to protect your files if they are exposed.

Now, there is one twist to this. We do send the password to the server and let the server decrypt the file if necessary. This is not strictly speaking necessary, we could pass the encrypted data to the client and do all cryptographic stuff on the client. However, our thought is that we gain a lot of usability and flexibility for the users by doing it this way, at a very low expense security-wise. Our users already entrust us with their data via our code on their clients (where we have little control over the environment), so we think it’s a reasonable compromise to allow our servers (where we have very strict control over the environment) the same access. The ‘weak’ link in this case is the transport over SSL. Here’s the thing with AxCrypt and me – we’re not conspiracy theorists. We actually believe SSL works, and Snowden appears to agree with us. Strong encryption works. That’s why the agencies have had to cheat so much!

Right now we’ve made the call to prioritize usability over a formal zero-knowledge model. I’m not really a big fan of the zero-model knowledge model when applied to situations like this, since it essentially assumes the user is absolutely trustworthy, which (s)he is not! It’s theoretical model, that works differently in practice.

This decision may change in the future, we’ve not built anything that absolutely requires the password to be made available to the server at all, but right now, yes it is during the sign in process and when working online via the website or the REST API. But we don’t store the password or a hash. We do store one or more encrypted files.