This topic contains 14 replies, has 2 voices, and was last updated by Harvey P 9 months, 2 weeks ago.
September 1, 2017 at 14:27 #7717
I have installed the AxCrypt android version in my phone (android V 7.1.1). When I try to log in I enter my e-mail and password and I get a message saying something like: “Error. It is not possible to connect to the server. Please check your internet connection” (translated from spanish)
I’m sure that the phone is connected to internet. I know i’m using the rigth password since I can log in when I use AxCryptor in my PC.
Just to check, instead of log in I have pressed “Register” but when I tried to enter another email address I got the same error mesage.
Any idea of what’s wrong? (Thank you in advanced)September 1, 2017 at 16:09 #7720
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.September 1, 2017 at 18:14 #7721
I followed your link and I was able to log in. Once I was logged in I tried trough the app bit I hoy the dame error I reportes before
Just in case ir hemos, My phone is a BQ Aquaris X (fairly new model).September 1, 2017 at 18:22 #7722
Sorry for my spelling in my last post (I didn’t checked it before sending it). What I meant to write was:
I followed your link and I was able to log in. Once I was logged in I tried through the app but I got the same error I reported before
Just in case it helps, My phone is a BQ Aquaris X (fairly new model).
If double post is not allowed please delete the previous one (for shake of clarity)September 1, 2017 at 19:19 #7723
The site works all the way back to Android 4, you’re using version 7 (the latest) so the page should work.
Have you tried connecting via WiFi or 4G?
Try another web browser and report back.September 1, 2017 at 20:07 #7724
My problem is with the android app (as I said I had no problem to log in using the web browser).
I tried both 4g and wifi. The phone is connected to internet for sure.
Thanks anywaySeptember 4, 2017 at 02:00 #7734
I just purchased the annual subscription of AxCrypt based on the awesome reviews I have seen. The software works great on my Windows 10 machine, however, I am getting the same error as the person mentioned in the original post. I have tried it with WiFi and 4G LTE with the same results. I am using the Google Pixel XL from last year on Android 8.0.0, and am able to view the page mentioned by Svante in his first response. I only receive the error when attempting to login to the mobile application.September 4, 2017 at 09:09 #7736
This seems like a problem in the Android app.
As you’re a premium customer you can get direct support by email. Send AxCrypt a message and they’ll get the problem fixed.September 4, 2017 at 10:31 #7737
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.September 4, 2017 at 10:51 #7738
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.
There’s no reason why the password needs to be sent to AxCrypt; it invites trade-offs like this.
Instead of sending the user’s password to AxCrypt why not send the user a one-time code via email/SMS/push message? That would be sufficient proof to allow them to retrieve the private key from the server and the password would be used locally to unlock the private key.September 4, 2017 at 11:08 #7739
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.September 4, 2017 at 11:32 #7740
I’ve just tried to log in using the android app and it worked properly.
At least in my case, the issue is solved.
Thank you for your supportSeptember 4, 2017 at 12:05 #7741
Glad to hear it’s working for you David.
As mentioned, there are several reasons for sending sensitive information to the server, including the use of the online password manager.
I don’t use the online password manager (I use Password Safe instead) so I took a look at the AxCrypt one and I saw that the passwords would be visible on the website.
I was under the impression that it was a file downloaded and decrypted on the device. I see it’s not; it’s decrypted by the server on the fly.
With respect I think the password manager service should be gracefully retired as it offers a poor level of security and comes with the risk that the password is transmitted to the server and could:
- if stored, be decrypted by employees
- if intercepted by hackers, allow decryption.
AxCrypt is great but the password manager isn’t.
I agree that it’s the person’s choice if they choose to use the password manager but with zero knowledge services out there like LastPass and 1Password it’s difficult to justify using a password manager service which isn’t especially secure.
I now understand why some people on here keep talking about the Offline Mode.September 4, 2017 at 12:34 #7742
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.
– 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.September 4, 2017 at 12:48 #7743
Wow, that’s a comprehensive response, thank you.
I know that LastPass and 1Password are both closed source solutions. It’s one of the main reasons I use Password Safe as it’s open source, has been audited several times and I’ve used it for years. I’m going to migrate to KeePass when I get time as it’s got more features and has received a €1 million security audit by the EU.
I prefer software that is under my control because if LastPass or 1Password go out of business they might not give a grace period for downloading your data. AxCrypt suffer from the same problem here in that respect because the password database is exclusively online. I’ve tested AxCrypt on my other computers and I can still decrypt files without an internet connection so I’m not at all concerned about losing access to my important files because I have a backup copy of AxCrypt.
I wholeheartedly agree with locking down the SSL configuration: it should be tight and secure. Now 3DES is obsolescent according to the US Government LastPass should stop using it.
The argument for having your servers in Sweden is a good one but it still relies upon me trusting you (just like I’d have to trust LastPass or 1Password) because your server source isn’t open sourced and it wouldn’t matter even if it was because there’d be no way I could verify whether that was actually in use.
I don’t know the mechanics of 1Password because I don’t use it but I’d like to believe that even if they’re using AWS that they’re checking data integrity on the database to stop this type of attack and they’re probably using a dedicated server instead of shared hosting which’d make it more difficult.