How does Axcrypt validate passwords if the private keys are encrypted on server?

[Aaron]

Hello,

I was reading older forum posts about Axcrypt’s key security. I was here https://forum.axcrypt.net/forums/topic/password-question/ and I read this post from Svante

The idea with AxCrypt is that if a file encrypted with AxCrypt is leaked or stolen, it should not be possible to decrypt it without the password.

What we store on the server are essentially just that – an AxCrypt file that encrypts not your password, but the private key of a key pair. So, a hack of the server is equivalent to a leak of an AxCrypt-encrypted file. And it’s just this scenario that AxCrypt is made for.

This is not to belittle the risk, and of course we realize that our server is more of a specific target than a typical users PC.

So, just to be clear, we do not store your password on the server. We do store an AxCrypt file encrypted with your password. If you’re using the password manager, we also store an XML-encrypted file, encrypted with your password. (We’ll be changing this in the future to use AxCrypt of course, to simplify security analysis, but since we like full disclosure this is how it’s done right now for historical reasons).

You ask why we do this? The answer is to be able to enable sharing of encrypted files in an unparallelled simple but still secure way. It’s also to ensure that your key pair is backed up. The most common cause for data loss in Windows is use of the Encrypted File System, which generates a key pair stored and encrypted locally. When a password reset is made, or Windows is re-installed, that key pair is permanently lost with all the EFS-encrypted data along with it. We’d like to avoid that, which is why we both keep backup copies of the key pair on our server, and also support decryption with only the password. In AxCrypt the key pair which we call an AxCrypt ID is really just for convenience, it’s not the primary vehicle of security. In the end, it’s always the strength and secrecy of the password used that determines the level of actual security.

I think you sum it up in the end when you say that your priority is security ahead of convenience.

We are of the opinion that security solutions must be so easy to use that they actually are used. This will be more secure, than a solution that is more secure but so hard to use, that it’s not used. That’s unfortunately the situation currently – there are many really secure solutions out there. Why are they not used? Because it’s too hard and inconvenient is my belief.

With that for context, my questions relate to how Axcrypt can validate server-side that my password is correct, without having to decrypt the private-key to read it?
If the backend is using the user-supplied password to decrypt the private-key to prove that the password is valid then how is the decrypted private key protected?

This is an interesting approach but I feel that there are gaps in my knowledge as to how this works. If I could have those gaps filled I would appreciate it.

-Aaron

[SvanteSpectator]

Hello Aaron,

You pose a very relevant question.

What we actually do on the server at this time, is to use the password manager encrypted XML as a vehicle to verify the password. We don’t actually decrypt or necessarily even keep a password manager file around, but instead in our handler for a sign in, we try to decrypt a “dummy” encrypted XML. If it succeeds, the password is verified. We’re not worried that this is a bad or insecure approach, but as mentioned in the original post, all security analysis is eased if complexity is reduced, so in the future we’ll be using the encrypted private key instead.

If you’re offline using a desktop app, we use the private key and we check to see if we can decrypt the private key AxCrypt-file in order to verify the password.  We don’t actually decrypt it – we just verify that we can.

Exactly how this is done is explained in the technical documentation of the AxCrypt file format. Briefly: All AxCrypt-encrypted files are encrypted with a random key uniquely generated for every time a file is encrypted. This key, the “session key” as it were, is then encrypted using the NIST AES Key Wrap algorithm using your password (and if it’s a normal file, also with your public key). So what we do when we encrypt the private key is we encrypt it with a random key, then encrypt that key with the NIST AES Key Wrap, and to verify we just attempt to unwrap the session key. The key wrap is self-verifying, so we’ll know if we get the right session key, and thus if the password is correct.

So, in either case, we don’t actually need to decrypt the private key in order to verify the password.

[Author]

Posts