Password Encryption, Transmission, and Secure Storage: From Symmetric/Asymmetric Encryption to HTTPS, RSA, and Hashing

Password Encryption, Transmission, and Secure Storage

Recently, a leak revealed that GitHub stored passwords in plain text in internal logs, highlighting the need for robust encryption of password transmission and storage.

Encryption Transmission

Encryption can be divided into two main types: symmetric encryption and asymmetric encryption.

Symmetric Encryption

Symmetric encryption uses the same secret key for both encryption and decryption.

The typical workflow is:

Party A selects an encryption algorithm and encrypts the data.

Party B uses the same algorithm and key to decrypt the data.

When client and server communicate using a single symmetric key, the key can be easily compromised; using a new key for each session improves security but increases key management overhead.

Asymmetric Encryption

Asymmetric encryption uses a pair of keys: a public key for encryption and a private key for decryption.

The process is:

Party B generates a public/private key pair.

Party A obtains Party B's public key and encrypts the data.

Party B uses the private key to decrypt the data.

Even if an attacker obtains the public key, without the private key the data remains unreadable.

RSA

RSA is the classic asymmetric algorithm, invented in 1977 by Rivest, Shamir, and Adleman. It relies on the difficulty of factoring large coprime integers.

In practice, a large product of two prime numbers forms the public key, while the factorization (the private key) is kept secret. Encryption with the public key can only be decrypted with the corresponding private key.

GitHub Login Method

Capturing the login request shows that the password is transmitted in plain text over HTTPS. While HTTPS encrypts the channel, sending the raw password is still not ideal.

HTTP vs HTTPS

Plain HTTP exposes three major risks:

Eavesdropping – third parties can read the data.

Tampering – data can be altered in transit.

Impersonation – attackers can pose as the legitimate party.

HTTPS mitigates these risks by adding TLS (formerly SSL) on top of HTTP.

How HTTPS Works (Simplified Flow)

Client initiates an HTTPS request.

Server provides an SSL/TLS certificate containing a public key (A) and metadata.

Client validates the certificate (issuer, expiration, etc.).

Client generates a random value and encrypts it with the server's public key.

Encrypted random value is sent to the server.

Server decrypts it with its private key (B) to obtain the shared secret (C).

Server uses the shared secret (C) to encrypt subsequent data (symmetric encryption).

Client decrypts the data with the same shared secret (C).

This handshake ensures confidentiality, server authentication, and data integrity.

Man‑in‑the‑Middle (MITM) Attacks

HTTPS security relies on the trustworthiness of certificates. If an attacker can forge or trick a user into trusting a malicious certificate, they can decrypt and modify the traffic, rendering HTTPS ineffective.

Baidu Login Method

Network capture shows that Baidu encrypts the password before transmission using RSA, similar to the JavaScript library jsencrypt . The flow mirrors the RSA process described earlier.

Secure Password Storage

Never Store Plain Text

Storing passwords in clear text (whether in a database or logs) exposes users to immediate compromise if the data is leaked.

Hashing Passwords

Hashing is a one‑way function: it converts a password into a fixed‑size digest that cannot be reversed.

Common hash algorithms include MD5 and the SHA family (SHA‑1, SHA‑256, SHA‑384, SHA‑512). However, simple hashes are vulnerable to rainbow‑table attacks.

Salting

Adding a random string (salt) to the password before hashing prevents pre‑computed rainbow tables from being effective. Each password should have a unique salt stored alongside its hash.

Key‑Stretching Algorithms (BCrypt, PBKDF2)

BCrypt and PBKDF2 allow configurable work factors that make hash computation deliberately slow, dramatically increasing the cost of brute‑force attacks.

Summary

Use HTTPS for all client‑server communication.

Encrypt passwords with RSA (or another asymmetric algorithm) before transmission.

Store passwords using a strong, salted, key‑stretching hash such as BCrypt or PBKDF2.

Following these steps maximizes the confidentiality and integrity of user credentials.