On October 19, researchers at the Ruhr-Universität Bochum announced a flaw in W3C XML Encryption.
The Axantum Password Manager Xecrets uses XML Encryption to store data on our servers.
This does not mean that Xecrets is vulnerable to attack.
The flaw only works in an attack against a server that knows the encryption key, and that can be queried about the result of attempted decryption of partially modified encrypted data. It is based on the fact that most implementations will happily decrypt the provided data using the secret key and then give different error messages if the decrypted data cannot be parsed as XML. These varying error messages can then be used to infer the original data, but not the actual encryption key.
Xecrets on the other hand never accepts encrypted XML in this way, nor does it know any users encryption except briefly during the users visit.
The XML Encryption flaw does not affect Xecrets.
Saturday, October 29, 2011
Tuesday, August 23, 2011
Why you should install programs to the default location
AxCrypt since version 1.7 does not have an option for the user to select installation directory during the installation process.
Some like to change the installation directory, typically to D: or E:, instead of the standard location typically on C: and on English versions of Windows in C:\Program Files\ or C:\Program Files (x86) . This is no longer directly possible from the installation graphical user interface of AxCrypt, and sometimes I get asked why.
The main reason is to avoid trouble, and minimize user options where I as a developer believe I can make a better informed choice. AxCrypt is built around many such decisions based on that premise, we choose the algorithms to use instead of providing you with a bewildering array of choices for example. This is simply because I as an encryption expert believe that I can make this choice better in at least 99,9% of the cases and thus spare all those users a strange question they don't really know how to or even want to answer.
With several millions of installations of AxCrypt, just about anything that can possibly go wrong has at least once or twice. More than twice I've had to help users with trouble caused by not understanding the interaction between Windows, the registry, fixed, removable and network drives and AxCrypt installation. AxCrypt has been installed to network drives, on remote VPN-mounted drives, on USB drives on CD's and just about anything you can imagine. Often it works, but sometimes it does not.
With AxCrypt 1.7 and the upgrade to use Windows Installer technology, a major motivation was increased robustness. Part of this is to minimize the risk of a user mistakenly making a bad choice, and the safest and easiest way to do this is to make the choice automatically. Thus the option to select installation a directory was removed from the installer graphical user interface. It's still there - but you need to know a bit about Window Installer in order to force it to do your bidding. The idea here is that any user skilled and knowledgeable enough to do this, is also skilled enough to make that decision with small or no risk of mistake. It's also very clear that if something does go wrong, it's something that needs to be fixed by the user and it does not wind up as an error report about AxCrypt.
The thing that cinched the decision to remove the installation directory was that I could not, try as I might, think of a single valid functional reason for changing it from the system default! Aesthetical, arguably yes. Functional, no. AxCrypt is tiny, has no performance impact on the drive it is installed to, and does not produce any growing data there. When we do change the installation directory, we also break some assumptions that are made by other software. We are also now responsible to ensure the right file system permissions for example, we might open a vector for a malware infection by installing to a directory that allows non-administrative rights to write to for example. Please note that AxCrypt, due to Windows design limitations, requires administrator elevation to install anyway. Other assumptions we break are the locations of 32-bit vs. 64-bit software in the various virtualized environments offered.
So, we wind up with a situation where I can find no situation where it's bad to install to the system default location, but several where it's bad to install to a different location. By making the intstallation easier for the user by removing one decision, we also make it safer and more robust. It's an easy call I think.
Finally, if you can provide me with a valid functional reason for not installing AxCrypt to the system default location, please do so and I will try to accomodate that reason in the best way I can think of.
Some like to change the installation directory, typically to D: or E:, instead of the standard location typically on C: and on English versions of Windows in C:\Program Files\ or C:\Program Files (x86) . This is no longer directly possible from the installation graphical user interface of AxCrypt, and sometimes I get asked why.
The main reason is to avoid trouble, and minimize user options where I as a developer believe I can make a better informed choice. AxCrypt is built around many such decisions based on that premise, we choose the algorithms to use instead of providing you with a bewildering array of choices for example. This is simply because I as an encryption expert believe that I can make this choice better in at least 99,9% of the cases and thus spare all those users a strange question they don't really know how to or even want to answer.
With several millions of installations of AxCrypt, just about anything that can possibly go wrong has at least once or twice. More than twice I've had to help users with trouble caused by not understanding the interaction between Windows, the registry, fixed, removable and network drives and AxCrypt installation. AxCrypt has been installed to network drives, on remote VPN-mounted drives, on USB drives on CD's and just about anything you can imagine. Often it works, but sometimes it does not.
With AxCrypt 1.7 and the upgrade to use Windows Installer technology, a major motivation was increased robustness. Part of this is to minimize the risk of a user mistakenly making a bad choice, and the safest and easiest way to do this is to make the choice automatically. Thus the option to select installation a directory was removed from the installer graphical user interface. It's still there - but you need to know a bit about Window Installer in order to force it to do your bidding. The idea here is that any user skilled and knowledgeable enough to do this, is also skilled enough to make that decision with small or no risk of mistake. It's also very clear that if something does go wrong, it's something that needs to be fixed by the user and it does not wind up as an error report about AxCrypt.
The thing that cinched the decision to remove the installation directory was that I could not, try as I might, think of a single valid functional reason for changing it from the system default! Aesthetical, arguably yes. Functional, no. AxCrypt is tiny, has no performance impact on the drive it is installed to, and does not produce any growing data there. When we do change the installation directory, we also break some assumptions that are made by other software. We are also now responsible to ensure the right file system permissions for example, we might open a vector for a malware infection by installing to a directory that allows non-administrative rights to write to for example. Please note that AxCrypt, due to Windows design limitations, requires administrator elevation to install anyway. Other assumptions we break are the locations of 32-bit vs. 64-bit software in the various virtualized environments offered.
So, we wind up with a situation where I can find no situation where it's bad to install to the system default location, but several where it's bad to install to a different location. By making the intstallation easier for the user by removing one decision, we also make it safer and more robust. It's an easy call I think.
Finally, if you can provide me with a valid functional reason for not installing AxCrypt to the system default location, please do so and I will try to accomodate that reason in the best way I can think of.
Friday, August 19, 2011
Concerning false positive reports about AxCrypt from antivirus software
From time to time I get user reports about warnings from antivirus software concerning either the installer or one or more of the components of AxCrypt.
This causes great trouble both for me and the user. The user often winds up with an inoperable software, and I get a lot of extra work defending myself against unfounded allegations by software companies that take no responsibility whatsoever. They will not guarantee anything about the 'security' they provide, and they will not in any way assume responsibility for harm caused by flagging clean software falsely as malicious. In a normal legal context this would be called slander, and be cause for legal action.
Some facts about AxCrypt and AxCrypt distributions. AxCrypt is always built completely from source, we do not statically or dynamically link to any third party code except those libraries that are part of the Visual Studio development environment and which come directly from Microsoft.
Distributions are not built in a developer PC, they are built in a special purpose build server which only do that. No other software is installed than that required to build our various softwares there. This server is stationed behind double firewalls, and is never used for any general purpose.
As part of the automated build process, each executable is digitally signed with an authenticode certificate, issued to 'Axantum Software AB'. The issuer of this certificate do certify that such an entity exists, and that it is in good standing. I have provided them with proofs of the companys registration etc. This signing process then ensures that any bits distributed with that signature is traceable back to me and my company, and we would thus potentially be legally accountable for any malware intentionally placed there.
To sum it up: There is no infection in a distribution from me which is digitally signed with my authenticode certificate in the name 'Axantum Software AB'.
It is a continuing effort trying to defend oneself as an independent developer against the so-called anti-virus companies unfounded allegations.
It is beyond belief that a serious anti-virus vendor still in 2011 will flag a properly digitally signed executable as malicious.
If I had the financial resources I would take strong legal action, since this causes sometimes hard or impossible to repair harm to my good standing, and that of my programs.
Please check that you have the properly digitally signed versions of both the installer and the executable components if you are in doubt, instructions on how to do this are found here.
Please help the community by reporting your findings as a false positive to your anti-virus vendor. Although the vendors empathically deny this, they do share signatures (or 'borrow' from each other). This is clearly evidenced by the fact that these false-positive situations usually come in swarms where I get a few reports first from one vendor, and then most of the other vendors follow suit. That can't be a coincidence...
This causes great trouble both for me and the user. The user often winds up with an inoperable software, and I get a lot of extra work defending myself against unfounded allegations by software companies that take no responsibility whatsoever. They will not guarantee anything about the 'security' they provide, and they will not in any way assume responsibility for harm caused by flagging clean software falsely as malicious. In a normal legal context this would be called slander, and be cause for legal action.
Some facts about AxCrypt and AxCrypt distributions. AxCrypt is always built completely from source, we do not statically or dynamically link to any third party code except those libraries that are part of the Visual Studio development environment and which come directly from Microsoft.
Distributions are not built in a developer PC, they are built in a special purpose build server which only do that. No other software is installed than that required to build our various softwares there. This server is stationed behind double firewalls, and is never used for any general purpose.
As part of the automated build process, each executable is digitally signed with an authenticode certificate, issued to 'Axantum Software AB'. The issuer of this certificate do certify that such an entity exists, and that it is in good standing. I have provided them with proofs of the companys registration etc. This signing process then ensures that any bits distributed with that signature is traceable back to me and my company, and we would thus potentially be legally accountable for any malware intentionally placed there.
To sum it up: There is no infection in a distribution from me which is digitally signed with my authenticode certificate in the name 'Axantum Software AB'.
It is a continuing effort trying to defend oneself as an independent developer against the so-called anti-virus companies unfounded allegations.
It is beyond belief that a serious anti-virus vendor still in 2011 will flag a properly digitally signed executable as malicious.
If I had the financial resources I would take strong legal action, since this causes sometimes hard or impossible to repair harm to my good standing, and that of my programs.
Please check that you have the properly digitally signed versions of both the installer and the executable components if you are in doubt, instructions on how to do this are found here.
Please help the community by reporting your findings as a false positive to your anti-virus vendor. Although the vendors empathically deny this, they do share signatures (or 'borrow' from each other). This is clearly evidenced by the fact that these false-positive situations usually come in swarms where I get a few reports first from one vendor, and then most of the other vendors follow suit. That can't be a coincidence...