No password when restoring encrypted backups in build 8029?
I encrypt my backups and in older versions of TI one has always been promted to type in the password if one change any setting in the backup. The same goes for restoring files, i am always promted to type the password. This is what i expect, encrypted backups should require a password to change settings, add files, remove files from the backup and of course require a password when restoring the backup.
With the new build 8029 the encryption function seems to be totally broken. I can freely change encrypted backups and restore encrypted backups without having to use any password. I see the same thing in backup jobs created in the previous build and backup jobs created in this new build.
Do anyone else see the same thing?
I would recommend raising a Support Case directly with Acronis Support for this issue, as this should be considered a high priority if encryption is being rendered ineffective for yourself, and potentially for other users upgrading to 8029.
I have not yet filed it, only submitted in-application feedback. I will uninstall TI2017 and then re-install it.
I have the 6116 NG version - I am prompted for credentials on all encrypted backups. However, once the backup has been "unlocked" with a password for that session, I am not prompted again for that particular backup. I'm only prompted in the app again (for the same backup if I close the GUI and re-open it.
This is pretty much the same behavior as I've seen with all versions though.
If you reboot and double click on an encrypted backup, does it not even prompt for credentilas then?
If you reboot and double click on an encrypted backup, does it not even prompt for credentilas then?
No, a reboot does not fix the issue. If i launch TI2017 after a reboot i can restore/change that backup without any password. However, if i double click on the .tib file in Explorer i am promted to type my password.
I see this on my two computers.
Roger, it sounds like your credentials are being stored / remembered somewhere on your system so would again recommend opening a Support Case for this issue as it doesn't seem like it should do this. I don't see this on my own systems.
Roger, it sounds like your credentials are being stored / remembered somewhere on your system so would again recommend opening a Support Case for this issue as it doesn't seem like it should do this. I don't see this on my own systems.
I opened a support case a couple of minutes ago. They could not solve it right now but will follow up with more details later.
Roger, thanks for doing that, please keep us posted on the outcome of the support case.
@Bobbo_3C0X1 , @Steve Smith:
Both of you say that you need to type the password and i have a question: When you must type the password, are we talking about from within TI2017 or after you have double clicked the .tib file in Explorer?
Roger, for me it is anytime that I try to click on an encrypted backup task, even to just look at the settings. All my encrypted backups are those stored in the Acronis Cloud, so I have never tried to double click on a password protected backup .TIB file, though any attempt to open the protected location still demands the password.
Roger
Same for me - screenshots of both scenarios. You sure you really have a password on it? Or does it just look like there's a password because you see greyed out stars there? Once a backup is configured and run, the password field is locked and may look like it has a password because of the grey stars. I'm guessing you may not actually have a password?
Maybe, the backups are from a previous setup where a password was created, but you RE-created the same backup using the same name, but no password was provided? Probably not, but can't explain the behavior you're seeing since I've never experiencied it.
All my encrypted backups are those stored in the Acronis Cloud
O.k, now i see that i was unclear in my original post. My issue happens only with local file and folders backups while cloud backups behave correctly as they always have done.
I see this issue only with local file and folders backups, iow backups stored as .tib files on an internal or external HDD.
@Bobbo_3C0X1, do you see this on local files and folders backups? Yes, i have passwords on my backups and the UI says ENCRYPTCED. See the attached image.
Here's what I see...
Here's what I see...
But what do you see if you close that dialog, select a local File and Folder backup, and click on the button Recover Files?
It has nothing to do what one can see in the Options dialog, it´s about what happens when trying to restore or add/remove files to a local Files and Folders backup.
When I log into the cloud, I also see this immediately.
As long as I'm navigating after providing the credentials, I don't have to enter a password again here. However, if I click on Home and it shows me the cloud backups again, if I click on the same one, or a new one, I get the password prompt again.
Roger, I have tested this on build 6116 (New Generation) and build 8029 and found the following:
Cloud backups with encryption - all work the same on both build versions, i.e. challenged for a password to view the settings or to open the backup location etc.
Local backups with encryption - this works differently depending on the build version.
Build 6116 - am challenged for a password to view or change task settings or to open the .TIB file in Explorer.
Build 8029 - no challenge for password to view or change task settings, but challenged for password when double-clicking on the encrypted .TIB file in Explorer.
I would recommend opening a Support Case for this issue with Acronis Support, quote this forum Topic for more information.
Here's what I see...But what do you see if you close that dialog, select a local File and Folder backup, and click on the button Recover Files?
It has nothing to do what one can see in the Options dialog, it´s about what happens when trying to restore or add/remove files to a local Files and Folders backup.
I must enter the password to unlock the backup job first. Once unlocked with the password, I can recover without putting in the password in again. I believe it holds teh password for as long as the console is still open. If I close the console and open it and try to access the backup, I have to enter the password again.
EDIT: Screenshot attached for reference on a console Cloud backup accessed from there too - what I see on my Cloud backups. All of my backups were created long ago though. I have not tried creating a new one, that was specifically built in the current version of NG or the latest standard version that came out last week.
Rob, looks like this behaviour is not consistent for build 8029.
I closed the ATIH 2017 GUI then waited a short time and reopened it again and wasn't asked for the password when I clicked on Options for the password protected task, yet I am every time for a Cloud task!
Is it the behavior in local and cloud backups, or just one or the other? I can test more later today with a new 8029 install on a VM.
Rob, the behaviour for Cloud backups looks to be as expected and consistent with earlier builds / versions.
It is the behaviour with local encrypted backups that is not consistent from my own limited testing.
With 6116 NGen I am asked for a password to view the task settings, but with 8029 I am not.
With both 6116 and 8029 I am asked for a password to open the .TIB file in Explorer.
To my way of thinking, encrypted backups whether to the Cloud or local drive should all behave the same.
The ability to explore the backup settings without providing a password is a potential security exposure though in reality someone still needs physical (or remote desktop) access to the system running ATIH 2017 build 8029.
Yes, Steve nailed it! Cloud backups=Needs password, Local Files and Folders backup=No need for password for restore nor changing the backup by adding/removing target files from within TI2017 interface. :)
Looking forward to your results Rob! :)
Confirmed the same issue in 8029 for a local backup by me as well.
- I am NOT prompted for the password to edit the task or do a recovery from it when using the Acronis GUI
- I am prompted for the password to open the backup when double clicking on the .tib file when navigating to the backup via Windows file Explorer.
Filing feedback now.
Rob, are you just submitting Feedback or are you opening a Support Case for this security issue?
Note: Support Case [02928684] Security exposure - password protected tasks exposed - has been submitted by email by myself.
Thanks Steve, I didn't submit a ticket - I will try to later though. The more it's logged, the better.
Thanks Rob, I cross referenced to this forum post so they can see the investigation we have given to this issue.
Thanks for confirming you results! :)
It seems that what we see now is how it is supposed to work from now on. This is the answer i got:
The case reference number is 02926482.
During the course of our chat conversation, I checked with my respective management team and would like to inform you that it is the designed behavior of the update build of the Acronis True Image 2017. When you will explore the encrypted backup within the Acronis application it will not ask for the password. However, while exploring the backup image with in the destination drive it will ask for the password.
Personally i prefer the old way, being promted to type the password when restoring and when making changes to the actual backup job. With this new behaviour i get the "does-my-password-protection-really-work-if-my-.tib-file-get´s-in-another-peoples-hand-on-another-computer?" feeling.
Roger, thanks for posting your response, I will do the same when I get one from my email submitted case. I agree that I prefer the old way of being prompted for the password as this leaves the data exposed should someone else have access to the computer without my knowledge. They may reply that physical security of the system is not their problem!
Hmmm. This new logic seems flawed.
But yet, it still asks for the password to edit a cloud backup on the same pc so why the different behavior there?
And any user on the pc that can launch the app can edit or view any backup task now. I will test that one. If you're a home or small business using True Image, you may be doing user or data backups per person with a different passwords so that those people can see their own content only by providing their unique password, separately. Yet now this may be a way for each person to see what's in the other persons backup, unless it prompts for non admin accounts still? I won't be able to test until much later this evening. It's 6am here.
To me the most troubling thing about this is that it means that ATI is somehow storing the password in a way that it can be read by the application and used to decrypt the backup. I'd thought these passwords were one-way keys and were not stored. I'm much more concerned about the underlying issue of password storage and decryption abaility than I am about whether or not the console prompts me. If ATI can read the stored password, somebody else could too.
Edit: I also think that a security change of this nature is far too large of a change in behavior for it to not be listed in the change log.
Philip, please open a Support Case for this issue (as I have already) and submit this as a high priority issue quoting this forum topic and also quoting case numbers 02928684 and 02926482 already submitted by myself and Roger.
Steve, I have submitted case 02929648 to this effect.
Completed my test...
I created a brand new user account and attempted to launch Acronis - failed (needs admin access)
I added the user to "backup operators" only - failed (needs admin access).
I added the user to "administrators" - SUCCESS (in a bad way).
As expected, anyone who can launch Acronis can recover a file from any backup on the same machine. The good news is that it requires administrator access to launch Acronis. Essentially an administrator can access any file on the PC as well (give themself access righs or take ownership) so this is not the worse thing in that regard. However, even then, they could not gain access to an encrypted file that someone was trying to protect with their own file level encryption.
This behavior skirts the file level protection by giving all administrators access to any backups on the files, making it less secure in this regard.
Thanks Rob & Philip for your updates. Had an email exchange with Faraheem yesterday evening where he had done all his testing on ATIH 2017 NG (build 6116) and couldn't reproduce the problem! Have made it very clear that this is a problem introduced by build 8029 and is easy to recreate.
I have done some testings with my two computers, A and B. If i create an encrypted backup on computer A and then move it to computer B i am promted to type the password. The same goes for creating a backup on computer B and moving it to computer A.
The thing that concerned me when i discovered this is exact what Philip Manwaring writes about in post #29 in this thread. The question that popped up in my head was "If TI can read the password, is it really safe to upload backup files to the cloud? If my TI can read it there is a possibility that another copy of TI can read it as well, without having access to my password."
I feel that this new feature has a layer of unsecurity tied to it.
Hello All,
Thank you for sharing your observations. We are currently investigating the issue on our side.
Regards,
Slava
Slava, please could you check case # 02929648 for this issue. I was contacted yesterday and asked for a Process Monitor log, AcronisInfo and screen shots for a problem which my contact Faraheem previously advised he was able to recreate, as can anyone with build 8029.
My reply was to ask that the developers recreate this for themselves and collect whatever information they require.
Thank you for sharing your observations. We are currently investigating the issue on our side.
FYI, please also note that it is possible to change iow add files or remove files checked for a backup without having to type the password. I did send a video to Swati to show that it is possible. The video is recorded on a fresh booted computer and it´s the first time i launch TI2017#8029 during that session. (Case 02926482)
I get the feeling that no one at Acronis really knows how this new password feature is supposed to work. I get conflicting answers. One says that a restore from within the UI of TI2017#8029 never requires a password. The other person says that the only time i don´t need to type the password is when i make changes to the backup job.
The true as of today is that the password is never needed in the UI of TI2017#8029.
I see two risks with this new behaviour:
1. Some one else with accsess can destroy an encrypted backup job without knowing the password.
2. That the user that creates the encrypted backup can freely do changes to the backup job and when the time passes that person may have forgotten the password when a restore is needed on a new computer since the password created one year ago never has been used and the memory has never been refreshed.
Roger, a further risk is on any computer with multiple users where the encrypted backup can also be accessed by anyone having Administrator access without being challenged for the password.
Hello All,
The issue will be fixed in the next update for the software.
Below is the list of cases when the problem does not reproduce and the password is prompted as expected:
1) accessing backups from Acronis Bootable Media, both Linux and WinPE versions, Acronis Startup Recovery Manager
2) accessing backups from a different computer
3) accessing backups by double-clicking .tib files in Windows File Explorer
4) accessing backups that have been removed and added back to the list
5) accessing backups in Acronis Cloud using a web browser
For users of Acronis True Image 2017 New Generation: Acronis Active Protection's self-defence module is not affected by the issue and any changes to backup files and settings outside of Acronis software graphical interface are disallowed and are blocked automatically.
Steve, thank you for the case number. I have left a corresponding note in the ticket.
Regards,
Slava
Thanks for the update Slava.
The issue will be fixed in the next update for the software.
When will this update be released?
Personally i think this issue is very serious and am expecting an update to be released as soon as possible. The nature of the issue is enough to withdraw build #8029 completely. I wonder how this issue even passed the QC.
Hello Roger,
The estimates are two-three weeks. Depending on the results of the currently running tests, the update may be delayed.
Regards,
Slava
Please keep me in the loop on this fix as well.
I posted this yesterday: 129325: Encryption Feature Appears to Have A Vulnerability
Steve then replied and filled me in on the details that Acronis is working on a solution.
After reading the above discussion, my concern is if a thief steals your computer and knows the old backdoor access method for Administrator level, then that thief essentially has your data....totally un-encrypted at his disposal...just by opening the TI2017 app. Not a good thing.
b/r,
Trub
So, if the thief can boot your system and launch Acronis on it, your data is already compromised. If they can't boot the os, they won't be able to launch Acronis on that machine so I wouldn't worry about that. But if they can launch the OS they have your data then too. It's easy to reset the admin password when you have physical access... or create a new admin account with a blank password and take ownership of the other profiles.
still agree the bug needs to be fixed though! Just don't think that situation is something to be concerned with specifically.