As a result of an interesting (if you're nerdy ) discussion going on in this thread, I started experimenting with definition files, specifically how the user-supplied encryption password is stored.

PROBLEM
Although Reflect encrypts the user-supplied encryption password before storing it in the definition file, a given password always encrypts to the same ciphertext. I understand that users are expected to safeguard their definition files, but that doesn't mean this can't be improved.

THREATS
A consistent relationship between a given plaintext and the generated ciphertext creates two possible threats:
- An attacker could compute a rainbow table, a one-time effort that could then be used to look up plaintext passwords from the ciphertext version stored in definition files. Any plaintext passwords whose length and composition were within the "scope" of the rainbow table would be vulnerable to compromise.
- An attacker could mount a chosen plaintext attack in an attempt to derive the key/mechanism that Reflect uses to encrypt/decrypt these stored passwords. ALL passwords encrypted in definition files would be vulnerable to compromise, regardless of the length or composition of the original plaintext.

OPPORTUNITY
I believe my proposed solution below completely eliminates the rainbow table threat and significantly reduces the key derivation threat, while maintaining compatibility with existing definition files and seemingly requiring minimal effort to implement.

SOLUTION
I propose that Macrium expand their definition file XML by giving the existing <password> tag a new "Type" value, perhaps named "EncryptwithSalt". Whenever the user supplied a new encryption password, Reflect would append a randomly generated, but fixed-length salt to it, and generate the ciphertext to be stored in the definition file from that combined string. When the password was needed, Reflect would decrypt that ciphertext and then remove the fixed-length number of characters from the end of the resulting plaintext to recover the user-supplied password. The purpose of the new "Type" value is to maintain backward compatibility with existing definition files, i.e. for any definition file whose <password> tag has its Type set to the current "Encrypt", Reflect would not perform this truncation after decrypting the stored password.

The end result is that a given user-supplied password will encrypt to different ciphertexts in different definition files, thereby thwarting rainbow table-style attacks, and the combination of a) this salt resulting in variable ciphertext for a given password and b) never actually writing the salt anywhere, makes it more difficult to derive Reflect's encryption key through chosen plaintext attacks. In fact for additional security, it may be worth Reflect steganographically hiding the salt when it is computed, using techniques already employed for its encryption key.

DRAWBACK
The only drawback I can see is that definition files that use this new <password> Type value would not be usable by older versions of Reflect, but I don't consider that a significant issue.

Another approach is to write the salt into the headers at the beginning of the backup file to allow for different salts during password changes like VeraCrypt.

If no salt is found in the header of the backup file, the Reflect program can revert to the old method of password authentication to maintain backward compatibility.

That wouldn't protect the password stored in the definition file from a rainbow table attack. Using salt stored in the headers of the backup files would allow the same password to result in different AES keys being used for different backup files. That ALSO has value, since it would mean that if someone somehow brute forced AES-128+ to find the key for one of your backups, they would not then be able to decrypt other backups that you had protected with the same password -- but brute forcing your backup files is a different threat model from brute forcing your definition file.  It's also worth noting that an AES-128 key already represents a large enough pool of possibilities that brute forcing it would take a completely impractical amount of time, even for a massive supercomputer/super-GPU array. By comparison, all possible password combinations up to the length that the overwhelming majority of people use would be faster to brute force by several orders of magnitude, as can be proven by playing with this site.  So the greater need would be to salt the password, not the AES key.  But of course there's absolutely no reason you couldn't do both, and it's entirely possible that Macrium's AES implementation already does salt the AES key; I don't know either way.  But they do NOT currently salt the password.

TL;DR: The encrypted backup file and the encrypted password stored in your definition file are two completely separate ciphertexts, and consequently adding protection to one does nothing for the other.

I would hope that Reflect uses a random number generator for creating the encryption key independent of the salt value used in the one-way hash algorithm that is used for the password.

Your concern regarding rainbow tables and the salt being unencrypted has not raised any security flags for both TrueCrypt audit and VeraCrypt audits.
Clearly, the PKCS-5 PRF mitigates this issue with number iterations performed through the hash algorithm along with the salt to make creating rainbow tables for a single password a very large number.

Perhaps Reflect could implement Argon2 for their password hashing.

VeraCrypt is not a useful comparison.  VeraCrypt doesn't need to store your password anywhere for automatic use, whereas Reflect does because it needs to be able to perform scheduled backups without prompting the user to enter the encryption password each time.  VeraCrypt has no need for the protection I'm requesting here, unless of course it does offer some way to unlock container files without any manually supplied input from the user. If it does, then I would be very curious to see whether the same password used for different container files results in different "auto-unlock" ciphertexts for each container.  I would imagine that would be the case, because otherwise this rainbow table vulnerability WOULD have been flagged in the audits you're referring to.  And if VeraCrypt's auto-unlock feature does generate different encipherments of the same password, then it would have the exact security design that I'm requesting for Reflect.  If on the other hand VeraCrypt does NOT offer auto-unlock, then the fact that nothing about this was flagged in an audit doesn't matter because VeraCrypt isn't offering a feature that Reflect is. (The other possibility even if VeraCrypt does offer auto-unlock is that it uses the same design as BitLocker does to achieve this feature, namely adding an additional "protector" to the container file being auto-unlocked rather than enciphering the password itself.  That too would avoid the rainbow table vulnerability, but that's a longer discussion, and that design wouldn't work for Reflect anyway since it requires the encrypted data to exist first, whereas Reflect needs to be able to generate new files encrypted according to a previously supplied password.)

