I was looking into the Master Key feature to decide if it will be a good feature to use as we are in the process of increasing the security for our managed customer Firewalls, in a move to avoid leaking parts of the configuration and therefore vital infrastructure information, or worse customer's Private Keys as well as add an extra obstacle to an outside attack from API code execution or CLI/WebUI hacking attempt etc. I thought that since I made a little bit of reaserach, other people might find this information usefull if they are considering deploying this themselves.
The sensitive passwords and keys that are used on a Palo Alto Firewall, need to be saved in the config. To store them securely, it encrypts them using Salted MD5, which is a fast and convinient hashing algorithm, but definately not the safest in the crypto side of things. By adding a Master key, you temper the Salted MD5 algorithm and therefore make it even more difficult to bruteforce.
The biggest disadvantage of using a Master Key is that if you lose it, you have to factory reset the Firewall. There is no way around it. Another disadvantage is that it adds an extra "password" you have to keep in and never look at, but have to find once the time comes. The 3rd and biggest disadvantage for us specifically, seems to be that you can't use a non expiring master key, and you cannot disable the current one even if you know it. The key must have an expiry date, and if it expires, there is no way to gain access to the Firewall without Factory resetting it (if the key expires, the Firewall automatically reboots in maintenance mode, meaning it is non funtional). The last disadvantage is that it adds an extra thing that needs to be checked in changes of default behaviour and new versions as any other feature when you are considering upgrades etc.
A HA pair always has to have the same key (otherwise the config would appear different on each Firewall) and the same goes when you use Panorama, where all the managed Firewalls and the Panorama have to use the same key for the same reason.
MD5 is a very weak algorithm when used for encryption. Not only it is very easy to bruteforce (as it was built for speed) it also suffers from many vulnerabilities. Salted MD5, is covering this issue, as for any sensitive plain text string, it generates a new nonce string, and concates it, then hashes the new, bigger string, and saves the nonce string in a seperate secure database. This covers bruteforce attacks as now the string is too big to be predicted randomly, and is not going to be in any brute force wordlists. It also covers the vulnerabilities, as even if you decrypted the MD5 hash, you would have a string that includes the original string but also the nonce, and therefore it won't work.
To conclude, it seems that the added security a Master Key adds, does not give enough of an advantage compaired to the disadvantages it has in my opinion. This would not be the case, of course, if the sensitive data was using plain MD5, but since it doesn't, I think the risk of locking down a firewall is bigger than someone hacking deep enough through all the other layers to be able to uncover the private keys and passwords. So unless it is part of your compliance, the only remaining issue is the non-encrypted configuration file.
I hope this helps anyone considering deploying this into their Palos. Most information I have found around here and the Technical documentation, but I might be wrong in a thing or two. Please correct me if you find something inaccurate and share your ideas.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!