mickyj wrote:Hi, using the Microsoft DPAPI has other issues in that you (or any software you run) can decrypt it without even needing the encryption key (*) (as long as you're on the same computer and logged in as the same user) and you cannot decrypt later if your password is changed by the admin, you re-install Windows, change user (e.g. if exporting and importing), etc.
(*) You can add an additional encryption key, but that would be a key in the EXE, so it doesn't make it any more secure.
Yes, this being the Entropy argument, which I appreciate this still leaves the problem on what to use for this argument and how to secure it. As you say it is not possible to secure it but you can make it difficult to find.
A simple way of doing this would be to create the entropy/key on the fly, for example you could calculate a hash based on various pieces of data such as the type of password you are storing, the username associated with the password, the target (eg. server name), the profile name or GUID and possibly some other data preferably stored in a different location such as the registry.
This would mean that to decrypt someone would first need to locate and reverse engineer the code within SyncBack to discover the algorithm that creates the entropy/key and what data it uses. They could then recreate the entropy/key assuming that they have got all the required data. Once they have completed this not insignificant task and recreated the entropy then they could access any encrypted data in as you describe. It is also possible to decrypt this offline with third party software, assuming they also have the user’s windows password.
Of course all this is possible but it is a lot of work and certainly significantly more secure that the existing scheme.
I not sure that the password change or Windows reinstall are real issues as this just means that the user will need to re-enter the required passwords. They are going to have re-enter passwords for other applications anyway because Microsoft extensively uses DPAPI as I believe does various Google software and other vendors. They will of course have the same issues as you have described, and presumable they have decided that this was a more preferable option then performing the encryption themselves.
Again for importing and exporting, the simple solution would be to require the passwords to be re-entered if importing as a different user, I would hope that they would need to do this anyway as they would be using different usernames and passwords.
However as long as the encryption is significantly better than it is now I not practically worried how it is performed.
mickyj wrote:We've changed the encryption for the next release, but the same issue will exist in that you cannot stop decryption unless the user chooses the key themselves and secures that key. Having the user choose the key has issues in that it must be available to decrypt, either via prompting or giving access to the key file.
I look forward to trying this out, will it convert all stored passwords or only when they are manually re-entered.
Andrew.