Security: watch
The password you type dozens of times a day is rarely broken by force. It is guessed, phished, or found in someone else's leak. Four films show how this happens and what actually protects against it.
Exercises and files are in the text version.
Part 1Passwords
Passwords are rarely stolen directly: mostly they are guessed after a leak from some site. The film follows that path from a site's database to someone else's mailbox and shows what breaks it.
Exercises and details for this part · The film on its own page
Part 2Second factor
A second factor adds to the password something only you have. There are several kinds, and they protect against different things. The film compares them on one attack: a fake site.
Exercises and details for this part · The film on its own page
Part 3Phishing and spoofed addresses
One of the costliest frauds starts with an ordinary email from a familiar supplier. The film shows how an account number gets swapped and which check stops it.
Exercises and details for this part · The film on its own page
Part 4Encryption
The word “encrypted” says little until you know who holds the key. The film follows one message from the device to the recipient and shows who can read it at each step.
Exercises and details for this part · The film on its own page
Check yourself
As text
The same as the films: every shot and its text. You can copy the text and give it to your own assistant along with your question.
Passwords
To recognize you, a site has to check your password somehow. It does not need to keep the password itself for that, and usually it does not: at sign-up the password goes through a hash function, and only the result, the hash, is written to the database. The function works one way: getting the hash from a password is easy, getting the password from the hash is not. At login the site hashes what you typed and compares it with what is in the database.
Suppose the database is stolen. Whoever has it now holds email addresses and hashes, but not passwords. A password cannot be recovered from its hash, but the attack can run the other way: take likely passwords, hash each one and look for a match in the stolen database. So it is more accurate to say that in such a leak passwords are not broken but guessed.
The guessing runs on the attacker's computer, not on the site, so no limit on login attempts applies. The program works through dictionaries, passwords from earlier leaks and common combinations such as a city name plus a year. It tries billions of candidates, so short and predictable passwords are found first.
A password's strength is the number of candidates an attacker has to try. A keyboard has about ninety-five characters, and each extra random character multiplies that number by ninety-five. The practical consequence: length matters more than swapping letters for lookalike symbols, because the program checks those swaps too. Five random words give a number of candidates twenty digits long, and they are easier to remember than eight random characters.
The guessed pair of address and password is then tried on other services: email, the bank, cloud storage. This is automated too and takes minutes. If the password is the same everywhere, a leak from a small online shop opens everything else as well. Your protection is then only as good as the weakest site you have signed up to.
So every site needs its own password, long and random. Nobody can remember dozens of those, and a password manager takes over the job. You keep one master password, and the manager itself is best protected with a second factor as well. Then a leak from one site costs one password, and you know which one.
You can check whether your address has turned up in known leaks on the Have I Been Pwned site. If it has, change the password on that site and everywhere you reused it. The next film is about the second factor: what it adds to a password and how its kinds differ.
Second factor
You can lose a password without doing anything wrong: a leak from one of the sites where you used it is enough. The second factor was invented for exactly that case. Logging in takes two things of different kinds: something you know, the password, and something you have with you, a phone or a key. The password alone is then no longer enough.
The most common second factor is a code by SMS. After the password, the site sends a few digits to your number, and whoever holds the phone confirms the login. It is convenient because nothing needs installing. That is also its weakness: the code is tied to the number, not to the phone. The number can be reissued on another SIM card with a forged request, and then a stranger receives the codes. SMS can also be intercepted in the carrier's network.
An authenticator app works without the carrier. At setup the site and the phone exchange a secret once, and from then on the phone computes the code itself from that secret and the current time. The code is never sent anywhere, so reissuing the SIM card gets an attacker nothing. One limit remains: a person types the code by hand, and so can type it on the wrong site.
Phishing builds on this: luring data out of people with a fake. There are many tricks; one of the simplest is a domain that differs from the real one by a single letter. The person follows a link, sees the familiar login page and enters the password and the code. The attacker's program passes them to the real site at once, while the code is still valid. No method that has you type something by hand protects against this.
A passkey and a hardware key work differently: there is nothing to type. The key signs the login request and is bound to the domain where it was registered. On a domain with one different letter it simply does not work. The protection does not depend on whether the person noticed the fake.
The second factor has a flip side: without the phone or the key, the owner cannot get into the account either. So save the recovery codes right away, on paper or in a password manager, away from the phone. For a hardware key, register a spare and keep it in a different place.
The methods differ in what exactly they protect against. SMS protects against a stolen password. An authenticator app or a push with number matching also protects against a reissued SIM card. A passkey also protects against a fake site. Turn on the strongest method available and start with email, because that is where passwords to all other services get reset.
Phishing and spoofed addresses
The supplier and the buyer's accountant have been emailing each other for years. The invoice arrives in an email, and the payment goes to the IBAN written on the invoice. Nobody checks each email on its own, because there are many of them and they all look alike. The fraud known as invoice redirection relies on this habit.
It starts with the supplier. He gets a phishing email and types his password into a fake login page, and from then on an outsider has access to his mailbox. For a few weeks the outsider only reads the mail. He sets up a rule that forwards him copies of the emails and waits for the next invoice.
When a payment falls due, the buyer gets an email: our bank details have changed, please pay today. The fraudster sends it from the same mailbox or from a domain with one letter changed. The style, the signature and the references to earlier emails are genuine, because he has read them. The attachment is an ordinary invoice in which only the IBAN differs.
The accountant pays the invoice, because there is no reason to doubt it. The money lands in the fraudster's account, and the supplier never receives it. This comes out a few days later, when the supplier asks about the payment. By then the fraudster has usually moved the money on, and every hour lowers the chance of stopping it.
Mail services and security teams filter out such emails all the time: spam filters, sender checks, monitoring. But an email from a real, compromised mailbox gets past the filter. So the most reliable defense is simple: call the person who is asking. A change of bank details is confirmed with the supplier by phone, using a number from the contract or older documents, not from the email. After that, a second person approves the change.
Some signs give such an email away. New bank details together with a demand to pay urgently. A request to tell no one or to communicate only by email. A domain with one letter changed, and a reply address that does not match the sender's. And a request to bypass the usual approval process.
If the payment has already gone, the first hours count. Call your bank, report the fraudulent payment and ask them to stop it or to contact the receiving bank with a request to freeze and return the funds. Next, a report to the cyber police. Keep the emails together with their headers: they show where an email really came from. The supplier, for their part, changes the password and checks the forwarding rules in the mailbox.
Encryption
Follow the route of one message. From the device it travels over Wi-Fi and the provider's network to the service's server, and from there to the recipient. Without encryption the text is open to everyone along the way: the Wi-Fi owner, the provider and the service itself. Different kinds of encryption close it off from different parties.
Channel encryption, familiar from the https mark, protects data on its way from the device to the server. The Wi-Fi owner and the provider see which site the connection is with, when, and how much data went through, but not the content. On the server this protection ends: the service receives the text in the clear.
Encryption on the server means the data is stored on disks in encrypted form, and the service itself holds the key. This protects against the theft of a disk or a copy of the database. It does not protect against the service itself: the service can read the data and hand it over on a lawful demand, for example under a court order.
With end-to-end encryption, as in Signal, the keys exist only on the devices of the two people talking. The server relays encrypted messages and cannot read them, even on demand. It still sees the metadata: who wrote to whom, when, and how much.
Once the content is protected both in transit and on the server, the device itself becomes the weakest point. An unlocked phone shows everything, end-to-end encrypted chats included. That is why the screen lock and disk encryption - FileVault on a Mac, BitLocker on Windows - decide what a person who finds a lost laptop gets.
People often expect more from a VPN than it gives. A VPN sends all traffic through an encrypted tunnel to its own server, so the Wi-Fi owner and the provider see only the tunnel. In exchange, the list of sites you visit becomes visible to the company that runs the VPN. The observer does not go away, it is replaced by one you chose yourself.
All these cases come down to one rule: encryption protects against those who do not have the key and does not protect against whoever holds it. So the first thing to find out about any service or device is who has the key. This is usually described in the documentation, and the answer says more than the word “encrypted”.
Sources
- NIST SP 800-63B: requirements for passwords and authenticationstandard
- CISA: phishing-resistant multi-factor authenticationPDF
- Passkeys: how passkeys workdeveloper guide
- Verizon Data Breach Investigations Reportannual breach statistics
- EFF Surveillance Self-Defensesetup guides
- CERT-UA · Cyber Police of Ukrainewhere to report in Ukraine