Password protection of Macrium images


Author
Message
Blimpyboy
Blimpyboy
New Member
New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)
Group: Forum Members
Posts: 10, Visits: 26
The 'AdvancedSettings' area allows me to protect backup images.  I've checked current documentation and searched the forum, but can't find much in-depth background on this feature.  I'd like to know how secure this makes backed-up images, especially when taking images off-site.  If a password-protected image were to go astray (get lost, stolen etc!) and fall into the hands of someone who undertood the contents to be a Macrium Reflect image, is the data useless to them without the key used for password protection?  Does the key simply unlock the image container or is the data itself encrypted as the data is written to the backup image file?  How long should the password be?  Should I really be using AES encryption?  Is there a penalty to pay in terms of backup creation time?  Yep, so many questions ;-)

Perhaps there is a formal Macrium document explaining all of this, but I can't find one - I'll be delighted to read one of it exists.  This has just become much more relevant  in the UK/Europe in view of GDPR!

Thanks for any light you might be able to shed.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)
Group: Forum Members
Posts: 4.5K, Visits: 34K
If you have a password and don’t use encryption, then the data is still stored in the clear, so it would be accessible to anyone who parsed the Reflect file.  Theoretically, the Reflect application could even be hacked to simply skip the password prompt and allow access to the data in this scenario.  That's why you should absolutely use AES encryption, in fact I have a Wish List thread asking encryption to be made the default and for the “no encryption” option to be removed, or at least come with a warning if it has to be kept for compatibility. A backup that has a password but no encryption imparts a false sense of security to the user, which can be very dangerous, and I can't think of a single use case in 2018 for having a password but no encryption.  CPUs for roughly a decade now have had hardware acceleration for AES encryption/decryption operations, so there's little to no performance penalty for enabling it, but even if there were, that consideration should pale in comparison to the risk of losing sensitive data, especially for backups involving other people's sensitive data.  Companies in certain industries that store sensitive data about their clients are required to notify those clients whenever the company has reason to believe the clients' data may have been compromised.  Loss of an unencrypted backup would certainly qualify as such an event, and could potentially require the company to notify ALL of their past, current, and prospective future clients.  However, those companies are typically NOT required to notify anyone if the lost data was encrypted, since in that case the lost data isn't assumed to be compromised -- so whether or not the company's backups are encrypted can drastically affect their reputation after such a loss, and of course their customers/clients susceptibility to identity theft, etc.  There’s simply no good reason not to use encryption in a scenario like this, in fact it's so easy nowadays that NOT using it would probably expose whoever configured the backups that way to gross negligence lawsuits.

When you DO use encryption, neither Reflect nor anything else can access your data without knowing the password/key — so let’s talk about that.  If you lose control of an encrypted file, then assuming you haven’t also lost control of the password of course, the safety of your lost data depends almost entirely on password length and complexity.  An attacker might try some easy guesses first, such as words in the dictionary, so make sure your password isn't that simple, but after those are exhausted, they switch to brute forcing the password. Technically the attacker could try brute forcing the AES key directly, but even with a 128-bit key, that would take on the order of hundreds of millions of years.  So your goal is to make sure the password is ALSO impractically long to brute force. There’s a useful interactive tool here that puts some actual time figures on this concept and shows the impact of adding length and/or complexity: https://www.grc.com/haystack.htm

As you can see, adding even a bit of length increases time to brute force dramatically, which is why even a simple long password is better than a short, gnarly, impossible-to-remember password. For passwords that are vulnerable to offline attacks, as in this case, I typically use at least 16 characters. Easy ways to add length without making a password difficult to remember and type would include adding a phone number, a few zip codes or significant dates, some easy pattern of characters, etc. Again, a password doesn’t need to LOOK scary to be secure. If an attacker is brute forcing, then length is the only thing that really matters. In another thread around here I explained why a password of 50 zeroes in a row is far more secure than something like “1icYZe0X60XAig”.
Edited 25 May 2018 5:10 PM by jphughan
Reflecting Mirror
Reflecting Mirror
New Member
New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)New Member (43 reputation)
Group: Forum Members
Posts: 25, Visits: 83
I mention the following in case it pertains to the newly General Data Protection Regulation.

Most companies and users will setup Reflect backup schedules. When using a Reflect schedule with password, the Reflect backup definition file contains the hashed password. FYI, the same password used for different backups will result in the same encrypted text shown in each of the definition files.

If someone within the company or a hacker steals the backup definition file(s) and reverse engineers Reflect's hash algorithm, they can access the encrypted backups.

The important point is to secure access to the backup definition files.

You can read Macrium's reply to this issue at the link below.

Salt encryption passwords before storing in definition file


Edited 25 May 2018 5:52 PM by Reflecting Mirror
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)Macrium Evangelist (6.7K reputation)
Group: Forum Members
Posts: 4.5K, Visits: 34K
^ To be precise, the definition file does not store a HASHED password; it stored an ENCRYPTED password. If a hash were stored, then Reflect would not be able to recover the original password to use it to perform the encryption during scheduled backups, since a hash is not a reversible function. Storing hashes works when you just need to determine whether a password provided later matches the password that was provided previously. That’s why the BACKUPS contain a hash of the encryption password to ensure that the decrypted data will be correct. But hashes do NOT work when you actually need to know what the password IS, not just whether it matches some subsequently provided input.