You're still confusing how the AES key is generated in order to protect the data being backed up with how the enciphered version of the password is generated in order to store it for automatic use.

I am not a cryptographer, however there are people that are better qualified than me that can create a solution to increase the password security to make creating rainbow tables impracticable which is the goal you are wanting to achieve based on your test results.

I would expect that a attacker would reverse engineer the Reflect password software module to determine the method used to create the rainbow tables. Therefore to make this task impracticable is the goal of using a salt and number of iterations of the hash algorithm.

The location of the salt value being stored in the header of the backup file is matter of backward compatibility and you will not have the XML file(s) available when using the Reflect Rescue CD/DVD/USB.

Attempting to discover the key that Reflect uses for encrypting these passwords is indeed a potential attack, and Macrium has said that they hide that key using steganography, but of course it does have to exist somewhere for Reflect to be able to decrypt that stored password, so unless the user wants to not store their password at all and is instead willing to manually type it for every backup, that risk can only be minimized, never eliminated.  That's simply a convenience vs. security tradeoff that people have to make. But if the user opts for convenience, the only question is how HARD you want to make it to brute force, and my point with this thread is that there's a fairly easy way to make that much harder. I have no knowledge of what Macrium does to protect the main key they use for encrypting these passwords.

The salt value would be irrelevant in a Rescue situation because you would be there to provide the password rather than needing Reflect to retrieve it automatically -- except in the automatic restore scenario, but that DOES require the definition file, so you would be covered either way. And once again, storing the password salt in the backup file is not a sensible design. You can't even assume that a backup file will EXIST to store it in when Reflect generates the encrypted version of your password in the definition file, since you can of course create a definition file before you run your first backup at all -- so how could you store the salt value for that password in the backup file?  I've already explained how backward compatibility can be maintained without even dealing with the backup files. You're still confusing your threat models and protections.

The hash uses all three values to determine that you entered the correct password.
Salt + number of iterations of hash algorithm + clear-text password = cipher-text to validate password.

Hence, you would need to have the salt value in order for Reflect to correctly hash the clear-text password provided by the user to validate the password. Without the salt value, the password algorithm will get a different cipher-text password.

"You can't even assume that a backup file will EXIST to store it in when Reflect generates the encrypted version of your password in the definition file, since you can of course create a definition file before you run your first backup at all -- so how could you store the salt value for that password in the backup file?"

Point taken.

You're talking about a different salt.  The "salt" I'm proposing would be to allow the encrypted and stored version of the same password to be different ciphertexts in different people's definition files.  Yes, in order to make sure those different variations always decrypt back to the same originally supplied password (which would THEN be used to calculate the AES key using a completely different and wholly independent mechanism), the salt would have to be known for the decryption -- which is why it needs to be stored in the definition file (UPDATE: Maybe not.  See update to first post.)  That encrypted version of the user-supplied password is the only item I'm trying to protect.  When the password is manually entered, then the salt I'm talking about isn't needed because Reflect doesn't need to decrypt a ciphertext version of that password, since you just supplied the cleartext password directly.

Also, the password is not being hashed in the operation that I'm discussing here.  A hash is a one-way function, so if Reflect were storing a password hash in the definition file, there would be no way for it to recover the password you actually supplied, which means Reflect would be unable to use that password to encrypt backups.  A stored hash would allow Reflect to tell you whether a password you manually supplied LATER matched one that you had supplied previously, but that's not useful for Reflect's purposes. The purpose of the definition file isn't to authenticate future manually entered passwords. It's to allow Reflect to use that password in order to do something autonomously.

Please take a step back and carefully reread everything I've posted thus far.  I promise you I'm right on this.  I completely get that security can be tough to understand properly and even tougher to design properly, but you are going all over the map here and talking about very different things, some of which are completely unrelated to the operation in question.  But for what it's worth, you did get it exactly right when you said that I am trying "to increase the password security to make creating rainbow tables impracticable, which is the goal you are wanting to achieve based on your test results."

I will leave this discussion since we are not understanding each other clearly. I concede your point about the salt cannot be stored in the backup file since no backups have been created yet when you setup the backup definition.

However, I believe there is merit in what I was trying to accomplish with one-way hash algorithms from my experience using various encryption software. I leave this matter to Macrium to ponder and perhaps Macrium will come-up with an alternate solution to strengthen their password algorithm.