Forums › Help & support › unique password for a file
This topic contains 18 replies, has 3 voices, and was last updated by Jack C. 1 year, 9 months ago.
In version 2 ow do I use unique passwords for individual files?
Sorry, you don’t! Read https://forum.axcrypt.net/blog/use-of-different-passwords/ for more information about why we did it this way.
I did read the suggested write-up, and it is not convincing. it is an interesting theory, but 99% of it is individual judgement from its author, with which one may agree or disagree, just like beliefs, preferences and religions, no proven theory in there.
what was nice with the previous version of Axcrypt is you could use a few different passwords for different categories of files to protect and different individuals you might want to share each category with. this is sadly lost.
Yepp, the post reflects the authors professional opinion, i.e. me. I’m the person who makes all the design decisions concerning AxCrypt, and has done so for the last 17 years or so. The idea is that while of course I’m not perfect, I do have a fairly good grasp of the overall situation as well as the nitty gritty details. Also, while perhaps there are no proofs, much of the reasoning is based on best practices in the security and cryptograhpy community.
AxCrypt has always been about me taking informed, professional, decisions on the behalf of my users – so you don’t have to. That’s why you can’t chose algorithms. That’s why the installation does not have a single choice.
After much reflection, I’ve come to the conclusion that the only relevant reason for having different passwords, is for sharing with other persons. We address that instead by way of the key sharing function, which scales better and is just so much safer any way you look at it (with the possible exception of the invitation scenario, where you invite a user to share secure access to a file before (s)he has a registered AxCrypt account in which case we do have access to the private key until that user sets the password).
So, what you should do to share secure access with different individuals is to use the key sharing function, which uses proven public key technology to achieve this goal without the need of sharing passwords.
OK, so I need to change habit and learn a new way of doing things.
1. BTW, if this is the case and I can only use the one password required to open the app, why is there a possibility in manage passwords to enter additional passwords, if you cannot select which one to use for a given set of files?
2. and how do I change the password Required to open the app?
1 – The password manager is a general purpose password manager. We do expect you to have different passwords for different online services for example. The only password it does not make sense to keep there, is your AxCrypt ID password…
2 – You use the ‘File | Options | Change Password’ option when signed in, or go to https://account.axcrypt.net/, sign in, and use the Change Password option there.
The challenge with the new approach is that key sharing requires the insertion of a 3rd party. That is, your site sends an E-mail to the user. The problem is when your E-mail is blocked or spam-trapped by others. It can also be considered as a security risk by the recipient if they do not know who is AxCrypt.
So although your philosophy around encryption might be based on years of experience, you also need to understand what users want. I for one am not looking for government-level TS encryption but for an easy way to securely exchange some files with others. Nothing “Top Secret” or what I want to hide from governments.
I liked 1.7 because of that and have since struggled with 2.x (see my other post – updated and lost “Premium” even if I am registered till 2/2018).
To be honest, I have started to use WinZip 21.5 with the AES-256 encryption to share files. OK, it might not be “Type-1” level encryption but it suits my needs. I wonder how many others miss the simplicity of 1.7 and are ready to use a “less secure” product for menial tasks?
I do like AxCrypt but I believe that the path you are following although more secure, might not necessarily be what your user base wants. But then again, all I can only refer to the posts I read over here. Maybe I am part of the minority?
Thanks for your feedback! You are of course right that some users, like yourself, miss the 100% password-based way AxCrypt 1 works. We’d of course be happy to please as many users as possible. Unfortunately we have several challenges. One being limited resources, it takes developer and designer time to implement and maintain different features. The other being the fact that the multiple-password nature of AxCrypt version 1 actually leads to some data loss because of mistyped, forgotten passwords, or just confusion about what password was used when and where.
Most users will respond “well, that’s just up to each user to be responsible about”… until it’s your files that you suddenly realize you can’t access.
So, we do have to be careful about adding features and actually have to try to protect users from themselves sometimes. A surprising number of users do not fully realize the implications of using password based strong encryption until it’s too late. A forgotten or misplaces password is the same as permanently destroying all files encrypted with that password. There is no way back.
All this being said, we are indeed looking at ways to add password based sharing to the product – but we have some other things with higher priority – namely the Mac version and fully featured iOS and Android apps.
This is also why I’ve stuck with the older version. I often send files to relatives who have computer phobia (they won’t set up anything I haven’t already done for them on rare visits, or with TeamViewer). I use a base password they know, with small additions to change it up sometimes. I give them hints about the additions when needed and it works well.
Having the ability to use custom passwords at any time would be a useful “regression,” though I know the practicalities of creating software.
I’m now testing the new standalone version which doesn’t seem to affect right-click shell integration of the old version. That seems to be the best workaround for fans of the old version who want to keep both and don’t need all the high-end features. The only “problem” I see so far is I can’t visually tell which files (icons) have been encrypted with either version, so I just have to let the error message tell me.
Appending to my other post: I like the drag-drop speed of the new version, but I find the self-contained mode of the old version to be more intuitive. The new version adds an ethereal quality to the password process. I’ve done basic programming and understand why various changes are implemented, but I’m not in that field.
I think the general public will remain lazy or naive about computer security, as evidenced by posting personal photos to the whole planet on Facebook, etc. Relatively few people seem to care about their privacy settings and will send stuff in email that gets quite personal. When I tell distant family members they should encrypt such things, they give me blank stares or think it’s paranoid or pessimistic. Some people still leave their doors unlocked as if their personal defiance of risk will change the behavior of burglars (my family isn’t that stupid!).
Also, Mr. Damore at Google was right about (typical) women and their disinterest in tech. None of my girlfriends has had any real interest in file/email encryption. They think it means I’m “hiding” something and they can’t grasp the concept of general privacy to cover Murphy’s Law.
I assume the AcCrypt team is targeting an entirely different set of people, especially with the newer version.
AxCrypt 1.7 is no longer supported but it still works perfectly in Windows 10; until Microsoft break a dependency at which point the developer has said it will not be updated.
There is a feature suggestion for different passwords although it’s not desirable in terms of security and it’s incompatible with the present paradigm. If you’re distributing a file in version 2 you should never give out your password: use the share feature instead.
Those who want to use different passwords may have their wish granted although the comments on here suggest it may be a long time coming and it might be a premium feature.
I don’t think there’s an easy way of discriminating between v1/v2 files because they both have the same extension. The easiest method would be to have a specific folder or, if you have many files, introduce the numeral 1 or 2 to denote the version.
However I don’t see what the problem is:
- Version 2 opens both version 1 and 2 files as long as you know the password
- Version 1 only opens version 1 files assuming you know the password
If you want a different password then use version 1.
A solution would be to remove the AXX file association to version 1 and associate AXX with version 2.
This solution would open all AXX files in version 2. You’d still be able to encrypt using right click in version 1.
I wouldn’t call the encryption process “ethereal”; it’s been designed to be simple to use. The general public don’t take many active precautions but the majority of people do still care about their security – try reminding them of the famous “dick pic program“. Suddenly people became very concerned about their privacy when that analogy is used.
Stanley, your points are quite logical. It is what it is and it’s not bad per se.
The main draw of the older version is that it works directly on the files without a “container” that seems detached from them. You can feel like the files are out of your control when they appear in a discreet window. It’s probably more psychological/GUI-related than real.
But I also like the encryption process to be isolated from the Internet, though I know it’s supposed to be with AxCrypt. Someone not directly involved in the programming just can’t know what’s going on behind the scenes of any program. I’d never use a convenience-based password manager like LastPass, for example (they were hacked more than once).
Getting back to the new AxCrypt: I’ve rejected other password programs that use a similar method but it could be gotten used to and I like it better than other choices.
Both versions of AxCrypt can be used without ever connecting to ththe internet. Version 2 provides an Always Offline mode.
As for operating within a separate window you never need see AxCrypt 2, apart from the initial login, as you only need to double click a file to open it; no additional windows involved.
For your argument against the window to make sense you’d have to dislike version 1 because you always see the AxCrypt window: for encryption and then for decryption. Then you must remember to encrypt your file again once you’ve finished with it in version 1.
Both version of AxCrypt ar open source. You can freely download the source code for Windows to see “what’s going on”. No secrets in how it works.
If you don’t use a password manager then it’s all the more reason to use version 2 – using a base password with a few changes is incredibly insecure. Using multiple, strong passwords is a recipe for disaster as the likelihood of forgetting the passwords increase. You can always use offline password managers like KeePass or purchase a hardware password manager like MooltiPass. You can even write them down on paper as long as you keep it safe.
Oh, I know about Always Offline mode, it’s just that email is needed to setup v2, so it feels like the password could get transmitted somewhere. One must go on faith, I suppose. Same deal with various third party email apps on phones, etc.
There is no right or wrong here, just preferences and the feel of a program.
I will give the new version a serious run and probably run the old one along with it for aforementioned varying passwords.
Email is not needed to setup version 2 you’ll be happy to know.
Switch off your WiFi, start AxCrypt, enter a fake email (email@example.com) and then put in a password.
If you activate Always Offline mode you can safely reconnect to the internet and AxCrypt won’t connect.
You can use AxCrypt without having any internet access and without receiving any confirmation email and without transmitting any data to the server.