Abstract

🇬🇧 English Abstract

Before entering a password, a user should know whether the login page or app is real. This article proposes a pre-authentication trust verification framework, where personalized markers (image, phrase, sound, or video) are cryptographically verified before login. Such a system could protect users from phishing and interface spoofing while promoting mutual authentication between user and service.

🇫🇷 Résumé en Français

Avant de saisir son mot de passe, l’utilisateur doit pouvoir vérifier que la page ou l’application est authentique. Cet article propose un cadre de vérification de confiance avant authentification, basé sur des marqueurs personnalisés (image, phrase, son ou vidéo) vérifiés cryptographiquement avant la connexion. Une telle approche renforce la protection contre le phishing et garantit une authentification mutuelle entre l’utilisateur et le service.

1. The Problem: Trust Ends Before It Begins

Today, users are asked to enter their credentials before verifying whether the website, application, or device truly belongs to the legitimate provider.
Phishing websites, fake banking apps, and counterfeit ATMs exploit this blind spot — imitating genuine login pages and collecting users’ passwords or PINs before they even realize the deception.

To counter this, authentication must start before the login form — at the pre-authentication phase — verifying that the interface itself is real.

2. The Concept: Personalized Trust Markers

At registration, the user chooses a personalized trust marker — a secret visual, textual, or auditory cue (for example, a phrase, picture, short sound, or animation).
Before displaying the login form, the legitimate website or application must present this marker — cryptographically verified and linked to the domain or service certificate.
If the marker does not match, or if the system fails to verify its authenticity, the login form is blocked and the user is warned of a potential phishing attempt.

3. How It Works (High-Level Model)

  1. Registration phase
    The user selects a marker.
    The client stores a hash of the marker locally, together with metadata (domain, service ID), using a secure keystore or encrypted storage.

  2. Pre-login challenge
    When the login page is requested, the server sends a signed package containing the marker’s metadata and a cryptographic challenge.

  3. Signature verification
    The client verifies the signature using the public key tied to the site’s TLS certificate, HSM, or WebAuthn attestation.

    • If the signature is valid → the marker is displayed to the user.

    • If invalid → the login form is not shown.

  4. Optional challenge–response
    To ensure freshness, the client may send a random nonce. The server signs it, and the client verifies it before proceeding.

This process creates a cryptographically provable “identity handshake” between user and service — before credentials ever leave the user’s device.

4. Implementation Possibilities

  • TLS-Backed Signature Model:
    Server signs the marker with its TLS private key.
    Fast to implement but vulnerable if certificate authorities (CA) are compromised.

  • WebAuthn/Attestation Model:
    Uses hardware attestation (TPM, HSM).
    Provides strong binding between service and hardware, ideal for critical infrastructure.

  • DNSSEC/DANE Integration:
    Marker authenticity verified via DNSSEC or DANE.
    Offers protection from compromised CAs but requires broader DNSSEC adoption.

  • Browser-Integrated UI or Extension:
    Marker displayed through a Trusted UI layer — outside the DOM — preventing fake sites from mimicking the interface.

  • ATM / POS Example:
    Before inserting a card or entering a PIN, the bank’s app verifies the ATM’s authenticity by checking a signed hardware marker unique to that machine.

5. Usability and Accessibility

To ensure inclusivity and usability:

  • Support visual, audio, and animated markers.

  • Allow secure re-registration or marker change.

  • Provide sync options via encrypted cloud vaults.

  • Include fallback methods (hardware tokens, SMS verification).

  • Emphasize non-intrusive UX with clear “trusted site confirmed” visuals.

6. Security and Limitations

While this system mitigates phishing and interface spoofing, it cannot:

  • Prevent users from ignoring warnings.

  • Eliminate all risks of CA compromise (without DNSSEC/DANE).

  • Guarantee privacy if marker storage or syncing is insecure.

Still, it raises the barrier for attackers, forcing them to compromise not only credentials but also cryptographic authenticity mechanisms.

7. Steps Toward Implementation

  1. Prototype as a browser extension to validate UX and security assumptions.

  2. Implement server-side signing using HSM.

  3. Integrate with WebAuthn and Certificate Transparency for full auditability.

  4. Conduct phishing simulation tests.

  5. Educate users — “No personal marker, no login.”

8. Conclusion

The future of secure authentication lies in mutual verification.
Before a user proves who they are, the system must prove what it is.
By introducing pre-authentication trust markers — personalized, cryptographically verified cues — we can finally ensure that login forms, ATMs, and digital services are not only secure after login, but before it.