pfSense

Currently ACB associates backups with a host by a hash of its SSH public key, which is known as the "Device Key" in ACB.

If a user has exposed the SSH service on a device to an untrusted network, a malicious client on that untrusted network could probe the SSH service and determine the hash of the public key. With that public key they can calculate the ACB device key. The malicious client could then take actions on the ACB content for that device key, such as listing backups, deleting backups, creating new entries with malicious reason strings, etc. If the user has chosen a weak encryption key, then the content of the backups could also be compromised.

The best practice has always been to protect firewall services such as SSH and the GUI and never expose them directly to untrusted networks.

Issue #16015 added a method for the user to change the device key, this takes it a step farther:

• Changes default behavior to use the new randomized key method rather than SSH.
• For users with ACB disabled, use the new method as well.
• Only keep the legacy key active if ACB is enabled, to not violate POLA.
• Inform users still using a "legacy" style SSH public key-based device key that the best practice is to change to a new key.

One of the risks associated with this is a potential XSS in the backup list, this is already covered by a separate issue: #15927

If a user does not have SSH enabled or they do not expose SSH to an untrusted network (e.g. WAN) then there is no concern, but the best practice is still to change the device key to a randomized value.

See also: Internal Issue 18131