How can I prove that my software is secure for those who are interested to install it?

Question

I've written a password locker program for Microsoft Windows that encrypts its contents to the local machine. The only way to get the data out is with the encryption key the user knows. It uses the existing APIs in the OS to do the encryption.

I think it is secure and haven't written any backdoors in it, but I'm not getting any traction in distributing it because people don't trust that such an application isn't backdoored or securely encrypted.

What can I do to properly assure potential users that software is safe to use?

Answer 1

Prove is a strong word, and to be honest, it isn't the word you're looking for. What you really want is trust. You want users (or potential users, in this case) to trust that your software is secure enough for them use to protect their most sensitive data. There are several ways that you can do this.

• Open source the software. If users have the ability to review the source code, technical users are more likely to trust it, even if they never do review the source code, or in many cases are not even qualified to review the source code.

• Get an independent opinion from a qualified third-party. In other words, an audit that gives your software a clean bill of health.

• Professional presentation. If your software is on a website that looks like it was built by an amateur in his spare time, many people will ascibe to it that quality for all of its features, including security. If it's presented professionally, and looks to be backed by someone professional, correctly or not, people will think more highly of it. Such is psychology.

Ulimately, your biggest challenge is likely not in your offering itself, but in the competition. There is a lot of password manager software out there. Yours needs not only have to appear to be of high quality and secure, but at least as high quality and secure as theirs.

Answer 2

If you're serious about providing evidence of security (I would hesitate to use the word "proof"), then for the U.S. market, the NIST Cryptographic Module Validation Program (CMVP) is what you would need.

Be aware that getting the validation is a long, arduous, and expensive process, and may require significant investment and changes.

Also be aware that should you pass, you not only get free advertising by the U.S. Government, but your product is then eligible for purchase by agencies and companies required to use only FIPS 140-2 validated products.

Beyond that, an trusted and public third party audit would at least be some evidence; it'll cost you, but not nearly as much as getting it validated.

Answer 3

You will not be able to convince potential users that your password management app is secure and trustworthy without specifying enough detail of the architecture so users can make an informed decision.

First and foremost, you need to say what encryption algorithm is being used and the key strength. Hopefully, whatever that is, it is current and generally accepted as unbreakable against modern tactics.

You also need to speak to how your code handles the data post decryption. On the Windows platform you have the SecureString class which does a reasonably good job of avoiding keeping the unencrypted data from being stored in memory in plaintext and/or in memory longer than needed. It would not be good if users discover that if the app abends the data is in the crash dump file in plaintext.

Details of the penetration testing that has been done should be provided along with the details. Ideally, you should solicit competent penetration testers to beat up your app to reveal any weaknesses. What active defenses does the app have against common attack methods, e.g. will it detect and refuse to work if if any of the most common keylogger apps is running?

Lastly, don't forget the human element. What happens when the user forgets their key, or more likely if the app somehow corrupts or loses it's half? Is there a recovery feature? What is the process around that? If the data is simply gone with no way of getting it back, that isn't going to be embraced very well. If there is a process to recover the data, then that process needs to be scrutinized. It won't be good if I can recover encrypted data simply by finding the mother of my target on Facebook and knowing the maiden name.

Not trying to discourage, but it is very risky marketing an app of this nature. You will be competing with companies that have been in this business for decades and have the resources to hire the top minds in the world to develop and/or test the product.

Even if you could do that, you would still need a very tight legal disclaimer to protect yourself from liability. What if you woke up one morning and it is all over the news that encryption classes in .Net were exploited in a way that makes your app vulnerable? You may have done everything exactly right in your code and support processes, but you are dependent on class libraries outside of your direct control.