Before posting, and to avoid disappointment, please read the following:

  • This forum is not for 2BrightSparks to provide technical support. It's primarily for users to help other users. Do not expect 2BrightSparks to answer any question posted to this forum.
  • If you find a bug in any of our software, please submit a support ticket. It does not matter if you are using our freeware, a beta version or you haven't yet purchased the software. We want to know about any and all bugs so we can fix them as soon as possible. We usually need more information and details from you to reproduce bugs and that is better done via a support ticket and not this forum.

SyncBack insecurely stores passwords.

For technical support visit https://support.2brightsparks.com/
Post Reply
ajs
Experienced
Experienced
Posts: 37
Joined: Sun Oct 25, 2009 8:57 pm

SyncBack insecurely stores passwords.

Post by ajs »

I have been entering various passwords into SyncBack over the last few weeks which made wonder how they are stored, so to reassure myself I decide to see if I could find where there are stored, hoping that I could not. So I was surprised that within a couple of minutes I had found where they stored. It was then concerning to find a direction relation in the way they are stored and the number of characters in the password. This made me wonder how strong the encryption was and within 10 to 15 minutes I had worked out the encryption method. I could now decode all the passwords stored within SyncBack. I then when to a different system and found that I could also decode all the passwords stored within SyncBack on that system too.

This is not good.

The encryption should be much stronger, the password should be mixed and padded with a significant amount of random data and lastly it should be less obvious where they are stored (having the word password on the same line as the encrypted password just makes to easy to find).

Andrew.
mickyj
2BrightSparks Staff
2BrightSparks Staff
Posts: 479
Joined: Mon Jan 05, 2004 6:51 pm

Re: SyncBack insecurely stores passwords.

Post by mickyj »

Hi, yes, the password encryption is not very strong nor has it ever been advertised as being strong. It's exactly the same password encryption that has been there since V1. It simply stops the passwords being clear text.

The problem with encrypting the passwords is that we must use a key, and that key must go in the EXE, so it's always going to be visible no matter what we do. We could ask the user for a key, but of course that needs to be stored somewhere, and that also needs to be encrypted, so back to square one. This means it makes no difference at all how strong the encryption is because you can get the key to decrypt it.

We can't ask the user for the key every time they run the program, but we can (and do) give the option of being prompted for a password, e.g. for FTP, so in that case no password is stored at all. That's obviously not practical for many people and it's viable in some cases, e.g. cloud.

You can of course secure access to your profile settings files, so if that directory itself is secure (using NTFS security) then nobody but you should have access to those files anyway and so cannot get to the encrypted password to begin with.

We've already put some thought into how to improve the encryption, but it all comes down the fact that it is simply impossible to securely encrypt anything when the key can be found by anyone determined enough. The only real option I can think of is letting the user decide on the key themselves and having it stored on some (physically) secure device. That is something we'll look at.

Thanks
ajs
Experienced
Experienced
Posts: 37
Joined: Sun Oct 25, 2009 8:57 pm

Re: SyncBack insecurely stores passwords.

Post by ajs »

mickyj wrote: Hi, yes, the password encryption is not very strong nor has it ever been advertised as being strong. It's exactly the same password encryption that has been there since V1. It simply stops the passwords being clear text.
True, but I think that it there is a reasonable expectation that it should take more than a few minutes to find and break.
mickyj wrote: The problem with encrypting the passwords is that we must use a key, and that key must go in the EXE, so it's always going to be visible no matter what we do. We could ask the user for a key, but of course that needs to be stored somewhere, and that also needs to be encrypted, so back to square one. This means it makes no difference at all how strong the encryption is because you can get the key to decrypt it.
I appreciate the issue with keys although there are ways around this issue which while not perfect would require significant effort to circumvent. If you want I can send you some suggestions.

This is not a problem that is exclusive to SyncBack and Microsoft provides DPAPI in Windows to address this issue. I have not used this myself but it looks to be fairly simple to use.
mickyj wrote: You can of course secure access to your profile settings files, so if that directory itself is secure (using NTFS security) then nobody but you should have access to those files anyway and so cannot get to the encrypted password to begin with.
True, but this it is generally not a good idea just to rely just on file system security. Unfortunately what tends to happen when something does not work is either security is removed or users are given privileges that they shouldn’t really have instead of actually fixing the issue, I have seen this more times than I care to remember.

Of course if you are unfortunate enough to have your system infected by malware then file system security is probably not going to help a lot. If the purpose of the malware is to collect sensitive information such as passwords then you do not want to make it too easy for it to succeed.

Andrew.
mickyj
2BrightSparks Staff
2BrightSparks Staff
Posts: 479
Joined: Mon Jan 05, 2004 6:51 pm

Re: SyncBack insecurely stores passwords.

Post by mickyj »

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.

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.

(*) 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.
ajs
Experienced
Experienced
Posts: 37
Joined: Sun Oct 25, 2009 8:57 pm

Re: SyncBack insecurely stores passwords.

Post by ajs »

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.
mickyj
2BrightSparks Staff
2BrightSparks Staff
Posts: 479
Joined: Mon Jan 05, 2004 6:51 pm

Re: SyncBack insecurely stores passwords.

Post by mickyj »

Hi, for the new encryption it will re-encrypt the password using the new method if it is changed. This isn't finalised as yet. We've also been pondering letting the user manage the password storage and retrieval themselves via scripting, however that's unlikely to be included in the next release.
ajs
Experienced
Experienced
Posts: 37
Joined: Sun Oct 25, 2009 8:57 pm

Re: SyncBack insecurely stores passwords.

Post by ajs »

I tried out V7.0.23.0 and unfortunately it is still very easy to break, it can be broken without knowing the key so the issues with secure storage of the key are irrelevant.

I can send you the details on the method I used but it is a fairly well known technique.

Andrew.
mickyj
2BrightSparks Staff
2BrightSparks Staff
Posts: 479
Joined: Mon Jan 05, 2004 6:51 pm

Re: SyncBack insecurely stores passwords.

Post by mickyj »

You can email support @2brightsparks.com, thanks.
raylward102
Newbie
Newbie
Posts: 1
Joined: Tue Jun 20, 2006 5:56 pm

Re: SyncBack insecurely stores passwords.

Post by raylward102 »

About these stored passwords; I'm looking to crack a password stored in syncback, in the hopes of finding my forgotten nas password.
I see where the hash values stored in the windows registry; any clues to how I decrypt them??
Post Reply