Don’t Forget the Back-End!

Over the years we’ve spent lots of time worrying about the security characteristics of various types of authentication tokens, with broad consensus that static passwords reek. And we’ve put lots of thought into the processes we use to vet users’ identity and to bind tokens to users. And of course we’ve put lots of effort into lifecycle management and processes to disable authenticators when they are no longer needed.

NIST Special Publication 800-63-1 is a pretty good exploration of topics like those mentioned above, and describes how they contribute to an authentication event’s level of assurance. However, I don’t see any mention of back-end authentication systems in the NIST document.

We’ve progressed far enough that the authentication back-end systems have now become attractive attack points. Why should attackers try to steal someone’s smart card if they can steal the certificate authority’s certificate signing key? Why should attackers try to replay a SAML assertion if they can steal the IdP’s assertion signing key? Why should attackers try to steal someone’s OTP token if they can steal all the tokens’ shared secrets from the back-end OTP verification system?

Even if attackers are unable to steal OTP tokens’ secrets from a company’s back-end OTP verification system, they may be able to steal the token secrets from the token supplier, or some third party contracted to inexpensively program OTP tokens. Did RSA ever confirm our conjecture that their customers’ OTP token secrets were stolen in a recent breach?

Even if attackers are unable to actually steal secrets and/or keys (thank heavens for hardware security modules), they may be able to compromise the back-end servers to maliciously exercise the secrets and/or keys, thereby generating what appear to be valid certificates, assertions, or OTP values.

Even if attackers are unable to maliciously exercise a back-end server’s secrets and/or keys, they may be able to inject malware onto a RADIUS, LDAP, or OTP server that returns a success status for every authentication, bind, or verification request.

Don’t forget the back-end! Are your back-end authentication servers sufficiently hardened? Are they in secure network enclaves? Are your secrets and keys protected by HSMs? Are single-factor admin passwords used to control access to your multi-factor authentication systems? Are you confident that your virtual machine hypervisor doesn't open attack channels to your hosted authentication servers? Could compromised workstations used for remote administration introduce malware to your authentication servers?

Yikes! How do we adequately protect the back-end? And how should we include back-end considerations in determining authentication level of assurance?