The password stored in the definition file is encrypted with a symmetric key built into Reflect, which Macrium says they take steps to hide steganographically. An attacker would have to reverse engineer Reflect to find that key in order to derive the original password from the encrypted version saved in a definition file, not reverse engineer some hash function. There's no purpose to reverse engineering has functions.  Their algorithms are public, but that still does not allow anyone to recover the original source data from a hash.

My suggestion to salt passwords before encrypting them addresses a different risk.  Currently, Reflect always encrypts the same password the same way, which means that if an attacker saw two definition files with the same encrypted password, they would know that those definition files used the same original password.  Adding a ransom salt to the original password before encrypting it would remove that possibility -- but a salt offers no protection against an attacker obtaining the original KEY that was used for the encryption.  Nothing would.

There is always a certain amount of unavoidable risk if you decide to store a password somewhere. If that is unacceptable, then you’ll have to be present to manually enter the password every time you want to run a backup.
Edited 25 May 2018 6:41 PM by jphughan
Blimpyboy
Blimpyboy
New Member
New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)New Member (26 reputation)
Group: Forum Members
Posts: 10, Visits: 26
jphughan - 25 May 2018 3:35 PM
If you have a password and don’t use encryption, then the data is still stored in the clear, so it would be accessible to anyone who parsed the Reflect file.  Theoretically, the Reflect application could even be hacked to simply skip the password prompt and allow access to the data in this scenario.  That's why you should absolutely use AES encryption, in fact I have a Wish List thread asking encryption to be made the default and for the “no encryption” option to be removed, or at least come with a warning if it has to be kept for compatibility. A backup that has a password but no encryption imparts a false sense of security to the user, which can be very dangerous, and I can't think of a single use case in 2018 for having a password but no encryption.  CPUs for roughly a decade now have had hardware acceleration for AES encryption/decryption operations, so there's little to no performance penalty for enabling it, but even if there were, that consideration should pale in comparison to the risk of losing sensitive data, especially for backups involving other people's sensitive data.  Companies in certain industries that store sensitive data about their clients are required to notify those clients whenever the company has reason to believe the clients' data may have been compromised.  Loss of an unencrypted backup would certainly qualify as such an event, and could potentially require the company to notify ALL of their past, current, and prospective future clients.  However, those companies are typically NOT required to notify anyone if the lost data was encrypted, since in that case the lost data isn't assumed to be compromised -- so whether or not the company's backups are encrypted can drastically affect their reputation after such a loss, and of course their customers/clients susceptibility to identity theft, etc.  There’s simply no good reason not to use encryption in a scenario like this, in fact it's so easy nowadays that NOT using it would probably expose whoever configured the backups that way to gross negligence lawsuits.

When you DO use encryption, neither Reflect nor anything else can access your data without knowing the password/key — so let’s talk about that.  If you lose control of an encrypted file, then assuming you haven’t also lost control of the password of course, the safety of your lost data depends almost entirely on password length and complexity.  An attacker might try some easy guesses first, such as words in the dictionary, so make sure your password isn't that simple, but after those are exhausted, they switch to brute forcing the password. Technically the attacker could try brute forcing the AES key directly, but even with a 128-bit key, that would take on the order of hundreds of millions of years.  So your goal is to make sure the password is ALSO impractically long to brute force. There’s a useful interactive tool here that puts some actual time figures on this concept and shows the impact of adding length and/or complexity: https://www.grc.com/haystack.htm

As you can see, adding even a bit of length increases time to brute force dramatically, which is why even a simple long password is better than a short, gnarly, impossible-to-remember password. For passwords that are vulnerable to offline attacks, as in this case, I typically use at least 16 characters. Easy ways to add length without making a password difficult to remember and type would include adding a phone number, a few zip codes or significant dates, some easy pattern of characters, etc. Again, a password doesn’t need to LOOK scary to be secure. If an attacker is brute forcing, then length is the only thing that really matters. In another thread around here I explained why a password of 50 zeroes in a row is far more secure than something like “1icYZe0X60XAig”.

A big thank you for taking the time to contruct such a clear explanation, it's much appreciated.  I have read & re-read your response to ensure I clearly understand all that you say - also the Gibson link which is great background.  I'm so glad I created the original post, probably one of the most important security questions I've asked in quite a while!
peter09aug2016
peter09aug2016
Junior Member
Junior Member (54 reputation)Junior Member (54 reputation)Junior Member (54 reputation)Junior Member (54 reputation)Junior Member (54 reputation)Junior Member (54 reputation)Junior Member (54 reputation)Junior Member (54 reputation)Junior Member (54 reputation)
Group: Forum Members
Posts: 42, Visits: 135

(1) I tried on a 40 GB File& Folder job: compared with and without setting a 1-character-password.

I opened the resulting hexaid.mrbak in Notepad.exe and could read the contents in plain text on both the unprotected and the password-protected hexaid.mrbak. I verified that for mounting the password is indeed required, or not required.

(2) AES requires an 8-character password, but I'm happy with a short password and weak encryption.

(Sometimes, to compare, on a zip file, I do password-protect it for the reason that malware sniffers do not go into the zip file, A password-protected zip is at least protected by the internal encryption algorithm).

+edits: a mentioning the 8-character password requirement for AES
+edit: mentioned performing a test, and  reading mrbak with text editor.

+Actually it was not a 40 GB File& Folder job, I run the test F&F backup on a folder with just one text file of 50 KB of known contents, with no compression, and could read its contents at the beginning of the mrbak in clear, password-protected or not.

Edited 13 January 2019 7:50 PM by peter09aug2016
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search