"This attack doesn't rely on a vulnerability in SAML 2.0. It's not a vulnerability in AWS/ADFS, nor in any other service or identity provider... Golden SAML is rather similar. It's not a vulnerability per se, but it gives attackers the ability to gain unauthorized access to any service in a federation (assuming it uses SAML, of course) with any privileges and to stay persistent in this environment in a stealthy manner."
Our security and identity teams have analyzed the claims in the blog post, and we believe that there are two primary claims: 1) that an attacker gaining access to the private signing key for a SAML Identity Provider may use that key to impersonate users, and 2) that this fact is a new disclosure.
The first claim is fundamental to how asymmetric cryptography works--messages between entities can be trusted because they are signed by a private key that is a secret. Any communication that relies on asymmetric cryptography relies on the sanctity of the private key, so we at Ping agree wholeheartedly that it must be kept secure under all circumstances.
We believe that this is a great opportunity to remind folks that protecting your private keys is essential to a public key system. There are many strong options for private key security, and it is critical that you understand the risks and make decisions that ensure the integrity of your identity infrastructure.
How to Properly Secure Keys
In general, implementing strong encryption is fairly straight-forward, and key management is just plain difficult. When implementing any public-key cryptographic system, some critical security processes must be implemented in order to ensure that key access is restricted to appropriate parties. These best practices include:
Adhere to the least privilege principle. Restricting access to only the minimal number of users who require it is simply common sense. In addition, be sure to put into place and stick to a clear, consistent process regarding who is allowed access and what happens when the individual no longer should have that access, such as when an employee leaves your company.
Use strong passphrases. The passphrase used in encrypting and using a private key is vital in protecting the key's integrity, and therefore a strong passphrase is paramount. Utilize strong passwords or passphrases that cannot be brute forced.
Periodically rotate the signing key. Practicing the capability to change your signing key not only reduces the potential damage that a breach can do, it also gives you the organizational capability to make a change when needed. The worst case scenario is to realize that your signing key has been compromised, only to find out that you don't have the ability to rotate it.
Take standard security precautions. You wouldn't unlock your safety deposit box and walk away, making it accessible for anyone who happens by. Follow the same routine with your computing environment: Don't expose a window with the key accessed when you leave your computer or other device. Also, follow other basic precautions such as not writing down passphrases and routinely monitoring and verifying that the above processes are still in place.
Utilize an HSM. Another method for protecting private keys is to use hardware security modules (HSMs). The HSM will hold the key material internally, and make it impossible to export the key for abuse. HSMs can greatly enhance key security, but will require architectural changes.
Public-key encryption is how we secure the Internet. It's how we secure websites, authentication, API's and a whole lot more. It takes work to secure our private keys, but by following the above best practices we can reasonably reduce the risk of key theft, and enjoy the benefits that federated identity provides. For more information, please contact us at email@example.com.