Protecting Data Flashcards

An automated geographic boundary that triggers an access decision — allow or restrict — based on whether a user or device is inside or outside the defined area. Works at building scale (inside vs. outside corporate HQ), country scale (block access from foreign countries), or any boundary in between. Technologies: GPS (high accuracy outdoors), 802.11 Wi-Fi positioning (indoors), cell tower triangulation (mobile devices), IP geolocation (least accurate, spoofable). Security applications: enhanced access inside the building, country-level blocking for organizations with no foreign users, triggering MFA challenges outside trusted locations.

Encryption: two-way. Plaintext → ciphertext using a key; ciphertext → plaintext using the key to reverse. Designed for data you need to recover. Primary goal: confidentiality. Hashing: one-way. Input → fixed-length digest; the process cannot be mathematically reversed. Designed for data where you only need to verify a match. Primary goal: integrity verification and password storage. The exam question "which technique cannot be reversed?" → hashing. "Which technique requires a key to decrypt?" → encryption. "Which technique produces a fixed-length output regardless of input size?" → hashing.

The current standard cryptographic hash function for most security applications. Output: always 256 bits = 64 hexadecimal characters, regardless of input size. Avalanche effect: changing one character anywhere in the input produces a completely different 64-character hash — no visible relationship to the original. Deterministic: same input always → same hash (this is how password verification works: hash the provided password, compare to stored hash). Use cases: password storage, file download integrity verification (compare hash of received file to published hash), digital signatures (hash the message, sign the hash with private key). Not reversible. SHA-256 is currently considered secure; MD5 and SHA-1 are deprecated due to collision vulnerabilities.

Systems store the hash of a password, never the plaintext and never an encrypted version. When a user logs in: system hashes the entered password and compares it to the stored hash — if they match, access is granted. No decryption needed. Why not encryption? Because decryption requires managing and protecting the encryption key — if the key is stolen, all passwords are exposed. With hashing: even if the database is stolen, the attacker has only hashes, not passwords (they must crack each hash individually, which is computationally expensive). Why not plaintext? Obviously — a stolen database would immediately expose all user passwords. The stored hash proves the user knows the right password without the system ever needing to store or transmit the actual password.

A digital signature provides three security properties simultaneously: (1) Authentication — proves the message came from the claimed sender, because only the sender holds the private key used to create the signature; (2) Integrity — proves the message was not altered in transit, because any change to the message would produce a different hash that would not match the decrypted signature; (3) Non-repudiation — the sender cannot deny sending the message, because only their private key could have produced that signature. Process: sender hashes message → encrypts hash with private key = signature. Receiver: decrypts signature with sender's public key → gets original hash; hashes received message independently → compares both hashes. Match = all three guarantees hold.

Making code or data intentionally difficult to understand while preserving its original functionality or meaning. Not encryption: there is no key, and a determined analyst can reverse it with enough effort. Not impossible to reverse: it buys time and raises the cost of analysis, but does not mathematically prevent reversal. Legitimate uses: software IP protection (obfuscate compiled/minified JavaScript so competitors cannot easily read proprietary algorithms), reducing file size (minification), legacy software protection. Malicious uses: malware obfuscates its code to evade signature-based antivirus detection. Key exam point: obfuscated code runs identically to the original — the behavior is preserved, only the human-readable structure is scrambled.

Both hide the real value from those who do not need it, but they work differently. Masking: hides part of the data for display purposes — the underlying full value may still be stored intact in the database (a call center agent sees **** **** **** 4532; the payment system can retrieve the full number). Masking is a view-layer control. Tokenization: replaces the actual value with a token throughout the system — the real value is stored only in the token service, nowhere else. Tokenization is a storage-layer replacement. The card number 4111-1111-1111-1111 no longer exists in merchant systems; only the token 8937-2841-7734-0092 does. If the merchant's database is stolen, the tokens are useless — no mathematical relationship back to the real card number.

Apple Pay / Google Pay use tokenization to protect card numbers in NFC (contactless) transactions. Setup: user adds card to wallet → card issuer generates a device-specific token for that card on that device. Token replaces the real card number in the device's secure element. Payment: device transmits token over NFC → merchant terminal receives token → network routes to token service → token service maps token to real card number → transaction authorized with real number → response sent back. The merchant only ever sees the token. One-time-use tokens: many implementations generate a single-use token per transaction — even if the token is intercepted, it cannot be replayed for another transaction. No encryption overhead in the token transmission itself — just a lookup.

Distributing data across multiple separate databases or systems instead of storing everything in one place. Security benefit: limits the blast radius of any single breach. An attacker who compromises one database gets only the data in that segment, not everything. Implementation: tier data by sensitivity — most sensitive data (SSNs, card numbers, medical records) in the highest-security tier with the most controls; less sensitive data (order history, product preferences) in lower-security tiers. Each tier gets security controls proportional to the value of its data. The tradeoff: operational complexity — cross-segment queries require joining data across systems or additional application logic. Security gain (breach scope limitation) versus operational cost (more complex queries and data management) is the core tradeoff.

Two-layer data access control. Authentication layer (who are you?): password policies (length/complexity requirements, expiration, history to prevent reuse), multi-factor authentication (second factor — authenticator app, hardware token, SMS, biometric), lockout after failed attempts. Authorization layer (what can you do after you log in?): group-based permissions (assign users to groups, manage permissions at the group level rather than per user), file/folder ACLs (read/write/execute per group), principle of least privilege (each user gets only the minimum permissions required for their job — not blanket access), separation of duties (critical operations require two or more people to prevent single-person fraud: one person initiates a wire transfer, a different person approves it).