[FEATURE REQUEST] Password protect to FFS

[netnet]

hi
I really enjoy using the software
I think it is necessary to make an option to protect FFS when running the software by password.
This is because if you allow the software to log into a Google Drive account, for example, a malicious user can exploit it for negative purposes, which means I think a password is needed to ensure that only someone licensed can access the software and from there access the drives and cloud accounts.
Thank you

[RelayUK]

I've recently been doing a security review of my systems and thought about this sort of thing. I'd be more worried about the fact that someone had access to your system than the app (and all your other apps like email, browser cached passwords, etc.). To get access to the app they'd have got passed your login security, or they have physical access to your disks (stolen pc for example), in which case, again I'd be more worried about encrypting the disks.
There's one issue not raised, which is the security level of the passwords stored on disk by FFS, I've not looked at that, but if it's on an encrypted disk and secured by a login (I use a bio-secure login) then it should be okay.
I also looked at my backups (NAS/Cloud) to make sure they're password and encryption protected.

[netnet]

In any case, I think that must be given to the user to protect the FFS login using a password.
This will close a significant security breach to Google Drive or any cloud service and even a local drive that is accessed through a password.

[xCSxXenon]

Proper security measures would include locking the machine when there are no authorized users around. If there are multiple users that must use the computer, then create multiple user accounts.

[netnet]

I think it's very important and necessary to have an option to enable FFS after password verification to secure the accounts and drives linked to FFS.
This is very common in software that has access to accounts and drives such as FFS, even though the computer user's account also has a password.
Thank you

[netnet]

I think adding this feature will not be too difficult but it will add a high level of security to the software

[xCSxXenon]

Well it's open source, so it shouldn't take you long to implement. Make sure it doesn't store the password in plain-text!

[netnet]

okay
I don't know how to do it alone ...
of course, the password should be properly encrypted and not saved in plain text

[xCSxXenon]

Oh, there also needs to be a way to submit a password reset! But then users would have to register by email or some other unique identifier, which if that gets compromised, then the password for FFS is useless anyway...Hmmm, I guess users can just nuke their FFS and completely reinstall and reconfigure if they forget yet another password. Are you going to also implement a self-reset system, or will there be a master password, or an admin-only reset, or just complete reinstall? And what about background automatic syncing? Proper system security and permissions are sounding better and better.
But let's say I am a malicious being. I'll just see what drive contains your Google Drive data to perform my devious actions, they'll get synced to the cloud on the next run. Your "security" breach scenario is only applicable after many layers of failed security.

[JDB]

Hello FreeFileSyncers,

I am also concerned about the security of the target files, not with cloud backup, but rather with external HDDs, because they are so easy to swipe (steal).

I can't speak for Zenju, but my guess is that modifying FFS to perform file encryption and user/password management within the application would NOT be and easy "fix", and could move it closer toward a Microsoft Bloatware Model.

For directory based cloud sharing services such as DropBox and Google Drive, I think it might be possible to use Microsoft Bitlocker in the Mapped directories. (I am not very familiar with it, but I'll bet it's a pain in the neck.) Beware of locking into Microsoft products. They didn't call it Bit"LOCKER" by accident. They tend to lure you in, then drop support and then remove all documentation from their website hoping that you'll either upgrade or forgive them for their screw-ups.

Back to encryption of a whole drive such as an external USB disk. I would like to write to directories within an encrypted drive. Correct me if I am wrong, but I believe that Microsft EFS (Encrypted File System) is no longer supported. Even if it is supported, I'll bet that it's an administrative nightmare and I wouldn't use it anyway. Is it true that they went to great lengths to make it possible to crack open by an Administrator? What if the Administrator is a Hacker? (NO THANKS)

There's another drive encryption utility called VeraCrypt, but support for that is also tenuous, since it originated from an abandoned project called TrueCrypt. However it seems to have a strong following on SourceForge, which adds some credibility as a long term solution. Since it's open source, it's been compiled with GCC and supported on Linux, Windows, and (I believe) also MacOS/X.

(DISCLAIMER: I am not affiliated with the VeraCrypt project in any way, just evaluating it as a method to encrypt target drives used by FFS. I am not affiliated with FFS either, just a HAPPY user.)

One big PLUS about VeraCrypt is that the encrypted drive can be mounted and accessed independently from the backup program (FFS). It also runs on multiple OS's as long as the underlying file system type can be mounted (e.g. FAT32, NTFS, etc). Therefore, recovery would not have to be performed through FFS in an emergency situation, as long as the VeraCrypt client is installed on the system performing the recovery.

I actually think it's a bad idea to give your drive / volume passwords to another program (even one as trustworthy as FFS) to utilize. I would rather perform password entry, mount, and unmount commands OUTSIDE of FFS. Then all that FFS needs to know is the drive letter or mount point.

I am going to try VeraCrypt with a 4 TB external drive over the next week or two. My backup will consist of about 700,000 files ranging in size from 1 KB to 20 GB. Total data size will be 1 TB. I am also going to set the "Thread Count" to 1 for both input and output. I've had problems using higher numbers due to USB data corruption under heavy load. (that's a whole other issue not FFS related but due to crappy controllers in most external USB3 drives.)

I already know that performance will be "somewhat" degraded due to cpu intensive encryption. Will the loss of speed be a reasonable price to pay for security? I'll post my results here. Note, I won't be contucting an exhaustive test of performance under different workloads. It will be simple, I can guarantee that much!

