Forum Replies Created
-
AuthorPosts
-
Hello Andrew,
Thanks for the info. We should definitely investigate that. Off the top of my head, I could imagine that this would happen a launch of emacs has a pattern similar to the following:
emacs.exe blabla.txt launches another process, perhaps xx_emacs.exe blabla.txt . Or, if you have an emacs process running, and launching another causes the new instance to just tell the old instance to open the file.
The point is that what AxCrypt does is:
– Decrypt the file to a temp location.
– Launch the associated application.
– If AxCrypt sees the started app, it’ll assume it’s done with the file when it exists and thus re-encrypt (if necessary) and then wipe the file in the temp location.The secondary emacs would then try to open a file that no longer exists.
I do not know the behavior of Emacs, but could something like this be the root cause?
Hello Dirk,
Thank you for your input. I’ll be writing a longer text on Authentication vs. Encryption, but very briefly. Authentication is about proving to a system that you are who you claim to be, i.e. to provide evidence to support the claim. In the physical world, this might be a passport for example. Encryption is not really about proving anything, it’s about either knowing or not knowing an encryption key. Either you know it, or you don’t. Two-factor authentication is about providing stronger evidence to support your identity claim. With encryption, that doesn’t make sense, because there is no identity claim involved, it’s just about either posessing or not posessing the decryption key.
All that being said, we’re thinking about the possibility of some hybrid system if we can figure something out that makes sense both from a security point of view, and from a user point of view. Our main issue here is that we’d like to keep AxCrypt to be about *real* security, not *perceived* . I.e. we don’t want to add features that many users believes increases security, while in fact it does not.
A timeout for the sign in is in the works, by popular demand. You can follow it here: https://bitbucket.org/axantum/axcrypt-net/issues/208/sign-out-automatically-on-a-set-time .
Once again – thank you!
Hello Dave,
The bad news is that we have not yet implemented a full command line with AxCrypt 2. There is still a command line, but it is a little limited and it’s really only intended for use by the Windows Explorer integration shell extension. You can actually encrypt files, if you sign in manually. We don’t have the command line documentation ready, but the switch is now –encrypt although I don’t think we actually support wild cards IIRC. Note the double-dash. As mentioned, no documentation – but you can check the source!
https://bitbucket.org/axantum/axcrypt-net/src/
Axantum.AxCrypt.Core/CommandLine.cs
The good news part 1 is that you might not need to, since we now have the feature called ‘Secured Folders’ where AxCrypt will monitor a folder for new files, and you can encrypt them all with a single click.
The good news part 2 is that we will make a real command line version of AxCrypt 2 which will be more capable and easier to use than version 1 – but we’re not there quite yet. Also, anyone with reasonable C# skills can integrate AxCrypt into any .NET program, or roll their own custom versions.
Hello Mike!
Welcome to Premium :-)
– You’ll be reminded both via email and via a notification in the application when your Premium is about to expire. We will not charge you automatically though. If you let it expire, nothing ‘bad’ really happens. You’ll have full access to all your encrypted files (but new or updated files will use 128-bit) and if you use the password manager, you can read all but not update.
– That’s a feature that’s not yet implemented, but we’ll have a ‘upgrade 128 to 256’ bit function in the not too far distant future. I’ve added an issue in our tracker for this: https://bitbucket.org/axantum/axcrypt-net/issues/202/function-to-convert-128-bit-to-256-bit . Right now, you’ll have to decrypt and re-encrypt (that’s actually what needs to be done anyway, but we can automate it).
Hello Rob,
One common cause for this kind of behavior is that Windows has locked the installer resource due to for example another update or installation that requires a reboot.
Try to shut down (and install updates if asked) and restart the computer.
This is entirely beyond the control of AxCrypt, it’s a fundamental problem with the Windows Installer technology used by Microsoft.
Hello Rickie!
Thank you for taking the time to ask, since this is obviously something we need to get better at explaining.
I’ll try to be brief:
- It does not ask you for a password before encrypting, because you already gave AxCrypt your password when you “signed in”. This password is kept around for as long as you’re still “signed in”, and used for both encryption and…
- …it just opens the locked file just as pretty as you please because of the same reason – the password is kept around as long as you’re “signed in”. This is one of the main improvements of AxCrpyt 2 – it makes it so much easier to work with!
The green icon appears because the file is really encrypted, and renamed to end with “.axx” and that’s when Windows will display the stylized green padlock icon.
You’ll now think – but where’s the protection if anyone can open the file?
The answer is that AxCrypt will sign you out automatically when the screen saver goes active, you log out of Windows or the computer goes to sleep.
And you never, never ever leave your computer logged on to windows in a place where other untrusted people have access to it, do you? If you do, there’s really no need to bother with encryption at all. It might make you feel better, but it doesn’t provide an ounce of real protection.
It’s a little like airport security confiscating your empty water bottle. “Look, we’re preventing people from getting inside with a container that can be filled with bad stuff!”, but… on the other side of security I can buy a new water bottle, empty it or drink the water – and now I have my empty container! It’s a totally meaningless action in the name of “security”.
Encrypting your files, regardless of mechanism, and then leaving your computer accessible to anyone who walks by is also a pretty meaningless action. Why? Because, as someone said, if you let someone else have full access to your computer, it’s no longer your computer. It’s that persons computer, and they can do pretty much anything they like. In this case it probably means quickly installing a readymade keylogger kit to pick up your password and send it so the person can open the files he or she also copied or sent out during the time they had access to your computer.
Security is also only as strong as the weakest link in the chain. It doesn’t matter how hard you’ve encrypted your files, if you are not using your computer in a generally safe way.
With AxCrypt 2, you get both convenient usage (which means it’s more likely you’ll actually encrypt your stuff) and real security as long as you follow some simple and general guidelines for reasonably safe computer use.
Hello Carl,
I’m sorry to hear that you’re unhappy with version 2 of AxCrypt. You can in fact use AxCrypt 2 entirely offline if you so wish.
We do not support different passwords for personal use though, as we consider this to be a behavioral security risk. Please see http://www.axcrypt.net/blog/use-of-different-passwords/ .
A lot of thought and effort has gone into making AxCrypt 2 as secure as AxCrypt 1, or more so, and at the same time being even easier to use. We realize this implies some changes in how you use AxCrypt, but we ask you to keep an open mind and really try it out.
We’re also listening to the feedback, and we’ve done a number of modifications based on comments from both new and especially existing users of AxCrypt 1. Among other things we’ve made the new main user interface be less prominent, so use from Windows Explorer is very similar to the old version. We’ve also enabled full offline mode for users who insist. There are many more minor changes made as well as a result of the input we’ve received.
So, please do continue to let us know what you think! We are listening!
However, improvements that we’ve made that affect the actual security of the application we’re much less likely to consider. The “multiple passwords for a single user” is one of them. Sorry!
AxCrypt is an advanced encryption tool for users who just want it to work, without having to take security related decisions themselves such as algorithms and other technical parameters. We simply think that we can make better informed decisions than most of our users, who also in most part do not want even to be confronted with the choice.
AxCrypt is thus an opinionated software. We have an opinion about how it should work, and what is secure and less secure behavior. The “multiple passwords for a single user” is such an issue. Of course, we’re open to reasoning about it, if you find a flaw in our reasoning – do let us know and we’ll discuss it!
Hello Robert,
Your question makes eminent sense, and I’d refrain from using encryption products that limit password length to 16 characters for AES-128 etc. It shows a fundamental lack of understanding of the technology, and I’d suspect that such a product does not properly implement other encryption functions.
I can’t write a really long response, but properly implemented software a password based key derivation function of some kind. AxCrypt uses a standard function called PBKDF2 with SHA512.
The fact of the matter is that in practice a typed password does not use 8 bits/character (even if the characters is stored using 8 bits, there’s a bit of effective waste there since not all 256 positions typically represent printable/typable characters). ASCII which you refer to for example is a 7-bit code, stored in 8 bits most commonly, and even so not all 128 positions are used by printable characters.
A 44 character password, provided that is not a sentence or set of words but rather really is a long password with a good mix of characters is very good, and is likely to give you more than 128 bits of effective strength, but perhaps not as much as 256 (it depends on how the password is constructed).
To determine the effective strength of the password:
- Assume the attacker knows the *principle* but not the detail of your password. I.e., assume the attacker is yourself, who knows everything about how you choose passwords – *except* the actual password.
- Estimate the number of possible passwords by taking the number of possibilities for each position or group times each other. Call this hopefully very big number N.
- Calculate log N / log 2. This will give you the number of effective bits.
Example: I chose a password that is 8 characters long, with completely random characters upper and lower case a-z. Each position can have 26 + 26 possibilities = 52 per position. So, N = 26 * 26 * … * 26 (8 times), i.e. 26^8.
N = 53459728531456.
log(53459728531456) / log(2) = approximately 45.6, i.e. approximately 47 bits.
This is a very weak password…
September 6, 2016 at 08:54 in reply to: Will I lose access to my files if my AxCrypt ID account is hacked? #4023Hello Vale,
Yes, accounts can be ‘hacked’ – although, what this typically means is that your password has been guessed or otherwise leaked. Very, very seldom are user accounts really ‘hacked’ in the sense that a vulnerability is exploited. Servers are however sometimes hacked, which sometimes is the cause of leaks of password databases (although just as often it’s an inside job).
No, if someone actually would gain access to your email for example, and then use that access to perform a password *reset*, that will not affect your files. It will, temporarily, cause your sign in to AxCrypt to fail if you’re online of course (since the ‘hacker’ has succeed in *resetting* your password). In this situation, you’ll just *reset* the password again to the original (after ensuring the ‘hacker ‘ no longer has access to your email of course, by changing the password to that service).
The files as such are not at all affected by any kind of change to the online account in this case. Also, with AxCrypt, regardless it’s always possible to open the files with the password originally used to encrypt them.
Your files are safe and usable for you, but not the ‘hacker’, if such person would succeed in actually *resetting* the password of your AxCrypt ID online.
A ‘hacker’ cannot *change* the password to your AxCrypt ID without actually knowing the original. This is not possible to bypass by hacking our server either, since it’s not a regular password change where we just check that the old password is known. We actually encrypt data on our server (using AxCrypt of course) using your password. So, to *change* password, this must be decrypted, and this requires to really know the old password before it’s possible to set a new one.
There is thus a definitive difference between *changing* and *resetting* AxCrypt ID online passwords. *resetting* can be done by a ‘hacker’ with access to your email. *changing* requires to really know the old password.
Hello marco,
Right now we don’t support recursive (i.e. following all subfolders of a folder) decryption of many files.
However, we do support windows explorer selection of many files.
I suggest you use the ‘search’ function of Windows Explorer, perhaps “*.axx” will suffice, or “*-jpg.axx”. Then you can select all with Ctrl-A, right-click and select AxCrypt | Decrypt .
Hello Caleb!
Thank you for your input. At this time we don’t support that option, but we may in the future – by popular demand, although our opinion remains that it generally tends to decrease security rather than increase it.
See http://www.axcrypt.net/blog/leaving-computer-axcrypt/ for the related discussion of why we think so.
Very briefly – if you leave your computer unattended, even with AxCrypt closed and signed out, all bets are off anyway. You should never trust a computer that someone has had access to with the same permission as yourself. It may happen because you leave it with Windows signed in, or because you are the victim of malware or an exploit that potentially gives the attacker the same permissions. In either case, the result is the same – a possibly compromised system that should be restored from original media.
Minor update on this issue. Checking the .NET source it turns out that this error stems from Windows returning an error code WSAEPROVIDERFAILEDINIT on a call to WSAStartup().
This in turn can be caused by various issues in the system environment, most often according to a Google search on the issue:
– Insufficient permissions (non-standard settings to UAC or setting ‘Run as Administrator’ for the executable might cause this for example).
– Not having the system variable ‘SYSTEMROOT’ set. This should seldom be a problem for AxCrypt which runs in an interactive session most of the time. Of course if files have moved and SYSTEMROOT is no longer correct, this could also cause the problem. Apparently this is how the appropriate dll is located. Among other things, mswsock.dll must be found.
– Broken or partially broken TCP/IP stack in the system.The fix being implemented will just silently ignore this error, and the requested functionality lost unfortunately – until I get more information or can reproduce the issue locally.
Hello again B Scache,
We’ll investigate the –offline issue at the same time, it may be that we’re still trying to initialize something even if we don’t actually do any network calls.
Thank you for the information!
Hello B Scache and Andrew,
We’ve investigated the issue further, and it’s a very simple call that fails. Microsoft does not document any conditions under which it may fail like this. Since this statement is executed everytime AxCrypt is started (if not in always offline-mode), and we only have these 2 reports it’s surely something specific in your respective systems that is unusual. Not necessarily wrong, just unusual. Of course we should AxCrypt should handle this to, the point here is that it’s not a general problem.
It would be good to understand what circumstances lead to this, in order to fix it as well as we could, so I’ll persist in asking: Do you have any idea or suggestions about something which in any way is out of the ordinary as regards to the networking in your environment? VPN software, extra network cards or USB networks, some unusual configuration, anything?
In the meantime we’ve logged an issue for this, and if nothing else comes up so we can understand this issue, we’ll issue a bug-fix that simply does not use this feature if it is broken like this. It does mean that if this is the fix that will be made, that we’ll silently ignore the error and disable the functionality which is not vital, but sub-optimal. We’d rather understand it and work around it properly.
You can follow the issue here: https://bitbucket.org/axantum/axcrypt-net/issues/200/socketexception-the-requested-service .
Hello James,
Yes, you can of course downgrade to AxCrypt 1.7 and thus keep being compatible with the old iOS app. Please be aware that files encrypted with the new AxCrypt 2 software are not possible to open with AxCrypt 1 or the iOS app – so for these files if any you’ll have to decrypt and then re-encrypt with version 1.
I suggest you download the stand-alone version of AxCrypt 2 (it’s fully featured, just without the Windows Explorer integration) since it can co-exist with an installed version of AxCrypt 1.
The current plan is to release the iOS app later this year.
-
AuthorPosts
