1.5Authentication and Digital Signatures (MFA, PKI, SSL/TLS)

"How do you prove someone really is who they claim to be?" — the cryptography from the previous section is the foundation for this authentication question. Authentication based on a password alone is weak against leaks and reuse, and public-key cryptography alone cannot prove that a given public key genuinely belongs to its claimed owner. This section covers how authentication only reaches practical strength by combining multiple mechanisms, from both the multi-factor-authentication side and the digital-signature/PKI side.

1.5.1Multi-factor and biometric authentication

• Multi-factor authentication (MFA) combines two or more different types from knowledge factors (e.g. a password), possession factors (e.g. an IC card or smartphone), and biometric factors (e.g. fingerprint, iris). Using two factors of the same type does not make it multi-factor (e.g., a password plus a secret question are both knowledge factors, so this is not MFA). The value is that if one factor leaks, the others still provide defense.
• Biometric authentication verifies identity via a physical characteristic such as a fingerprint, iris, or vein pattern. The false rejection rate (FRR) (rejecting the genuine person) and the false acceptance rate (FAR) (accepting an impostor) are in a tradeoff relationship — tightening one loosens the other. It carries no risk of being lost or forgotten, but since biometric data cannot be changed, the impact of a leak is severe.

1.5.2Digital signatures, PKI, challenge-response, and SSL/TLS

• A digital signature is the hash of the data, encrypted with the sender's private key. The recipient decrypts it with the sender's public key and compares it against a freshly computed hash, verifying both authenticity (created by that sender) and integrity (not tampered with) at once. Do not mix up the direction: signing uses the private key, verification uses the public key — the reverse of the key usage for confidentiality-purpose encryption.
• The PKI (public-key infrastructure) is the overall system that guarantees a public key genuinely belongs to its claimed owner. A certificate authority (CA) is a trusted third party that issues a digital certificate binding a public key to its owner's identity. A public key alone cannot prove "this really is that person's key," so a certificate signed by a CA is what guarantees authenticity.
• In challenge-response authentication, the server sends a random value that changes every time (a challenge), and the client returns only a computed result (a response) combining it with the password — the password itself never crosses the wire, defeating eavesdropping and replay attacks. SSL/TLS follows the flow: verify the server's authenticity via a server certificate (issued by a CA) -> securely exchange a session key using hybrid cryptography -> encrypt the rest of the session efficiently with symmetric-key cryptography — together delivering confidentiality, integrity, and authenticity.

Consider a financial company's IT department strengthening security for two areas: remote access to internal systems, and e-contracts with customers. First, for internal system login — previously password-only — given the risk of credential theft via phishing, they upgrade to multi-factor authentication, requiring a password (a knowledge factor) plus a one-time code from a smartphone app (a possession factor). For high-privilege accounts such as executives, they add fingerprint authentication (a biometric factor) as a third factor, tuning the accuracy so the false rejection rate (FRR) is not so high that it disrupts work. Next, for exchanging contracts with customers as electronic data, they need to simultaneously guarantee the contract was not tampered with and that the counterparty genuinely is the contracting customer, so they adopt digital signatures. The customer attaches a signature made by encrypting the contract's hash with their private key, and the company decrypts it with the customer's public key to verify. But this raises a new question: is that public key really the customer's? To resolve it, they use a digital certificate issued by a trusted certificate authority (CA) to confirm the customer's public key's validity, with the overall PKI framework underpinning authenticity. Finally, for the communication between the internal system and browsers, they enable SSL/TLS, which through the sequence of verifying server authenticity via a server certificate, securely exchanging a session key via hybrid cryptography, and then encrypting the rest of the session quickly with symmetric-key cryptography, also reduces the risk of the password or one-time code itself being eavesdropped. Strengthening authentication by combining several mechanisms suited to the risk of the task at hand, rather than relying on a single technology, is the judgment SG expects of a manager.

1.5.3Section summary

• MFA = two or more different types among knowledge, possession, and biometric. Combining factors of the same type does not count
• Digital signature = encrypt with the private key, verify with the public key = authenticity + integrity. CA/PKI guarantees the public key's validity
• Challenge-response never sends the password itself, defeating eavesdropping/replay. SSL/TLS integrates authentication, key exchange, and encrypted communication