Secure communication over the web depends on Transport Layer Security (TLS), the protocol underlying HTTPS. During the TLS handshake, the client proposes supported cipher suites, the server replies with its digital certificate and a chosen cipher, the client validates that certificate against trusted certificate authorities (CAs), and the two sides use asymmetric cryptography to derive a shared secret. From that point onward, all traffic is protected by faster symmetric encryption. The trust model is hierarchical: a self-signed root CA sits at the top, intermediate CAs are signed by roots, and server certificates are signed by intermediates. Browsers walk up the chain to confirm each link, and certificate pinning can further restrict which authorities are accepted for a given domain, though Certificate Transparency has largely replaced HTTP Public Key Pinning in modern deployments.
Cryptography itself comes in two principal flavors. Symmetric encryption uses the same key for both encryption and decryption and is favored for bulk data because of its speed; examples include AES and ChaCha20. AES operates on 128-bit blocks with key sizes of 128, 192, or 256 bits, and modern recommendations prefer AES-256-GCM because the Galois/Counter Mode provides authenticated encryption, delivering both confidentiality and integrity in one step. Asymmetric encryption, in contrast, pairs a public key with a private key and is used for key exchange and digital signatures; RSA and elliptic-curve cryptography are the most common algorithms. TLS cleverly combines both worlds: asymmetric crypto establishes a session key, and symmetric crypto then carries the bulk traffic efficiently. A digital signature follows a similar pattern: the sender hashes the message, encrypts that hash with a private key, and the recipient verifies by decrypting with the corresponding public key and comparing hashes. This proves both authenticity (who signed it) and integrity (the message was not altered), and the technique underpins everything from TLS certificates to signed JWTs to code signing.
Passwords require a different approach because they must be protected in a form that is never recoverable. Hashing provides a one-way transformation: given a hash, you cannot in general recover the original input, but you can re-hash a candidate password and compare. Fast general-purpose hashes like MD5 and SHA-256 are unsuitable for passwords because attackers can compute billions of guesses per second, so the field uses deliberately slow, password-specific functions. Bcrypt, based on the Blowfish cipher, includes automatic salting and a configurable work factor that can be increased as hardware grows faster; its output looks like $2b\(12\)salt...hash.... Argon2, the winner of the 2015 Password Hashing Competition, is even more flexible, with Argon2id (a hybrid variant) recommended for general use and tunable parameters for time, memory, and parallelism that resist both GPU and ASIC attacks. Salting is what makes these schemes resistant to rainbow table attacks: precomputed tables of hash-to-password mappings become useless when every user has a unique random salt mixed into their hash. It is also worth keeping three related concepts distinct: encoding (such as Base64 or URL encoding) is purely for compatibility and offers no security; encryption is reversible with a key; and hashing is one-way. Confusing these is a frequent source of vulnerabilities.