Brytalearn.How things workFind something
Phishing, fake messages and account security Feedback on this lesson
Sign in to save
INTERACTIVE EXPLANATION

How can a fake message put an account at risk?

Peel a familiar-looking message away from its destination. Take apart real URL structure, compare passwords, codes and passkeys, and discover why checking through a known route changes the evidence.

Enable JavaScript to change the conditions and run the interactive experiment.

Make a discovery

A message can look familiar while pointing somewhere else. Its appearance, its destination and the protection used to sign in are different pieces of evidence. Change one while holding the others still.

  • Distinguish a message’s appearance from its destination.
  • Identify a complete hostname and explain what a URL parser cannot tell you.
  • Separate HTTPS connection protection from trust in a request.
  • Use a route established independently to check an unexpected message.
  • Explain different boundaries for passwords, codes and passkeys.
  • Distinguish a browser’s RP-domain check from the service’s origin and challenge checks.
  • Respond to a mistake with practical help rather than blame.

Make a prediction

The notice looks exactly the same, but its hostname changes. What did keeping the design unchanged prove?

  • The destinations are equally trustworthy
  • Only that the appearance stayed the same
  • That a password would go to the same receiver
Read the explanation

Appearance was the controlled variable. It did not establish the destination or its operator.

Understand it

The front can stay the same

Change the destination while keeping the club notice unchanged. The page picture is a claim; it does not establish where the request leads.

An address has structure

The hostname identifies the named host. Path and query text have other roles. Our native URL parser reveals those parts; it does not determine who owns or operates a real site.

A protected connection has an endpoint

HTTPS protects transport to a destination. An encrypted connection to a dishonest receiver does not make its request honest.

Find evidence by another route

In this story, the club page was established before the message arrived. Checking that saved reference changes the source of your evidence. A newly supplied link is not independent just because it says “help.”

Change the protection

A typed password can be handed to a page. Another factor can prevent a password alone from completing sign-in. A passkey uses scoped public-key proof, giving it a different phishing boundary from manually typed codes.

Look closer at the science

Hostname and origin are different

For ordinary HTTP(S), an origin combines scheme, host and port. The same hostname with port 8443 is a different origin from default HTTPS. A path change normally does not change that origin.

Parsing is not reputation

We compare full hostnames against fixed fictional examples. Taking only the last two labels is not a universal registration rule: public suffixes vary. The parser’s normalized output can also differ from the original spelling.

Credentials have a scope

Our fixed RP ID is club.example. The browser permits this registered parent-domain request from club.example or an eligible subdomain, with HTTPS required here. Newer related-origin mechanisms exist; this base model omits them.

The service performs separate checks

An eligible request is not automatic acceptance. The service checks its allowed origin, the expected challenge and the signature, among other requirements. Our gates show a selected subset as explicit booleans, not a conforming WebAuthn implementation.

A fingerprint is not the passkey

A local PIN or biometric check can authorize use of a credential. The website receives public-key evidence, not a fingerprint image. Our main view shows a device-bound example; synced passkeys can be available through a credential manager on other devices.

Why codes still help, and where they differ

The password-only comparison assumes the other factor remains unavailable. That can stop sign-in with an exposed password. A manually entered code can still be handed to an impostor and relayed while valid; different MFA methods should not be treated as one mechanism.

The page can submit elsewhere

A real form’s action determines its submission destination. Our exercise deliberately fixes it to the displayed page origin. It does not teach that every form submits only to the address shown in the bar.

Interface cues need evidence too

A 2019 field experiment and surveys found little benefit from the particular identity-indicator changes tested. This was not a trial of Brytalearn or children’s learning. Highlighting a domain cannot guarantee that a learner will identify every attack.

Where this is used

Game clubs and group projects

An unexpected invitation can look familiar. Pause to inspect where it leads and check through the group’s established route.

A password manager or passkey option

Different tools bind information to destinations differently. This lesson explains the mechanisms; account setup, recovery and provider support need their own instructions.

Helping after a mistake

Stop the interaction and use the real service’s support or recovery guidance. For younger learners, involve a trusted adult. No one needs to solve a confusing request alone.

Try it yourself: The message, the address and the separate clue

Supplies

  • Two sheets of paper
  • Pencil or washable markers
  • Six folded paper cards
  • The illustrated learning pack
  • Optional: the device already showing this lesson
  1. Make two imaginary places

    Label two areas club.example and other.test. Draw the same friendly club emblem above each. Mark both imaginary.

  2. Keep a separate reference

    Place a card off to one side: “Before this message, our story established https://club.example as the club page.” Its separate origin is a stated premise.

  3. Predict, then uncover

    Write “A project update is ready” on a folded card. Put one fictional destination under the flap. Predict what the front alone tells you, then unfold it.

  4. Change one thing

    Repeat with the same art and a different destination; then change the art while keeping the destination. Record appearance and destination separately.

  5. Observe the browser, optionally

    Expand the real browser’s address bar for this already-open lesson. Identify the hostname, then compare that control with a picture of an address bar inside a page. The paper-only alternative uses the pack’s labeled cutaway.

Which evidence came from the incoming card, and which was established separately?

Use only the fictional paper cards. No accounts, credentials, pasted links or messages to other people are needed. The optional browser observation uses this already-open lesson. This exercise does not prove a real site is uncompromised.

Check your understanding

The club picture stays the same while the parsed hostname changes to other.test. What changed?

  • Only the picture
  • The destination named by the URL
  • Proof that both pages have the same owner
