Clone settings and encryption
When I perform a "Clone Settings" operation I see that image protection fields are already filled.
That means that it's possible for ATIH2013 to **reverse** the password or that ATIH2013 stores it in plain text (which actually is even worse).
Please correct me if I'm wrong, but isn't it a security breach?
PS: now I realized, that otherwise it wouldn't be possible to create incremental backups, so there is no other option
PPS: but still, it provides an attack vector - now we can easily know the length of the password, which in case of short passwords decreases security a lot. Don't you think some irreversible password derivatives (hashes) as a key for the image/aes and empty fields after settings clone would be better?
Pat L,
yep, it's exactly the same password. So you can know the length of the password if you have access to the PC and Acronis
Perhaps, cloning should require knowing a password
I'm surprised people don't care of security ATIH provides. That's sad
But what is more sad is that dev team doesn't care either
The password itself is not stored in plain text, if you look in the task script file you will see the encoded result.
Have you checked what placeholders are shown if you only have a 2 character password or a 20 character one?
> The password itself is not stored in plain text, if you look in the task script file you will see the encoded result.
If ATIH may decrypt it then it's possible to decrypt it manually as well. It depends on how much you are ready to spend to extract the decryption key from the ATIH binary. Security rule of thumb - if you don't need the original password (and we don't need it in this case) - don't store it (either in plain text or encrypted), but store its hash.
> Have you checked what placeholders are shown if you only have a 2 character password or a 20 character one?
Yep. In the latest stable version the number of placeholders exactly matches the number of characters in my passwords (my former ones were 10 characters and now they are 18)
PS: encoded or encrypted?
I can see there could be two areas of thought on this matter.
1. Cloning by itself would imply copying exactly what is already there, so it might be reasonable to assume that the majority of users would also want their passwords copied across, after all why else would you clone a task?
2. As you point out, this could be a weak spot from a security point of view.
I'm not sure how robust a password protection many users expect from the Home version, I'm not sure it is a most used feature amongst users, not that that negates your comments, just an observation.
I'll have a look at ABR11.5 and see if that works the same way.
Don't forget if the task is exported, the password is carried over in the xml file.
1. I have cloned a task to **change** my password, because at the moment there is no another way. Or I would clone if I needed to create a similar task just in case to not bother myself specifying the same settings twice (in this case it's not a problem to set a new password).
2. Well, if it's possible to make more secured software - it makes sense to do so :-)
> Don't forget if the task is exported, the password is carried over in the xml file.
Actually I didn't know that. And I'll check what's available in that file.
Thank you :-)