Information Security 11 min read

Understanding Password Encryption, Transmission, and Secure Storage

This article explains how passwords should be encrypted during transmission using symmetric and asymmetric methods such as RSA, why HTTPS is essential, how services like GitHub and Baidu handle login security, and best practices for securely storing passwords with hashing, salting, and strong algorithms like BCrypt and PBKDF2.

Architect's Tech Stack
Architect's Tech Stack
Architect's Tech Stack
Understanding Password Encryption, Transmission, and Secure Storage

Recently, a GitHub internal log leak revealed that plaintext passwords were recorded, highlighting the importance of protecting user credentials. This article introduces methods for encrypting password transmission and securely storing passwords.

Encryption Transmission

There are two main encryption approaches: symmetric encryption, which uses the same secret key for both encryption and decryption, and asymmetric encryption, which uses a public key for encryption and a private key for decryption. Symmetric encryption is simple but requires secure key exchange; asymmetric encryption solves the key‑distribution problem. The classic asymmetric algorithm is RSA, which relies on the difficulty of factoring a large product of two coprime prime numbers.

GitHub Login Method

Packet capture of a GitHub login request shows that the password is sent in plaintext over HTTPS. Although HTTPS provides transport encryption, sending the raw password still poses risks.

HTTP vs. HTTPS

Standard HTTP transmits all data in clear text, exposing it to three major risks: eavesdropping, tampering, and impersonation. HTTPS combines HTTP with TLS/SSL to provide confidentiality, authentication via certificates, and data integrity checks.

HTTPS Handshake Overview

Client initiates an HTTPS request.

Server presents an X.509 certificate containing a public key (key A) and metadata.

Client validates the certificate, generates a random value, and encrypts it with the server’s public key, producing an encrypted secret (key C).

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

Both sides then use key C for symmetric encryption of subsequent data.

Man‑in‑the‑Middle (MITM) Attacks

HTTPS security depends on the trustworthiness of certificates. An attacker who can forge or trick a user into installing a malicious certificate can bypass encryption, making even HTTPS‑protected password transmission insecure.

Baidu Login Method

Packet capture of Baidu’s login request shows that the password is encrypted. The server response includes a public key, indicating RSA encryption. The process matches the JavaScript library jsencrypt , which Baidu appears to use for client‑side RSA encryption.

Secure Password Storage

Storing passwords in plaintext is unsafe. One‑way hash functions (MD5, SHA‑1/256/384/512) convert passwords to fixed‑size digests, but are vulnerable to rainbow‑table attacks. Adding a random “salt” to each password before hashing mitigates rainbow‑table attacks, but fast hash functions still allow brute‑force attacks.

Adaptive hashing algorithms such as BCrypt and PBKDF2 deliberately increase computational cost by repeating the hash many times. By configuring a high work factor, hashing can take seconds per password, rendering brute‑force attempts impractical.

Summary

Use HTTPS for all client‑server communication.

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

Store passwords using a strong adaptive hash like BCrypt or PBKDF2, with a unique salt per password.

RSAEncryptionHashingpassword securityHTTPSbcryptPBKDF2
Architect's Tech Stack
Written by

Architect's Tech Stack

Java backend, microservices, distributed systems, containerized programming, and more.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.