I hope this turns out to be a reasonable solution.

[JDB]

FYI, for the encrypted drive test, the target drive will have 2 partitions:

1. A small UN-Encrypted FAT or FAT32 partition containing several installable distros of Veracrypt, perhaps the past 3 versions for Linux, Windows, and MacOS/X. Also to include the "free" version of FFS and a 30-day trial versions of BeyondCompare for Windows, Linux, and Mac (by https://www.scootersoftware.com/ ). This would be to assist recovery onto a system that has no software installed.

2. The remainder of the disk will be formatted by VeraCrypt and mounted to a drive letter onto which to perform the backup (um, er, I mean synchronization.)

[netnet]

I don't understand why the people here make a big deal of it

Very simple, just make a password option when entering the software. And also encrypt the file where the passwords are stored accessing drives as well as Google Drive, etc. that's it.

It maintains access to drives and Google Drive.

If someone forgets the password, they can reinstall the software, then they will re-enter the Google Drive accounts and drives, and that's it. Simple and easy.

[JDB]

@netnet -- Unfortunately it's really not as simple as you describe. One of the beauties of FFS is that the synchronized target is accessible outside the program. By implementing proprietary encryption within the program, it would become more like a walled-in backup solution rather than an open synchronization program. My suggestion to use a disk volume encryption system allows FFS to continue what it does best, and to remain open. Solutions like BitLocker, EFS (defunct), and VeraCrypt only protect data while at rest. As long as the volumes or file directories are mounted and accessible, they can be read and written by users on the system, INCLUDING the Google Drive client. Then the readable content gets replicated by Google Drive to the cloud. I realize that this is NOT what you want.

On the other hand, if the destination files are stored encrypted by the FFS software, then to read those files, you would need to rely entirely upon a restore function (a.k.a. "Save As...." from within FFS.) The destination directory would become useless outside the program, but Google Cloud would replicate encrypted files instead of the original content. Within FFS on the local machine, comparisons would become unmanageable because you would lose the date stamps and the length would be altered. In order to compare files to see if they need to be refreshed on the destination, you'd have to restore everything to a temporary directory and replace the timestamps with the original. Then compare, then do your copies, then delete the temporary. It would completely interfere with the functionality of FFS that works so well today as-is, and it would introduce a lot of instability.

I think that you are looking for a backup system that uses a per-file or per-directory Zip format. Perhaps there is one out there, sorry that I don't know of a good one.

I don't blame you for not trusting Google.

_JDB

[Plerry]

This topic is starting to mix two different topics/aspects:

- A password for entering/opening FFS or the for opening/entering the file/network locations to be included in the FFS sync, and how to safely store or deal with these passwords (e.g. via encryption thereof)
For file/network location access you may simply use the Windows Credential Manager. I suppose Mac and Linux have equivalents of this. (assuming you find that safe enough).
Like implied here by xCSxXenon, best practice is to use a dedicated user account for your backup tasks, and only give write (and possibly even read) rights for your backup location to that user account. Again, user credentials for that account for the file/network locations involved in the sync may be stored in the Credential Manager

- Encryption of file/data contents.
For this latter aspect, see e.g. here.

[netnet]

All what I asked is just add a password option when starting the software.
That's all.

Everyone admits this improves data security.

My argument is very simple: for a password protected drives, you can login without a password using FFS. Adding password protection to FFS solves this problem.

For all the ideas of a special user account, etc.:
this makes it difficult while working,
that need to be constantly transferred from one account to one account, etc.

Maybe don't use FFS but do a manual backup by manually comparing each file...

The same as you realize that FFS saves you this manual work, so look to save time and energy.

[JDB]

I apologize for not understanding the question fully and expanding this into a broader topic. I don't usually try to be a pompous buffoon, but sometimes it turns out that way! Sorry, netnet.

I'll add my results with VeraCrypt to the other post that Plerry referenced.

-John

[xCSxXenon]

Bitlocker is a fantastic method for encryption. Microsoft has offered it for a long time and can't just yank support for it. It has a key that will decrypt it. As long as Windows is accessible, the drive can be unlocked. VeraCrpyt(TrueCrpyt) is great as well! It is easy to use and can avoid encrypting a full drive and rather use smaller folders. Adding a password to FFS for security is like putting your car keys in a safe so your friends don't steal them. There are steps to take before such scenario that negates the reason for it

[netnet]

Thanks for the tips on how to encrypt, but that's not what I asked for.

I only ask the developers for one thing: password protection when entering the software.

Any ideas to do: another user account, use BitLocker, etc. You can say the same about not protecting an encrypted drive or Google Drive without a password. So it's not about FFS.

Like having a password on Google Drive, or a password on encrypted drive, I ask that it remain as I use FFS. Just add an option that will log in to the software with a password. that's it.

[xCSxXenon]

You also said everyone agrees this improves data security, I don't agree with that at all.
Again, it's open source, add the feature if it's invaluable that you don't implement proper security on the below layers

[netnet]

There are many users who think that adding a password to the software will improve FFS security.

There is no problem that there are those who disagree with it, so I suggested doing it as an option, and those who do not want it should not use it.

But this option of password protection will exist for anyone who wants it.

[WilliAmaya]

Feature request: Password when open "FreeFileSync" or for each task

[kwill]

Feature request: Password when open "FreeFileSync" or for each task

Is there a channel for [FEATURE REQUEST]? This function is what is limiting my use.