This topic contains 11 replies, has 2 voices, and was last updated by Svante 6 years, 5 months ago.
We’ve just opened up for beta testing of our AxCrypt iOS app. Now you can open and view your encrypted files and documents on the road in any iOS device!
Send an email to email@example.com to get an invite, and then follow the instructions. You’ll need to install TestFlight from Apple as well.
There’s a feedback function in the app, but you can also give feedback here and via Premium support.
Premium or Premium Trial is required to use the apps.
That’s great news Svante! Forum users should be aware that this will be a Premium-only feature (I believe?).
Two things that surprise me about the app:
* Unless one shuts down the app (double-click, flip up), it remains logged in the whole time. Isn’t that a trifle dangerous? I am sure that you will have thought through the reasoning for this, but I would be interested to learn why!
* There is no fingerprint integration – but maybe this is linked to the no-log-off decision?
Keep up the good work!
It is indeed a Premium-feature. Sorry, but if it’s any consolation every dollar that is paid for AxCrypt Premium goes into design and development of new features and platforms – the income goes right back into the software.
– You can explicitly sign out of the app. It remains signed in with essentially the same reasoning we have for the desktop app. See http://www.axcrypt.net/blog/leaving-computer-axcrypt/ for a longer dicussion about this. Briefly – use pin codes or Touch ID to lock your phone.
– We could do a partial finger print integration, and we may in the future, assuming that one signs in at least once in order for us to store the password in the phone but there are some fundamental differences between biometric identity credentials and the secret that is required for encryption. Also here, I’ve made a longer argument: http://www.axcrypt.net/blog/encryption-and-biometrics/ .
Thanks for that. I am fine with the desktop reasoning, but as you say: ‘it’ll stay signed in until you sign out, or the screen saver goes active, or the device goes to sleep…’. But with the iOS device it does not do that: it stays active ‘forever’ ie for days on end, even if the phone is not used. I must say I would prefer to have some depth of security, not just sole reliance on phone access.
I’ll have to look harder for the method of ‘explicitly sign out of the app’…..(or maybe you are referring to the iOS double-tap-swipe?). I thought that the ‘key icon’ might logically do the job, but that’s the web sign-in. Ah, found it at the bottom of the menu page…
Since I use LastPass and SpiderOak with iOS I guess that I have got too used to the ‘always re-authenticate’ regime!
Even if fingerprint was not enabled, even a PIN would be great.
Still, its great to have iOS access back again!
We’ll evaluate the sign in / sign out options for the mobile apps as we go along, but right now we’re depending to a large degree on the inherent security of the device encryption capabilities since there are so many aspects of a mobile phone we can’t control without rooting it and doing all kinds of bad stuff. Even if we did sign out, without device encryption, there will be at least some information available for a persistent attacker that has physical access to your phone.
So – ensure that you are using device encryption and a pin or Touch ID or equivalent to unlock your phone. This applies regardless if you use AxCrypt Mobile or not!
Looking back, I see in another post you stated ‘ Idle time close. Yes, it’s a relatively frequently requested feature. Coming soon!’
I continue to be concerned about the ‘always stay on even after sleep’ nature of the iOS app. I, for one, would like some depth in my file protection. I would like to rely on more than just my (six digit) iOS access code.
You should use the “Erase Data” option if someone tries your passcode too many times. As mentioned, even if we did require the AxCrypt password every time, a phone is such a locked down environment that we could not guarantee it to be clean anyway.
The iOS level of protection against passcode attempts is actually pretty solid. The FBI did manage to get around it in an old iPhone 4S after several months and paying an undisclosed (but presumably significant) amount of money to a third party to bypass the protection. More recent versions of iOS does not have that particular vulnerability.
Yes, I am quite aware of that thank you. BUT I am an avid believer in DEPTH of protection – and also my phone is sometimes ‘in the hands of others’ (for instance, taking photos). The sole reason that I use AxCrypt is for this Depth (for just a very few of my ‘very special’ files) – I am OK with my ‘transmission medium’ (SpiderOak, that does have log-off options of course) and also OK with my password manager (LastPass, that does have log-off options of course). Also, both have other-device options where I can kill a compromised password so that the old password is totally useless.
Whatever, Happy Christmas!
You can take photographs from the lock screen Robin. You should never hand your phone to somebody when unlocked unless you really trust them!
Defence in depth is a neat concept but, just like the person taking a photograph on your unlocked phone, you have to trust AxCrypt not to store your password. The point is that if you have “very special files” then you should not be storing these on your phone because there are too many variables out of AxCrypt’s hands which can lead to full compromise of your data.
I know you say you’re using SpiderOak and that’s a good solution but last time I tried it I was unable to edit files. There’s also Tresorit which is more expensive (true zero-knowledge) but by far more suited to mobile devices and desktops as it allows real-time editing, viewing files, locking with TouchID or a PIN, remote revocation, 2SV, limiting access by device, limiting access by IP range. It’s designed for professionals so may not be suited.
AxCrypt is geared towards users who store data in Dropbox, Google Drive, OneDrive (i.e. none of these use zero-knowledge encryption).
Hi Lucas. I am not sure if you work for AxCrypt, but I lot of your posts seem orientated towards pust a number of us long-term-users away from the product. Is it a stated policy of Svante that ‘AxCrypt is geared towards users who store data in Dropbox, Google Drive, OneDrive’?. Wow! I thought that it was/is a great product for a user even if they had no use for cloud storage or synchronisation!
I have used AxCrypt for many years and it used to do exactly what I wanted. That included just-what-I wanted iOS and OSX integration. I have a great deal of loyalty (and faith) in the product.
You put down the guy who had users sharing one login – pushing him towards MS Office file passwords. But why not let him continue to propose a configuration of AxCrypt that suits his use? At least Svante has the right to consider such suggestions from users.
That said, it looks like the direction that is going will longer suit my use, so I had better butt out….
Hi Robin, no I don’t work for AxCrupt but I have used both versions of the software as an end-user and have extensive experience of cryptography.
Personally I prefer 1.7 like many other people on this forum because of its simplicity.
AxCrypt 2 changes the trust model and requires us to trust not only the developers of AxCrypt but also the SSL/TLS protocol (and the issuing authority), the integrity of our email providers and the security of AxCrypt’s servers. In addition we have to blindly accept that AxCrypt are not being secretly compelled by their Government not to store our passwords. With 1.7 these attack surfaces didn’t exist.
There is a place for AxCrypt 2 and that is for users who want simplicity, need support and are prepared to pay for the product.
Axcrypt is 100% geared towards cloud storage and sharing. It isn’t a full disk encryption product and will not protect you from an adversary who has uncontrolled access to your computer. Nor does Svante suggest it is a substitute for FDE.
<p style=”text-align: left;”>AxCrypt complements FDE by encrypting individual files. Obviously this would only be necessary if you’re sharing the files with others or emailing sensitive information.</p>
<p style=”text-align: left;”>It has been made clear by Svante that AxCrypt will not be returning to the previous position of allowing multiple passwords because he considers it a security risk. He’s written this in a blog post!</p>
<p style=”text-align: left;”>The guy using Microsoft Office had multiple people using the computer and AxCrypt 2 (with its one password policy) wouldn’t protect them in that scenario. I did not “put him down”; I suggested a better alternative for his situation.</p>
<p style=”text-align: left;”>AxCrypt 1.7 has been abandoned and will no longer be updated. This may have suited the Microsoft Office guy but it wouldn’t be sensible to recommend a product which is no longer being updated as that in intself is a security risk.</p>
<p style=”text-align: left;”>If you like AxCrypt 2 that’s great. The developer seems genuinely nice and honest and he needs to earn a living. But none of that changes the position that people need to use the product that suits their needs.</p>
<p style=”text-align: left;”>So, I’ll repeat myself: AxCrypt 2 is very much geared towards sharing files and cloud synchronisation.</p>
Hi Robin (& Lucas),
As Lucas says, no there’s no connection with AxCrypt. Lucas is just an engaged member of the community, for which we’re grateful. He’s in his full right to point out alternatives, and I am very much for an open, honest and objective climate in these forums so I’m perfectly fine with suggestions for alternative softwares or solutions. AxCrypt is not perfect, not in version 1, not in version 2. Nor is any other product.
We’ll be continuing to develop AxCrypt and for this to go in the right direction, we need input – be it positive or negative.
As mentioned elsewhere, we will be providing the option to request the password every time as a result of feedback. We may indeed also implement some model of use which is closer to the version 1.x, but that remains to be seen. Lucas is of course right that the AxCrypt 2 model does open up a few more attack vectors, but in each case we judge the benefit to be worth it. We are trying to make a product that is really useful for a large number of users, and this means we have to make tradeoffs from a theoretical zero knowledge model, in order to make the product useful in practice.
Finally, AxCrypt is indeed mostly suited for data transmitted over the Internet (i.e. email attachments), or stored remotely (i.e. cloud services, backups). For local device security I do indeed generally recommend full disk encryption or possibly file system level encryption such as Windows EFS, which is often well complemented by file encryption such as AxCrypt. Using file encryption software (be it AxCrypt, 7-zip or MS Office built-in) leaves quite a few holes on a local computer, that are more or less impossible to plug in the softwares themselves (temporary files, swap files, wear levelling in SSD etc). These holes are plugged very efficiently by full disk encryption. Similar arguments, but even more so, apply to mobile devices.
So, our recommendation is to use some kind of device or full disk encryption for local device security + some form of file level encryption for remote storage and transmission (we think AxCrypt is a good choice).