[SvanteSpectator]

Hello Sven,

I do understand your scenario now. We don’t support that scenario right now, just like that. You could work around it by using a separate account for this of course. We do have plans on adding a feature where you can add passwords, and share it that way, and that might work but there are some practical issues with that need to be ironed out.

[SvanteSpectator]

Hello Alberto,

You can use the ‘Try Broken File’ feaature. It is a little hidden, so you first have to enable the ‘Debug’ menu by File | Options | Debug, and then try to decrypt the file with ‘Debug | Try Broken File’.

No guarantees – you’re likely to get some other message, but it may help you recover part of the file.

[SvanteSpectator]

Hello Sven,

We try to be really clear about the automatic upgrade of old files to version 2 format, but I guess we could be even clearer…

From what I understand, the key sharing feature of AxCrypt 2 is a perfect fit for your scenario. Let’s call you Sven and your in-law Bob, with email sven@one.test and bob@two.test .

Sven adds ‘bob@two.test’ as a key sharing recipient to ‘in-case-of-svens-death.txt’ . Now, Bob can open the file using his own password, without the need for a separate password in an envelope (of course Bob would keep such a backup anyway for his relatives in the case of his demise).

Bob adds ‘sven@one.test’ as a key sharing recipient to ‘in-case-of-bobs-death.txt’ . Now, Sven can open the file using his own password, without the need for a separate password in an envelope (of course Sven would keep such a backup anyway for his relatives in the case of his demise).

This also makes it easy to manage multiple possible recipients of this information, such as a spouse or child etc, should you wish to.

The only difference is the absence of the specific envelope with the separate password used for this mutual purpose, but that seems a little cumbersome I think and doesn’t really add anything. As you write – it’s still a case of mutual trust.

[SvanteSpectator]

Thanks Stephen,

It’s the same start bytes for the legacy version 1 as well, so it should work for all AxCrypt-files.

[SvanteSpectator]

Harvey P,

Thanks for your input, it’s much appreciated.

Just for the record, no we can’t decrypt the passwords stored in the password manager. We don’t know the password, and it’s encrypted using strong XML Encryption on the server. (Yes, in theory if our code is evil, we could – but that applies regardless of online / offline – including LastPass and 1Password. If their programmers are evil, they can get your information from your system. So you have to trust the code and the programmers. The difference is that our code runs on a locked down, single purpose server. Their code runs in the most hostile and dangerous environment known to man – privately managed PC’s).

As for the “if intercepted by hackers, allow decryption” – well, that’s just why we are strengthening the SSL configuration. And, while I know this view is not shared by all, I still would like to ask you what would you trust more:

– Encryption technology that is all pervasive, publically reviewed both from specifications and from implementation code, and used by essentially all networked devices on the planet – with known weaknesses mitigated by proper and validated configuration.

or

– Encryption technology that is closed source, proprietary, relatively new and never publically reviewed and used by relatively few users.

The former describes SSL/TLS, the latter describes  the “zero knowledge” schemes used locally by for example LastPass and 1Password.

Both services also use SSL/TLS for example for signing in to your account via the web. LastPass supports the weak algorithm 3DES on their web site, so a downgrade attack could possibly succeed.  1Password has actually gone one step further than we do, and simply drop backwards compability for a lot of clients by only supporting TLS 1.2.

1Password is run on Amazon Web Services – which means that anyone with access to that infrastructure can potentially intercept data or plant code there. As you probably know, there have been several well-documented cases of national agencies gaining access to large providers infrastructure.  We use physical owned servers located in Sweden.

I’m not saying that LastPass or 1Password are bad or insecure services. They are not. However, it’s not a simple equation to determine what is “more secure”. It really depends on both objective and subjective factors when you evaluate it.

[SvanteSpectator]

Hello Harvey P,

As mentioned, there are several reasons for sending sensitive information to the server, including the use of the online password manager. One can of course argue that in itself is a problem, but we’ve made an active decision to do this in order to gain all the usability benefits we get from it.

It is by no means a trivial decision, and either way we go it has serious impact on security and usability.

Regardless, it’s important that we keep good SSL hygiene.

[SvanteSpectator]

Hello Adam & David,

We are investigating this. The likely cause is a little too tight configuration of our SSL parameters, however although we’re sorry for the inconvenience we’d rather err on the safe side here.

The background is that since we’re relying on SSL/TLS to protect sensitive information when travelling to our server (passwords both for the account and the online password manager), it’s important that we maintain strong security. Since SSL/TLS has been under careful public (and secret) scrutiny for many many years, weaknesses have been discovered. Some are such that we really don’t want to allow such a connection, so we actually do not support some legacy “cipher suites” and protocols.

In other words – in some cases we’d rather not allow a client to connect and use a service, rather than allow an insecure connection.

