Encryption, hashing, digital signatures and tokenization do not solve the same security problem. This Security+ SY0-701 walkthrough maps each mechanism to confidentiality, integrity, accountability and recoverability, then examines practical failures caused by weak key custody, incorrect password hashing and missing verification.<\/p>\n
A team says it needs to "encrypt a document" when its actual problem may be demonstrating that the document was not changed. Another team wants a hash of a password but expects it to be reversible. A third team has a valid website certificate but stores its associated private key in a broadly accessible file share. These mistakes come from treating every cryptographic operation as a substitute for every other.<\/p>\n
Cryptographic controls should be selected according to the security property and data state. Encryption protects confidentiality when keys are managed correctly; hashes help detect changes; message authentication codes and signatures support different integrity and origin claims; secure key custody and rotation limit exposure after compromise. The PKI certificate lifecycle<\/a> adds issuer trust, issuance, renewal and revocation decisions that differ from choosing a cipher for a stored document. A third-party Security+ SY0-701<\/a> question is useful when it asks which security property failed and what evidence verifies the chosen control. Encrypting a file does not prove who authored it, and a valid digital signature does not itself authorize the signer to approve a business action.<\/p>\n Consider a fictional payroll system with stored compensation data, HTTPS connections, employee passwords, signed approval records and application secrets. Each asset requires a separate question: who is allowed to read it, how will unauthorized modification be detected, what evidence identifies the signer, and what happens if a key is lost?<\/p>\n Symmetric encryption uses a secret key to encrypt and decrypt information efficiently. It suits large bodies of stored or transmitted data when approved key distribution and management are available. Asymmetric cryptography uses public and private key operations for particular purposes, including key establishment and digital signatures; it is not normally the mechanism used to encrypt every byte of a large database.<\/p>\n Encryption at rest protects against defined threats to stored media or snapshots, but a compromised process with authorized decryption rights may still read plaintext. Full-disk encryption can protect a lost laptop while doing little to stop malware running as the logged-in user. Database field encryption may restrict exposure through some administrative paths but requires careful consideration of where keys and plaintext are accessible.<\/p>\n Encryption in transit protects data moving across a network when the protocol is correctly negotiated and endpoints are authenticated. TLS can help protect a web session; it does not establish that the application user is permitted to retrieve every document stored behind the website. Distinguish the transport security channel from the application’s actual authorization decision.<\/p>\n A cryptographic hash creates a fixed-length digest of input data. It helps detect changes when the reference value and comparison process are trustworthy, but the digest alone does not identify who authored a file. A malicious actor who can change both the file and the stored expected digest may evade a naive integrity check.<\/p>\n Password storage requires a different approach from generic file hashing. Use an approved password-hashing or key-derivation method designed for passwords, with unique salts and appropriate work parameters. A fast general-purpose hash directly applied to common passwords is vulnerable to large-scale guessing. A salt helps prevent identical passwords from sharing the same stored verifier and makes precomputed attacks less convenient; it does not turn a weak password into a high-entropy secret.<\/p>\n Where appropriate, a separately protected pepper can supplement a password-storage design, but its lifecycle and storage location matter. Never place plaintext passwords, full password-reset tokens or sensitive authentication secrets in log messages just to make troubleshooting easier.<\/p>\n A digital signature is created using a private signing key and verified using the corresponding public key and appropriate trust context. It can establish integrity and provide evidence about the signer when key custody and certificate validation are sound. It is different from encrypting the message for secrecy: a signed public document can still be readable by anyone.<\/p>\n A message authentication code such as HMAC uses shared secret material to authenticate data between parties that know that secret. It can protect message integrity and authenticity for a defined relationship, but it generally cannot provide the same third-party non-repudiation properties as a properly managed asymmetric digital signature, because more than one holder may know the shared key.<\/p>\n For a payroll approval workflow, a signed audit record can be meaningful only if the signing private key is protected and the event is bound to the exact transaction and actor. If several administrators share the private key, the signature loses much of its value for attributing a particular approval.<\/p>\n A certificate associates a public key with an identity or other attributes under an issuer’s signature. Certificate chains, trusted roots, validity periods and revocation signals matter when relying on that binding. But the certificate is not the private key itself. A website can present a valid certificate and still run an application with a serious authorization defect.<\/p>\n In a client connecting to a TLS endpoint, the server certificate helps the client authenticate the intended service, while the session keys protect traffic after a successful handshake. An administrator should distinguish the server’s identity, negotiated protocol configuration, key exchange and the application’s user-session authentication. The earlier PKI lifecycle article explores renewal and revocation in more detail; this article focuses on making the correct cryptographic selection for each data flow.<\/p>\n A cryptographic design is incomplete until someone can answer where keys are created, which actors can use them, how their usage is logged and what happens during compromise, rotation or loss. A database encrypted under a key that is permanently lost may be unreadable, which can be as damaging as disclosure in a different way. A backup of ciphertext without recoverable approved key material might not meet the organization’s disaster-recovery requirement.<\/p>\nEncryption protects confidentiality, not every security property<\/h2>\n
Hashing is not reversible encryption<\/h2>\n
Signatures and message authentication solve different problems<\/h2>\n
Certificates bind keys to identity claims<\/h2>\n
Key rotation and backup should be operationally planned<\/h2>\n