Track 5 · Lesson 4 of 7

Passwords, keys and secrets

Why passwords are hashed, how to make a strong passphrase, generate random secrets, and keep your private SSH keys safe.


In this lesson you will look at how passwords are actually stored. You will generate strong random secrets of your own. You will also create an SSH key that is safe to keep on your phone. This matters, because most break-ins do not start with clever code. They start with a weak secret. It was reused, stored badly, or left lying in the open.

What you'll be able to do

  • Explain the difference between hashing and encryption, and why it matters for passwords.
  • Generate a long random secret with tools that are already on your device.
  • Check a password against a stored hash without ever reversing the hash.
  • Create an SSH key and protect the private half with a passphrase.
  • Recognise the two habits that cause most password trouble: reuse and leaked keys.

Step 1: Understand hashing

Encryption is designed to be undone. With the key you can turn ciphertext back into plaintext. Passwords are not stored that way. A password is run through a one-way hash, and the hash is what gets saved. When you log in, the system hashes what you typed. Then it compares the two hashes. It never needs your original password.

Here is a one-way hash of a passphrase. The -n stops echo adding a newline. You hash exactly the characters you typed.

$ echo -n "correct horse battery staple" | sha256sum
c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a  -

Run the same command again and you get the same 64-character result. Change one letter and the whole result changes. You cannot work backwards from that string to the passphrase. A hash lets a system check a password without keeping the password.

Two different passwords can sometimes produce the same hash. That is called a collision. Good hash functions make it so unlikely that you can ignore it in daily use. What you cannot do is run the hash backwards to recover the password. That is the difference between a hash and encryption. It is why a leaked hash file is far less damaging than a leaked password file.

Hashing is one way

If you ever see a service claim it can email you your old password, that is a warning sign. A properly hashed password cannot be recovered, only reset.

Step 2: Check a password against a hash

Hashing is one way, so the way you check a password is to hash it again and compare. Here the same passphrase is hashed a second time, character for character.

$ echo -n "correct horse battery staple" | sha256sum
c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a  -

The two hashes match, so the password matches. Now try a wrong password the same way.

$ echo -n "correct horse battery staple!" | sha256sum
e5a0f4f3a2c9d1b6e8f7a3c2b1d9e0f4a7c6b5d4e3f2a1b0c9d8e7f6a5b4c3d2  -

One extra character and the hash is completely different. That is why a single character matters. A longer secret matters even more.

Step 3: Generate a strong random secret

Humans are bad at random. Use the machine instead. openssl ships with Termux and produces random bytes.

$ openssl rand -base64 24
0Yk3Qm7pXvT2sLbA9dRfW1nHcJ8eZuGq

That command asks for 24 random bytes and encodes them in base64. That gives you 32 characters of printable text. If openssl is not available, read straight from the system's random device and encode it yourself.

$ head -c 32 /dev/urandom | base64
7vQ2mK9xR4pL0aZtN8bW3yC6dF1gH5jS2kM4nP7qR0s=

Both produce output you could not have guessed. Use it for anything that needs to be unpredictable. A session secret or a generated password is a good fit.

Never invent a secret by hand

A secret you type from your own head follows patterns, and patterns are what attackers try first. Let the machine generate it.

Step 4: Prefer a long passphrase

A short password with symbols is hard for you to remember. It is still short for a machine to grind through. A long passphrase of several ordinary words is easier to remember. It also gives the attacker a far larger space to search. Length beats complexity.

$ echo -n "copper lantern wheel anchor" | sha256sum
9f2b1c4a7e0d3b6f8a5c2e9d1b4f7a0c3e6b9d2f5a8c1e4b7d0f3a6c9e2b5d8f  -

Four words give you far more combinations than one short scrambled word. You can still recall it. Treat the passphrase as your key to a password manager. Then let the manager hold unique long passwords for everything else.

A manager needs its own long passphrase, and it can generate the rest. Here is a single strong value on demand.

$ openssl rand -base64 18
3rT8kL2mN9pQ4sV6wX1yZ0aB

You now have a value you did not choose and could not predict. Store it in the manager. Give it a name you will recognise. Let it stay unique to one account.

Step 5: Create and protect an SSH key

An SSH key comes in two halves. The public half goes to the server you connect to. The private half stays on your device and must never leave it. Generate a pair with ssh-keygen.

$ ssh-keygen -t ed25519 -C "phone key"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/data/data/com.termux/files/home/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /data/data/com.termux/files/home/.ssh/id_ed25519
Your public key has been saved in /data/data/com.termux/files/home/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:8Nq2wVb7kLp3Zx1rT5yU9iO4aS6dF0gH2jK8lM3nP7q phone key

Notice the prompt for a passphrase. Type one. It encrypts the private key file. If the file is copied off your phone, it is useless without that passphrase. Then look at what was created.

$ ls -la ~/.ssh
total 16
drwx------ 2 u0_a231 u0_a231 4096 Mar  6 10:21 .
drwx------ 6 u0_a231 u0_a231 4096 Mar  6 10:20 ..
-rw------- 1 u0_a231 u0_a231  411 Mar  6 10:21 id_ed25519
-rw-r--r-- 1 u0_a231 u0_a231  100 Mar  6 10:21 id_ed25519.pub

The private key id_ed25519 is readable only by you. The -rw------- permissions show that. The public key ends in .pub and is safe to share. Print it when a server asks for it.

$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEXAMPLEKEYNOTREALPLACEHOLDER000000000 phone key
Never reuse a password or commit a key

One password reused everywhere means one breach unlocks everything. And a private key committed to a repository is a key you have given away. Keep keys out of version control, and give every account its own secret.

Two habits cover most of the ground here. Give every account its own long secret. Keep the private half of any key on your device, behind a passphrase. Do both, and a single breach stays a single breach.

Quick reference

CommandWhat it does
sha256sumHashes the text you pipe in, or a file you name
openssl rand -base64 24Prints 24 random bytes as base64 text
head -c 32 /dev/urandomReads 32 random bytes, ready to encode
base64Encodes whatever you pipe into it
ssh-keygen -t ed25519 -C "label"Creates a new SSH key pair
cat ~/.ssh/id_ed25519.pubPrints the public key you can share
ls -la ~/.sshShows the permissions on your key files

Next steps

Test yourself on this

4 questions and 1 task where you run a real command, with the reasoning explained either way.

Start