Windows 10: Bad design or bug? > Windows Filehistory settings

Hi,


I really don't get why everything has to pass through the feedback app that basically is a voting app. If this is how Microsoft takes input and evaluate what to work on, it's just horrible.


Anyways.

I just want to say that I think the setting setup regarding FileHistory is terrible. If you set up FileHistory to use a network share (like a NAS) as a backup location, the credentials are stored in the Windows Credential Manager Vault.

So if a ransom-ware enters my system and starts to encrypt all my data it basically just need to ask the Credential Manager to gain access to my network location for my FileHistory backup and then starts to encrypt my backup.

So the actual mechanism that is supposed to be used in such incidents (backup/restore) could potentially get compromised by its own flaw.


Why don't Microsoft store username and password inside the FileHistory application instead of using Windows Credential Manager that easily gains random accounts access to the entire backup share?


I don't get it. Can someone either tell me that this isn't a problem or show me how to do this differently... my backup is worthless if a ransom-ware finds its way in and starts to encrypt my backup.

:)

 

Bug > FileHistory/Credential Manager

Hi,

I don't know where to report this so please guide me.

I use FileHistory to back up all my Windows 10 PCs. Target backup location is a Synology NAS.

FileHistory uses the Credential Manager to log into the NAS and store the backup files. To me that's a huge problem and therefor a serious bug.

If I have to store credentials in Credential Manager for FileHistory to be able to store the backup everyone can access that backup data.

I should not be difficult for ransomeware to ask the Crendential Manager to browse the backup location and then encrypt it. It's pretty ironic that this is a valid scenario - you would think your FileHistory backup is where you restore all data from when it
has been encrypted - but that's not the case when the entire backup is encrypted.

I suggest that FileHistory uses it's own password vault instead of Windows Credential Manager. It's a huge flaw that the Credential Manager is being used for backup purpose and it defeats the purpose of having a secured backup when everyone can access the
backup files. The goal must be to only grant the backup client access to the backup location.

// peter

 

Bug: Windows 10 (build 14393.693) FileHistory when using hidden network share as backup destination

Okay. Seems like it's impossible to report a bug as a standard consumer. I don't wanna call Microsoft supporter or anything - I just want to say that I've found a bug.

It's pretty simple to reproduce.

1. You have to have a FileHistory running using a network location as backup destination.

2. Disconnect the backup share (like move the folder so FileHistory cannot find it anymore).

3. Setup a new network share but make the new share hidden (so you have to use $ to browse it)

4. Enter FileHistory configuration

5. Configure FileHistory to use the new share - browse your way in \\someserver\share$\

6. FileHistory now asks you if you want to move previous FileHistory to the new location. Click Yes.

7. FileHistory now fails. Note that when you have clicked Ok to the fail dialog the screen shows your new network backup destination. BUT there's no $ in the path. The FileHistory process is kind of halted and you cannot start it, because the new destination
does not exist (due to lack of $ in path).

8. To workaround, reproduce step 4-5 but in step 6 click No to move previous FileHistory.

9. Now the label has the new network path has the $ in its destination and the FileHistory is now working.

 

AMD FX OC'ers Club

That's what the auto setting will do since you're over the 1333 mark it jumps to the next step which isn't listed or officially supported I assume by that ram.

At this point though I would suggest dropping the multi one step or .5 so that we can get something stable and possibly take the heat issue out of the picture for now.