Answer and explanation

The destination named by the URL Compare the complete destination strip. The picture and the parsed hostname are separate observations.

In https://club.example/projects/other.example, which is the hostname?

  • club.example
  • other.example
  • Both address-like words
Answer and explanation

club.example The later words are part of the path. Move the words into a different compartment to see their role change.

Both fictional destinations use HTTPS. What can we conclude from that modeled condition?

  • Both requests are honest
  • They are the same destination
  • Transport is protected; the request still needs evidence
Answer and explanation

Transport is protected; the request still needs evidence The protected connection still has a receiver. HTTPS is not a judgment about that receiver’s intentions.

An unexpected message asks you to change something in an account. Which route supplies independent evidence?

  • The help link inside that same message
  • A service route already established separately
  • Replying with a secret code
Answer and explanation

A service route already established separately Check using a route you already know, and ask a trusted adult if needed. A secret is not a question to send back.

Someone knows a password, but the independent second factor remains unavailable. What can MFA change?

  • The password alone can be insufficient
  • Every future request becomes trustworthy
  • Every MFA method becomes equally phishing resistant
Answer and explanation

The password alone can be insufficient This useful protection depends on the stated second-factor condition. Authentication methods still differ.

An unrelated other.test page asks to use the existing club.example passkey. What happens in our base model?

  • The matching logo releases it
  • The RP boundary refuses the request
  • The private key is pasted into the form
Answer and explanation

The RP boundary refuses the request The browser’s configured RP check supplies this boundary. The lesson excludes related-origin configurations.

studio.club.example can request the configured club.example RP, but the service allows only https://club.example. What happens?

  • All subdomains must be accepted
  • The page picture decides
  • The RP check can pass while the service rejects the origin
Answer and explanation

The RP check can pass while the service rejects the origin Eligibility to request a credential and an allowed calling origin are separate checks. Try the subdomain preset.

A friend entered information before noticing something was wrong. What helps next?

  • Blame them so they remember
  • Help them stop and use the real service’s support/recovery route
  • Send the information again as a test
Answer and explanation

Help them stop and use the real service’s support/recovery route Practical help and a trusted adult when needed are more useful than embarrassment. Use the real service’s route.

Sources and model limits

  • This is a closed fictional environment. Reserved addresses stay inert; no real account, password, code, message or passkey prompt is used.
  • A parsed hostname is an observation about syntax, not proof of ownership, honesty or an uncompromised device.
  • Enrollment, form action, HTTPS, RP scope and the service’s allowed origins are explicit story conditions. Real systems can have redirects, federated sign-in and multiple legitimate origins.
  • The fixed suffix comparison is not a general public-suffix validator. Related-origin requests, embedded cross-origin flows and native apps are outside this model.
  • All proof and service checks are simulated. No signature is computed, no attack probability is estimated, and playback seconds are not measured network latency.
  • Authentication does not secure every recovery path, session or later action. An accepted modeled sign-in is not a blanket safety guarantee.
  • Independent security-educator review and learner trials are pending. The exercise does not certify anyone’s ability to detect scams.

Different authentication methods have different phishing boundaries

NIST distinguishes verifier-bound cryptographic authentication from manually entered passwords and OTPs. This supplies the mechanism distinction, not a success-rate estimate.

NIST SP 800-63B-4 · phishing resistance

RP scope and service verification are separate checks

Level 2 Recommendation: selected domain, origin, challenge and signature checks. Our fixed boolean subset is not a protocol implementation.

W3C WebAuthn Level 2

Related origins are an explicit exception outside the base model

Level 3 Candidate Recommendation, May 26, 2026, includes related-origin request mechanisms. Do not interpret the base example as an absolute rule across all supported configurations.

W3C WebAuthn Level 3 · related origins

URL parts come from a defined parser

Native URL parsing supplies normalized scheme, host, port, path and query. Fixed fixture outcomes are checked locally; parsing does not classify trust.

WHATWG URL Standard

Ordinary HTTP(S) origins include scheme, host and port

The tuple definition explains path, scheme and port comparison cases.

WHATWG HTML · origins

Forms may submit to a different destination

Form submission uses its action. Our same-origin form condition is authored and disclosed.

WHATWG HTML · form submission

Registration boundaries are not always the last two labels

Maintainer guidance on public suffixes. This lesson compares full fixed hostnames and does not infer ownership from a suffix.

Public Suffix List maintainers

Demonstration names are reserved

IANA special-use registry includes example and test. No fixture is used to make a network request.

IANA · special-use domain names

HTTPS does not establish the honesty of the endpoint

The Chromium team’s 2023 lock-icon design explanation addresses this distinction. The historical UI is not copied or presented as every current browser.

Chromium · the lock icon

Passkeys can be synced or device-bound

Source-owned explanation of credential options. No adoption or performance claims are used.

FIDO Alliance · passkeys

Check suspicious requests through an independently known route

FTC consumer guidance supports the practical habit and recovery/help links. Our club story and paper activity are original teaching examples.

FTC · recognizing and avoiding phishing

The tested identity indicators had limited benefit

Thompson et al., USENIX Security 2019. Original field and survey research; not a youth training trial or an evaluation of this lesson.

USENIX 2019 · The Web’s Identity Crisis

2014 FIDO 1.0 publication milestone

Issuer-authored December 9, 2014 announcement. Used only as the date and identity of the specifications.

FIDO Alliance · 2014 announcement

Independent subject review is pending.

Read the sources and model assumptions