One might argue that it’s the users decision, but in this case it’s just too hard to know as a user just what the risks are.

Also unfortunately, there’s no well-accepted best practices here since it all depends on the server capabilities and the level of security required, offset by other requirements as well such as performance.

So we’ve been very conservative, and may have locked some devices out. We have now amended this slightly, so perhaps you can try again and see if you have better luck.

In any case, do let us know, so we know if we should continue investigate.

[SvanteSpectator]

Thank you Callum!

[SvanteSpectator]

Hello Al,

Thank you for contacting us. No, we’re not that expensive ;-) We use the European Central Bank currency rates via an XML web service service, and it appears that for some reason the values were either sent by them, or interpreted by us, incorrectly. We cache these values for 24 hours, and it they were updated just before you checked and saw the surprising result.

This has actually been in operation for many years without a single problem, so it was a bit of a surprise that it suddenly just stopped working as intended!

Once again – thank you for notifying us of this.

[SvanteSpectator]

Hello Jason!

Thanks for the input and ideas. A general comment is that when password-based encryption becomes too transparent, i.e. you don’t have to enter the password at all or very infrequently, is that that people tend to forget it’s there. Which is a good thing until… you for some reason need to re-enter the password, perhaps after moving the data to a new computer, and realize that you don’t remember it any more. That’s one of the reasons we think that it’s a good thing to actually have to enter the password at certain times, even if it can feel annoying.

We may in the future offer regular licenses instead of subscriptions, but there’s quite some work in order to do so, and we think the subscription plan in many ways is more fair. Read https://forum.axcrypt.net/blog/subscription-vs-license/ for a longer discussion of this.

[SvanteSpectator]

Hello David,

Can you please try to browse to https://account.axcrypt.net/ from your Android device and ensure that it can establish a connection with the server?

We have recently tightened security on the SSL configuration, and there is a potential for older devices not being able to connect due to this. You have a fairly recent version though, so it should be ok but let’s start there.

[SvanteSpectator]

Hello Richard,

This is integral to how AxCrypt works, so they must be there when you are working on them. They should be cleaned when you exit the application.

You can enable EFS (Encrypting File System) for the folder %localappdata%\AxCrypt if you wish.

[SvanteSpectator]

Hello Bryan,

Thank you for the report, we’ll be looking into this asap. You can follow progress here: https://bitbucket.org/axcryptab/axcrypt-xwt/issues/168/temporaries-are-not-cleaned .

[SvanteSpectator]

Hello Greg,

First of all, ensure that you have not already registered an AxCrypt ID account for the new email.

Then sign in to https://forum.axcrypt.net/ using the old password and the old email, and under settings change y0ur email to the new.

Then you can download and install AxCrypt on the new PC, use the new e-mail and purchase Premium when appropriate.

If you wish to use the new email in the old PC, click “Cancel” at the AxCrypt sign in, then do File | Options | Clear All Settings and Exit.

 

[SvanteSpectator]

Hello Bryan,

Simultaneous access of a shared file on a network share is always a little tricky and not something Windows really supports.

With AxCrypt it gets even more so.

When you open an AxCrypt-encrypted file (double-click), what happens is the following:

1) The file is decrypted to a temporary location on your local hard drive.

2) Your local copy of AxCrypt marks the file as “open for editing”, and tries to keep track of when it’s time to re-encrypt it. It lights the red “Broom” (clean up) icon in order to indicate this. AxCrypt cannot successfully keep track of all situations and determine when you’re done with the file, so sometimes you may have to do this manually by clicking the broom icon.

3) AxCrypt launches whatever application Windows thinks is best for the decrypted file (Microsoft Office or Excel in your case).

So, this is the situation when someone starts editing the file, on the mac or the windows server. After making some changes, you click ‘Save’. This saves it to the temporary location on your hard drive. Since you still have Word / Excel open, AxCrypt will typically not re-encrypt the update to the shared encrypted file (this behavior depends on the individual application and the situation at startup, but for Word / Excel this is what happens).

Thus, while you’re happily editing and saving changes, these are only saved to the temporary decrypted copy. Until you fully close Word / Excel, at which point they file will be automatically re-encrypted to the shared location, and changes made visible to others – *if* they open the file after the update.

Note that AxCrypt does not stop more than one person from editing the file at the same time (we’re working on at least blocking more than one person from making updates but we don’t have that just yet).

If the situation arises that several people are editing the same file at the same time, “last one to save and exit wins”.

The part in your description I can’t explain is: “I can see, from both Macs, that the document has been modified“, unless you by this mean that while the same file is open on the Mac, and you look at the share, you see the last modification date has been updated. If the file is not open on the Mac, and has been cleaned (no red broom icon), then if you open the (modified) file, the changes should really be seen on the Mac as well.

[Author]

Posts