From e57d9fc2163e5d3fabb771fc37bf7d2c5da44880 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Fri, 12 Sep 2025 14:18:45 -0700 Subject: [PATCH 01/15] Draft phishing article --- .../security/attacks/phishing/TOTP-phish.svg | 3 + .../web/security/attacks/phishing/index.md | 87 +++++++++++++++++++ 2 files changed, 90 insertions(+) create mode 100644 files/en-us/web/security/attacks/phishing/TOTP-phish.svg create mode 100644 files/en-us/web/security/attacks/phishing/index.md diff --git a/files/en-us/web/security/attacks/phishing/TOTP-phish.svg b/files/en-us/web/security/attacks/phishing/TOTP-phish.svg new file mode 100644 index 000000000000000..dfe0d9ef2944914 --- /dev/null +++ b/files/en-us/web/security/attacks/phishing/TOTP-phish.svg @@ -0,0 +1,3 @@ + + +
User
Fake site:
my-bank.examp1e.com
Real site:
my-bank.example.com
Phishing email
Enter username+password
Enter username+password
Calculate TOTP
Request TOTP
Request TOTP
Calculate TOTP
Enter TOTP
Enter TOTP
Success!
Set session cookie 
 \ No newline at end of file diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md new file mode 100644 index 000000000000000..119f1b4292b7456 --- /dev/null +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -0,0 +1,87 @@ +--- +title: Phishing +slug: Web/Security/Attacks/Phishing +page-type: guide +sidebar: security +--- + +Phishing is a social engineering attack which a user is tricked into believing that are interacting with a site with which they have an account, when in reality they are interacting with the attacker. The attacker convinces the user to enter their credentials on the fake site, and thereby steals the user's credentials. + +## Overview + +Phishing is a very old but still very common attack, which has gone through many variations, both to evade defenses and to take advantage of new vulnerabilities. In a basic form, though: + +1. The attacker registers a domain name that resembles the target site. For example, if the user's banking website is `my-bank.example.com`, the attacker could register `my-bank-examp1e.com`. +2. The attacker creates a site at that address that resembles the real site. +3. The attacker sends the user an email, purporting to be from `my-bank.example.com`, giving some reason to ask the user to visit the site, and containing a link to the fake site `my-bank-examp1e.com`. +4. The user clicks the link and is asked to sign in. They enter their username and password, and the attacker now has their credentials. + +Phishing attacks sometimes use different techniques to contact their victims, such as text messages or voice calls, and sometimes don't involve websites at all, convincing users to tell them passwords or PIN codes verbally. + +Some phishing attacks are highly indiscriminate, sending out many messages to potential victims, in the hope that some will be tricked. In _spear-phishing_ attacks, on the other hand, attackers research specific victims, gathering personal information about them to make the lure more convincing. For example, the email may purport to come from someone the victim knows, and even include private information. + +Phishing attacks are not dependent on naive or inexperienced users: decades of experience has shown that even highly experienced and knowlegeable users can be vulnerable to phishing attacks, especially when they are busy, tired, or distracted. + +## Defenses + +One thing that makes phishing challenging for a website to defend against is that the target site is not involved at all in the attack. It's entirely dependent on the user being tricked by the attacker. In this section we will discuss some practices that can help, but the only one that is really effective is using [passkeys](web_authentication_passkeys) instead of passwords. + +### Password managers + +Password managers can provide some degree of protection against phishing attacks. They fulfill three main functions: + +- **Password generation**: Creating strong passwords when users sign up. +- **Password storage**: Storing a user's passwords securely, so the user doesn't have to remember them (and can therefore use stronger passwords) +- **Password entry**: Automatically entering the user's password for a site, when the user visits the site's login page. + +It's the last of these that can help against phishing. The user might not see the difference between the fake domain `my-bank-examp1e.com` and the real domain `my-bank-example.com`, but the password manager will, and as a result it will not automatically enter the real password on the fake site. With luck, this will be enough of a warning to the user that the login request is not legitimate. + +As a web developer, you can't make your users use a password manager. But you can, if you are not careful, make it impossible for password managers to integrate with your site. The article [Making password managers play ball with your login form](https://hidde.blog/making-password-managers-play-ball-with-your-login-form/) is an excellent summary of practices to follow, and practices to avoid, if you want users to be able to use password managers on your site. It's also important to test your site with password managers, both those built into browsers and popular standalone applications. + +Unfortunately, users have been trained to expect tools to fail sometimes, and to work around their failures. So even if a user has a password manager, and it works with your site, and it does not auto-fill the password during a phishing attempt, you still have no guarantee that the user will not just paste the password in manually. + +### Multi-factor authentication + +Using {{glossary("multi-factor authentication", "multi-factor authentication (MFA)")}} to authenticate users makes phishing more difficult but, depending on the specific method used, does not prevent it. + +In particular, in the most common MFA implementations, the user has to enter their password and another code, called a _one-time password_ (OTP), which is unique to this login attempt. Two common variants are: + +- SMS-based OTP: + - The user provides their cellphone number when they register. + - After the user has supplied their username and password, the website sends an SMS to the user which contains an OTP. + - The user enters the OTP. + - If the OTP values match, the user is signed in. + +- Time-based OTP (TOTP): + - The user has an authenticator app installed. + - After the user has supplied their username and password, the website calculates an OTP using the current time as input. + - The user's authenticator does the same calculation, and the user enters the OTP that the app generated. + - If the OTP values match, the user is signed in. + +TOTP is considered more secure than SMS-based OTP, because it is possible for attackers to intercept SMS messages. However, from the point of view of phishing, both methods are vulnerable. + +To phish a user who uses OTP as a second factor, the attacker's fake site is an active manipulator in the middle, between the user and the real site: + +1. The attacker sends the user the email, containing the link to the fake site. +2. The user clicks the link in the email, and enters their username and password in the fake site. +3. The fake site relays the username and password to the real site. +4. The real site generates a TOTP. +5. The fake site asks the user to enter their TOTP. +6. The user's authenticator app generates the same TOTP, and the user enters it on the fake site. +7. The fake site relays the TOTP to the real site, and the attacker is given access. + +![](TOTP-phish.svg) + +This is much more difficult than just phishing a password, because the attacker must operate in real time. However, phishing toolkits greatly reduce the complexity of accomplishing it. + +### Web Authentication (passkeys) + +The strongest technical defense against phishing is to authenticate users with _passkeys_, which are based on the [Web Authentication API](/en-US/docs/Web/API/Web_Authentication_API). + +Unlike passwords or OTP codes, a user never manually enters a passkey on a site. When a web page asks the user to authenticate using Web Authentication, the browser finds applicable passkeys, and asks the user to authenticate themselves to the module on their device which manages the passkeys (for example using their fingerprint or a PIN). If this is successful, then the browser uses the passkey to sign into the site. + +A passkey is specific to the {{glossary("origin")}} for which it was originally created. So if a passkey was created for the user's account at `my-bank.example.com`, the user will not be able to use it on `my-bank.examp1e.com` — the browser just won't consider it applicable to the fake site. + +This means that passkeys are an effective defense against phishing. + +## Defense summary checklist From 04c6b62ae96beab0590e106687eb42cc9db9658a Mon Sep 17 00:00:00 2001 From: wbamberg Date: Fri, 12 Sep 2025 14:22:01 -0700 Subject: [PATCH 02/15] alt text --- files/en-us/web/security/attacks/phishing/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index 119f1b4292b7456..26cb20a17d11997 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -70,7 +70,7 @@ To phish a user who uses OTP as a second factor, the attacker's fake site is an 6. The user's authenticator app generates the same TOTP, and the user enters it on the fake site. 7. The fake site relays the TOTP to the real site, and the attacker is given access. -![](TOTP-phish.svg) +![Diagram showing how a phishing attack can work against 2-factor TOTP authentication](TOTP-phish.svg) This is much more difficult than just phishing a password, because the attacker must operate in real time. However, phishing toolkits greatly reduce the complexity of accomplishing it. From 99189651666a202750d259efe281a9b26cb173e9 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Fri, 12 Sep 2025 14:24:52 -0700 Subject: [PATCH 03/15] lowercase filename --- files/en-us/web/security/attacks/phishing/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index 26cb20a17d11997..c75743d54a847b0 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -70,7 +70,7 @@ To phish a user who uses OTP as a second factor, the attacker's fake site is an 6. The user's authenticator app generates the same TOTP, and the user enters it on the fake site. 7. The fake site relays the TOTP to the real site, and the attacker is given access. -![Diagram showing how a phishing attack can work against 2-factor TOTP authentication](TOTP-phish.svg) +![Diagram showing how a phishing attack can work against 2-factor TOTP authentication](totp-phish.svg) This is much more difficult than just phishing a password, because the attacker must operate in real time. However, phishing toolkits greatly reduce the complexity of accomplishing it. From 1c2181ae14f330de17c61e0c6d24ab75c2d6cc39 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 09:16:19 -0700 Subject: [PATCH 04/15] Rename SVG --- .../security/attacks/phishing/{TOTP-phish.svg => totp-phish.svg} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename files/en-us/web/security/attacks/phishing/{TOTP-phish.svg => totp-phish.svg} (100%) diff --git a/files/en-us/web/security/attacks/phishing/TOTP-phish.svg b/files/en-us/web/security/attacks/phishing/totp-phish.svg similarity index 100% rename from files/en-us/web/security/attacks/phishing/TOTP-phish.svg rename to files/en-us/web/security/attacks/phishing/totp-phish.svg From 7150c1d4692612986286a75a2e2216edd1b5fe5d Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 14:56:34 -0700 Subject: [PATCH 05/15] Updates to passkey section --- files/en-us/web/security/attacks/phishing/index.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index c75743d54a847b0..a04aed637d773e8 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -76,12 +76,16 @@ This is much more difficult than just phishing a password, because the attacker ### Web Authentication (passkeys) -The strongest technical defense against phishing is to authenticate users with _passkeys_, which are based on the [Web Authentication API](/en-US/docs/Web/API/Web_Authentication_API). +The strongest technical defense against phishing is to authenticate users using _passkeys_, which are based on the [Web Authentication API](/en-US/docs/Web/API/Web_Authentication_API). -Unlike passwords or OTP codes, a user never manually enters a passkey on a site. When a web page asks the user to authenticate using Web Authentication, the browser finds applicable passkeys, and asks the user to authenticate themselves to the module on their device which manages the passkeys (for example using their fingerprint or a PIN). If this is successful, then the browser uses the passkey to sign into the site. +A passkey is created when the user registers on the site, and is specific to the {{glossary("origin")}} for which it was originally created. -A passkey is specific to the {{glossary("origin")}} for which it was originally created. So if a passkey was created for the user's account at `my-bank.example.com`, the user will not be able to use it on `my-bank.examp1e.com` — the browser just won't consider it applicable to the fake site. +Unlike passwords or OTP codes, a user never manually enters a passkey on a site: in fact, the passkey is never transmitted to the site at all. The passkey is kept in a module called an _authenticator_, which is built into or attached to the user's device. -This means that passkeys are an effective defense against phishing. +When a web page asks the user to authenticate using Web Authentication, the browser asks the authenticator for an applicable passkey. If it can find one, the authenticator generates a token which the browser sends to the website. The website verifies the token and signs the user in. -## Defense summary checklist +Because the passkey is specific to the site's origin, if a passkey was created for the user's account at `my-bank.example.com`, the user will not be able to use it on `my-bank.examp1e.com`. The browser just won't consider it applicable to the fake site. + +This makes passkeys an effective defense against phishing. + +### Defense summary checklist From fd7a52ca24268c599e0835f727aacc2693b718c9 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 15:26:18 -0700 Subject: [PATCH 06/15] More updates to passkey section --- files/en-us/web/security/attacks/phishing/index.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index a04aed637d773e8..76bba5840b0c7d9 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -78,14 +78,15 @@ This is much more difficult than just phishing a password, because the attacker The strongest technical defense against phishing is to authenticate users using _passkeys_, which are based on the [Web Authentication API](/en-US/docs/Web/API/Web_Authentication_API). -A passkey is created when the user registers on the site, and is specific to the {{glossary("origin")}} for which it was originally created. +A passkey is created when the user registers on the site, and is specific to the {{glossary("origin")}} for which it was originally created. The passkey is generated by, and stored in, a module called an _authenticator_, which is built into or attached to the user's device. -Unlike passwords or OTP codes, a user never manually enters a passkey on a site: in fact, the passkey is never transmitted to the site at all. The passkey is kept in a module called an _authenticator_, which is built into or attached to the user's device. - -When a web page asks the user to authenticate using Web Authentication, the browser asks the authenticator for an applicable passkey. If it can find one, the authenticator generates a token which the browser sends to the website. The website verifies the token and signs the user in. +Unlike passwords or OTP codes, a user never manually enters a passkey on a site: in fact, the passkey is never transmitted to the site at all. When a website asks the user to authenticate using Web Authentication, the browser asks the authenticator for a passkey that matches the site's origin. If it can find one, the authenticator generates a token which the browser sends to the website. The website verifies the token and signs the user in. Because the passkey is specific to the site's origin, if a passkey was created for the user's account at `my-bank.example.com`, the user will not be able to use it on `my-bank.examp1e.com`. The browser just won't consider it applicable to the fake site. -This makes passkeys an effective defense against phishing. +This makes passkeys an effective defense against phishing. Passkeys are a much newer authentication method than passwords or OTP, and the tooling surrounding them is less mature. However, this is changing, and passkeys may eventually displace passwords as the most common authentication method on the web. ### Defense summary checklist + +- Consider using passkeys to authenticate users. +- If you use passwords, consider using MFA, and ensure that password managers can work with your site. From 5e742efbf77d520b1c6395dc6515006eca589558 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 15:36:47 -0700 Subject: [PATCH 07/15] typoes --- files/en-us/glossary/social_engineering/index.md | 0 files/en-us/web/security/attacks/phishing/index.md | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) create mode 100644 files/en-us/glossary/social_engineering/index.md diff --git a/files/en-us/glossary/social_engineering/index.md b/files/en-us/glossary/social_engineering/index.md new file mode 100644 index 000000000000000..e69de29bb2d1d64 diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index 76bba5840b0c7d9..6da81a4a1652eb0 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -5,7 +5,7 @@ page-type: guide sidebar: security --- -Phishing is a social engineering attack which a user is tricked into believing that are interacting with a site with which they have an account, when in reality they are interacting with the attacker. The attacker convinces the user to enter their credentials on the fake site, and thereby steals the user's credentials. +Phishing is a social engineering attack in which a user is tricked into believing that they are interacting with a site with which they have an account, when in reality they are interacting with the attacker. The attacker convinces the user to enter their credentials on the fake site, and thereby steals the user's credentials. ## Overview From 708e772c475d079fcd2bad8bd8761667bdebd517 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 15:39:48 -0700 Subject: [PATCH 08/15] drafting se glossary page --- files/en-us/glossary/social_engineering/index.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/files/en-us/glossary/social_engineering/index.md b/files/en-us/glossary/social_engineering/index.md index e69de29bb2d1d64..83993cd66b71b65 100644 --- a/files/en-us/glossary/social_engineering/index.md +++ b/files/en-us/glossary/social_engineering/index.md @@ -0,0 +1,8 @@ +--- +title: Social engineering +slug: Glossary/Social_engineering +page-type: glossary-definition +sidebar: glossarysidebar +--- + +In computer security, a **social engineering**... From 889c2ba8d861fff88a0e712e505ab525a9740e03 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 15:47:37 -0700 Subject: [PATCH 09/15] more typoes --- files/en-us/glossary/social_engineering/index.md | 2 +- files/en-us/web/security/attacks/phishing/index.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/files/en-us/glossary/social_engineering/index.md b/files/en-us/glossary/social_engineering/index.md index 83993cd66b71b65..5219af36e542022 100644 --- a/files/en-us/glossary/social_engineering/index.md +++ b/files/en-us/glossary/social_engineering/index.md @@ -5,4 +5,4 @@ page-type: glossary-definition sidebar: glossarysidebar --- -In computer security, a **social engineering**... +In computer security, **social engineering** is a technique in which an attacker psychologically manipulates users into harmful actions, such as divulging their {{glossary("credential", "credentials")}} or other sensitive information. diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index 6da81a4a1652eb0..55133b6aa388075 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -5,15 +5,15 @@ page-type: guide sidebar: security --- -Phishing is a social engineering attack in which a user is tricked into believing that they are interacting with a site with which they have an account, when in reality they are interacting with the attacker. The attacker convinces the user to enter their credentials on the fake site, and thereby steals the user's credentials. +Phishing is a {{glossary("social engineering")}} attack in which a user is tricked into believing that they are interacting with a site with which they have an account, when in reality they are interacting with the attacker. The attacker convinces the user to enter their credentials on the fake site, and thereby steals the user's credentials. ## Overview Phishing is a very old but still very common attack, which has gone through many variations, both to evade defenses and to take advantage of new vulnerabilities. In a basic form, though: -1. The attacker registers a domain name that resembles the target site. For example, if the user's banking website is `my-bank.example.com`, the attacker could register `my-bank-examp1e.com`. +1. The attacker registers a domain name that resembles the target site. For example, if the user's banking website is `my-bank.example.com`, the attacker could register `my-bank.examp1e.com`. 2. The attacker creates a site at that address that resembles the real site. -3. The attacker sends the user an email, purporting to be from `my-bank.example.com`, giving some reason to ask the user to visit the site, and containing a link to the fake site `my-bank-examp1e.com`. +3. The attacker sends the user an email, purporting to be from `my-bank.example.com`, giving some reason to ask the user to visit the site, and containing a link to the fake site `my-bank.examp1e.com`. 4. The user clicks the link and is asked to sign in. They enter their username and password, and the attacker now has their credentials. Phishing attacks sometimes use different techniques to contact their victims, such as text messages or voice calls, and sometimes don't involve websites at all, convincing users to tell them passwords or PIN codes verbally. From 1370849d4d84aff8a7100f0bee2f6aed32c0531a Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 15:48:54 -0700 Subject: [PATCH 10/15] more typoes --- files/en-us/web/security/attacks/phishing/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index 55133b6aa388075..af8e2e034e36d85 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -34,7 +34,7 @@ Password managers can provide some degree of protection against phishing attacks - **Password storage**: Storing a user's passwords securely, so the user doesn't have to remember them (and can therefore use stronger passwords) - **Password entry**: Automatically entering the user's password for a site, when the user visits the site's login page. -It's the last of these that can help against phishing. The user might not see the difference between the fake domain `my-bank-examp1e.com` and the real domain `my-bank-example.com`, but the password manager will, and as a result it will not automatically enter the real password on the fake site. With luck, this will be enough of a warning to the user that the login request is not legitimate. +It's the last of these that can help against phishing. The user might not see the difference between the fake domain `my-bank.examp1e.com` and the real domain `my-bank.example.com`, but the password manager will, and as a result it will not automatically enter the real password on the fake site. With luck, this will be enough of a warning to the user that the login request is not legitimate. As a web developer, you can't make your users use a password manager. But you can, if you are not careful, make it impossible for password managers to integrate with your site. The article [Making password managers play ball with your login form](https://hidde.blog/making-password-managers-play-ball-with-your-login-form/) is an excellent summary of practices to follow, and practices to avoid, if you want users to be able to use password managers on your site. It's also important to test your site with password managers, both those built into browsers and popular standalone applications. From a467cf0e8e685e4daf9cadab4766460167bf3fa4 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Mon, 15 Sep 2025 16:00:16 -0700 Subject: [PATCH 11/15] se glossary page --- files/en-us/glossary/social_engineering/index.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/files/en-us/glossary/social_engineering/index.md b/files/en-us/glossary/social_engineering/index.md index 5219af36e542022..0891347226f7a29 100644 --- a/files/en-us/glossary/social_engineering/index.md +++ b/files/en-us/glossary/social_engineering/index.md @@ -6,3 +6,9 @@ sidebar: glossarysidebar --- In computer security, **social engineering** is a technique in which an attacker psychologically manipulates users into harmful actions, such as divulging their {{glossary("credential", "credentials")}} or other sensitive information. + +For example, in a [phishing](/en-US/docs/Web/Security/Attacks/Phishing) attack, the user thinks that they are signing into a site with which they have an account, when in reality they are giving their login details to a fake site controlled by the attacker. + +Social engineering attacks can be distinguished from other attacks because they do not target vulnerabilities in software or hardware, but target users, causing them to make bad decisions. This can make them hard to defend against, although system design choices can make them less likely to succeed or even effectively impossible. + +Defenses against social engineering attacks often focus on teaching users safe practices, such as not clicking links in emails. However, experience has shown that all users can be vulnerable to social engineering attacks especially when they are tired, busy, or stressed. From fabbbb0c3d5215d77e07572792ca3951a4d0cd19 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Tue, 16 Sep 2025 10:19:18 -0700 Subject: [PATCH 12/15] Add a section on security indicators --- .../web/security/attacks/phishing/index.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index af8e2e034e36d85..d53eec19f91fccc 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -86,6 +86,27 @@ Because the passkey is specific to the site's origin, if a passkey was created f This makes passkeys an effective defense against phishing. Passkeys are a much newer authentication method than passwords or OTP, and the tooling surrounding them is less mature. However, this is changing, and passkeys may eventually displace passwords as the most common authentication method on the web. +### Personalized security indicator + +Another phishing defense, which isn't often used any more, is for the website to display a secret message or image to the user on its login page. + +1. After the user signs up, the user is asked to choose a secret message or image to be associated with their account. +2. When the user signs in, they first enter their username. +3. The login page then shows the secret associated with the account. +4. If the secret is not what the user expected, then the user should not enter their password. + +The idea is that the attacker doesn't know what the secret is, so can't display it on the fake login page. + +In a variation of this technique, the website uses a persistent cookie to decide which secret to display, instead of the username. + +In practice there are a few difficulties with this technique: + +- It relies on the user paying attention to the security indicator: that is, it relies on user education. Experience has shown that as a general principle (that is, out of a controlled context such as a securely managed corporation) user education is not very effective in preventing phishing attacks. +- Depending on the mechanism used to decide which secret to display, it may be vulnerable to the same manipulator in the middle attack as MFA. +- The mechanism the server uses to decide which secret to display may be vulnerable: for example, it may be easier for an attacker to discover a username than to discover a password. With a username, an attacker could determine the secret and build a convincing fake site. + +As a result of these weaknesses, this defense is rarely used: both MFA and passkeys are considered to be stronger defenses. + ### Defense summary checklist - Consider using passkeys to authenticate users. From 757302261c74e5b1c445d6b924d03aad5836250c Mon Sep 17 00:00:00 2001 From: wbamberg Date: Tue, 16 Sep 2025 10:39:53 -0700 Subject: [PATCH 13/15] Add entry in Attacks page --- files/en-us/web/security/attacks/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/files/en-us/web/security/attacks/index.md b/files/en-us/web/security/attacks/index.md index 8dcca335ab6176b..19bd72b898825cd 100644 --- a/files/en-us/web/security/attacks/index.md +++ b/files/en-us/web/security/attacks/index.md @@ -19,6 +19,8 @@ This page links to pages explaining how some common attacks work, and how they c - : In a cross-site scripting (XSS) attack, a website accepts some input crafted by the attacker and mistakenly includes this input in the site's own pages in a way that makes the browser execute it as code. The malicious code can then do anything that the site's own front-end code could do. - [Manipulator in the Middle (MITM)](/en-US/docs/Web/Security/Attacks/MITM) - : In a Manipulator in the Middle (MITM) attack, the attacker inserts themselves between the user's browser and the server, and can see and potentially modify any of the traffic exchanged over HTTP. +- [Phishing](/en-US/docs/Web/Security/Attacks/Phishing) + - : Phishing is a {{glossary("social engineering")}} attack in which the attacker steals a user's {{glossary("credential", "credentials")}} by tricking them into believing they are signing into the target site, when in reality they are interacting with a fake site controlled by the attacker. - [Server Side Request Forgery (SSRF)](/en-US/docs/Web/Security/Attacks/SSRF) - : Server‑Side Request Forgery (SSRF) is a vulnerability that allows an attacker to make HTTP (or other network) requests to arbitrary destinations. SSRF makes these requests originate from within a server itself, which typically has broader access than an external client. - [Subdomain takeover](/en-US/docs/Web/Security/Attacks/Subdomain_takeover) From 87fd3d46df4610ba7ce186b5d36d70a97d3eb08c Mon Sep 17 00:00:00 2001 From: wbamberg Date: Wed, 17 Sep 2025 08:36:47 -0700 Subject: [PATCH 14/15] Update files/en-us/web/security/attacks/phishing/index.md Co-authored-by: Florian Scholz --- files/en-us/web/security/attacks/phishing/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index d53eec19f91fccc..62cafa9c1ce64a0 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -20,7 +20,7 @@ Phishing attacks sometimes use different techniques to contact their victims, su Some phishing attacks are highly indiscriminate, sending out many messages to potential victims, in the hope that some will be tricked. In _spear-phishing_ attacks, on the other hand, attackers research specific victims, gathering personal information about them to make the lure more convincing. For example, the email may purport to come from someone the victim knows, and even include private information. -Phishing attacks are not dependent on naive or inexperienced users: decades of experience has shown that even highly experienced and knowlegeable users can be vulnerable to phishing attacks, especially when they are busy, tired, or distracted. +Phishing attacks are not dependent on naive or inexperienced users: decades of experience has shown that even highly experienced and knowledgeable users can be vulnerable to phishing attacks, especially when they are busy, tired, or distracted. ## Defenses From 2e50854b612f4dd2df1b42638320edbe53adf8bf Mon Sep 17 00:00:00 2001 From: wbamberg Date: Wed, 17 Sep 2025 15:40:03 -0700 Subject: [PATCH 15/15] Add a bit on DNS records --- files/en-us/web/security/attacks/phishing/index.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/files/en-us/web/security/attacks/phishing/index.md b/files/en-us/web/security/attacks/phishing/index.md index 62cafa9c1ce64a0..a873752daac1b2c 100644 --- a/files/en-us/web/security/attacks/phishing/index.md +++ b/files/en-us/web/security/attacks/phishing/index.md @@ -26,6 +26,16 @@ Phishing attacks are not dependent on naive or inexperienced users: decades of e One thing that makes phishing challenging for a website to defend against is that the target site is not involved at all in the attack. It's entirely dependent on the user being tricked by the attacker. In this section we will discuss some practices that can help, but the only one that is really effective is using [passkeys](web_authentication_passkeys) instead of passwords. +### DNS configuration + +Phishing emails often forge the sender address, to make the victim think that the email really came from the target website. Three {{glossary("DNS")}} records help email servers detect these forgeries, which helps ensure that phishing emails are marked as spam in the victim's email client, or are blocked entirely. + +- The [Security Policy Framework (SPF)](https://www.cloudflare.com/en-ca/learning/dns/dns-records/dns-spf-record/) record lists addresses that are allowed to send an email from the domain. A receiving email server extracts the domain name from the email's `Return-Path` header, and looks up the SPF record associated with that domain. +- The [DomainKeys Identified Mail (DKIM)](https://www.cloudflare.com/en-ca/learning/dns/dns-records/dns-dkim-record/) record enables the sender to {{glossary("digital signature", "digitally sign")}} emails. The receiving server extracts the domain name from the signature, and uses it to look up looks up the DKIM record associated with that domain. The DKIM record incldues the public key used to verify the signature. The domain name in the signature must also be aligned with the domain name in the email's `From` header (this essentially means that the domain names must match or the value in ther `From` header must be a subdomain of the domain in the signature). +- The [Domain-based Message Authentication Reporting and Conformance (DMARC)](https://www.cloudflare.com/en-ca/learning/dns/dns-records/dns-dmarc-record/) tells the recipient how to handle SPF and DKIM failures: whether to quarantine them as spam, reject them, or allow them. + +You should set these DNS records for your domains, to help email servers recognize forged messages. + ### Password managers Password managers can provide some degree of protection against phishing attacks. They fulfill three main functions: @@ -109,5 +119,6 @@ As a result of these weaknesses, this defense is rarely used: both MFA and passk ### Defense summary checklist +- Set `SPF`, `DKIM`, and `DMARC` DNS records for your domains. - Consider using passkeys to authenticate users. - If you use passwords, consider using MFA, and ensure that password managers can work with your site.