Security

Overview A VPN creates an encrypted tunnel for all of a device’s network traffic through a remote server, while a proxy forwards traffic from a single app or protocol through an intermediary server, typically without encryption. The distinction matters because it determines what’s protected, how much overhead is added, and what happens when the connection fails. Comparison Diagram VPNProxyDevice (OS)all apps & trafficencrypted tunnelVPN ServerInternetEncrypts & routes ALL device trafficBrowserapp trafficProxy ServerOther Appsbypasses proxy (direct, unencrypted)InternetRoutes only configured app/protocol traffic Comparison Table Aspect VPN Proxy Scope of traffic routed All network traffic from the device (OS-level) Traffic from a specific app or protocol the client is configured to use Where it’s configured System network settings / dedicated client that creates a virtual interface Individual app settings (browser, OS network stack per-app, or system-wide proxy field) Encryption Encrypts traffic between device and VPN server by default No encryption by default; only as strong as the underlying protocol (e.g. HTTPS) Authentication to server Client authenticates with certificates/credentials to establish the tunnel Often none, or simple username/password at the app layer Visibility to local network/ISP ISP and local network see only encrypted tunnel traffic to one endpoint ISP sees the proxy connection plus any traffic from unproxied apps Performance overhead Higher — encryption and full traffic redirection add latency Lower — only proxied traffic is redirected, often with caching Typical use case Secure remote access to a private network, or system-wide privacy on untrusted Wi-Fi Per-app geo-bypass, content filtering, or caching for a single protocol Behavior on failure Well-configured clients include a kill switch that blocks all traffic if the tunnel drops Only the proxied app’s connection fails; other traffic is unaffected Key Differences A VPN operates at the OS network layer, capturing all traffic, while a proxy operates at the application layer for one app or protocol VPN traffic is encrypted by default; proxy traffic is unencrypted unless the underlying protocol adds it VPNs require dedicated client software creating a virtual interface; proxies need only an IP:port entry in an app’s settings A VPN’s kill switch can block all traffic on disconnect; a proxy failure only drops that single app’s connection When to Use Each VPN ...

Overview Hashing and encryption both scramble data into something unreadable, but they solve different problems: hashing is a one-way function used to verify that data hasn’t changed, while encryption is a reversible process used to keep data secret from unauthorized parties. Mixing them up — like encrypting passwords instead of hashing them — is a common and dangerous mistake. Comparison Diagram HashingEncryptionInput (any length)Hash FunctionDigest (fixed length)irreversible, no keyPurpose: integrity & verificationPlaintextEncrypt (+ key)CiphertextDecrypt (+ key)Plaintext (recovered)Purpose: confidentiality Comparison Table Aspect Hashing Encryption Core operation Transforms input into a fixed-length digest Transforms plaintext into ciphertext Reversibility One-way; original input cannot be recovered Two-way; ciphertext decrypts back to plaintext Key requirement No key needed for a standard hash function Requires a secret key (or key pair) Output size Fixed-length digest regardless of input size Ciphertext length scales with plaintext size Determinism Same input always produces the same digest Same plaintext yields different ciphertext each run via IV/nonce Primary goal Integrity verification and data identification Confidentiality of data Main failure mode Collision: two inputs producing the same digest Key compromise, exposing all encrypted data Typical use cases Password storage, checksums, digital signatures Securing data at rest and in transit Key Differences Hashing is one-way; encryption is designed to be reversible with the correct key. Encryption always requires a secret key; standard hashing needs none. A hash always produces a fixed-length digest, no matter how large the input is. Hashing protects integrity; encryption protects confidentiality. A hash function must resist collisions; a cipher must resist key or plaintext recovery. When to Use Each Hashing ...

Overview Symmetric encryption uses a single shared secret key for both locking and unlocking data, making it fast but dependent on securely distributing that key beforehand. Asymmetric encryption uses a mathematically linked key pair — public and private — solving the distribution problem at the cost of heavier computation. Comparison Diagram SymmetricAsymmetricAliceBobsame keyshared secretlySenderReceiverpublic key(shared openly)private key(kept secret)encrypted withpublic key1 key, both directions2 keys, one direction each Comparison Table Aspect Symmetric Encryption Asymmetric Encryption Key setup One shared secret key generated for both parties Mathematically linked key pair: public key and private key Key distribution Requires a secure channel to exchange the key beforehand Public key can be freely published; private key never leaves its owner Encryption operation Same key encrypts the plaintext Sender encrypts using the recipient’s public key Decryption operation Same key decrypts the ciphertext Recipient decrypts using their own private key Performance Fast, low CPU overhead, suited to large volumes of data Computationally expensive, orders of magnitude slower Key scalability Number of keys needed grows quadratically with participants Each participant needs only one key pair regardless of participant count Common algorithms AES, ChaCha20, 3DES RSA, ECC, Diffie-Hellman Typical use case Bulk data encryption: disks, files, VPN tunnels Key exchange, digital signatures, certificate/identity verification Key Differences Symmetric uses a single shared key; asymmetric uses a key pair of public and private keys Symmetric is far faster, making it practical for encrypting large payloads Asymmetric eliminates the key distribution problem since the public key can be shared openly Real-world protocols like TLS use a hybrid approach, using asymmetric encryption to exchange a symmetric session key Only asymmetric keys support digital signatures for authenticity and non-repudiation When to Use Each Symmetric Encryption ...

Overview RBAC and ABAC are two models for deciding whether a subject can perform an action on a resource. RBAC grants access based on a user’s assigned role and that role’s fixed permission set, while ABAC evaluates a policy against attributes of the user, resource, action, and environment at request time. The choice affects how fine-grained, dynamic, and auditable your authorization system can be. Comparison Diagram RBACABACUserRole: EditorPermissionsReadWritePublishFixed, regardless of contextUser attrsResource attrsEnv attrsPolicy EngineAllow / DenyEvaluated per request, in context Comparison Table Aspect RBAC ABAC Access decision basis A user’s assigned role Attributes of the user, resource, action, and environment Permission structure Static, predefined role-to-permission mappings Dynamic policies expressed as attribute-based rules Administration Admin assigns users to existing roles Policy author writes rules combining attribute conditions Runtime evaluation Check whether the user’s role includes the requested permission Policy engine evaluates rules against current attribute values Context sensitivity Same result regardless of time, location, or device Can factor in time, location, device, and other real-time signals Granularity Coarse-grained, applied per role Fine-grained, applied per request or condition Scalability with complexity Role explosion as requirements diversify Policy complexity grows, but avoids proliferating roles Auditability Easy to audit — list who holds a given role Harder to audit — requires tracing policy logic across attributes Key Differences RBAC ties access to roles; ABAC ties access to attributes RBAC decisions are static; ABAC decisions are context-aware ABAC enables fine-grained control at the cost of policy complexity RBAC suffers from role explosion as requirements grow RBAC is generally easier to audit than ABAC When to Use Each RBAC ...

Overview Authentication (AuthN) confirms who a user or system claims to be, typically through credentials like passwords, biometrics, or tokens. Authorization (AuthZ) determines what an already-authenticated identity is permitted to do or access. The two are sequential and often conflated, but security bugs frequently trace back to confusing one for the other — e.g., checking that a user is logged in without checking they’re allowed to see a specific resource. ...