Face + Gesture Unlock
  1. Face
  2. Live
  3. Hand
  4. ✓Unlocked

Face + Gesture Unlock

This demo uses your camera locally in your browser. No data is uploaded. Face data is stored only in your browser's localStorage and you can delete it anytime.

Waiting for you to start the camera.

Vault Encrypted notes behind the lock

Locked.

Attacker view: what is actually stored in this browser 
(nothing stored yet)

Your secret goes through PBKDF2-SHA256 (600,000 rounds, random salt) to make an AES-256-GCM key. Only the salt, a random IV and the ciphertext are stored. Even if someone bypasses the face check by editing the code, they get this ciphertext, not your notes.

Educational demo. Camera-based face matching can be fooled by photos and is not suitable for real security.

Security lab

Attack it, watch the defences react, read the log. Red team + blue team = purple team.

Red team Try to fool it

  1. Photo attack. Turn the switch below off, then hold a photo of yourself (on your phone) up to the camera. Face matching alone lets it in.
  2. Same photo, liveness on. Turn the switch back on: the photo cannot blink, turn or open its mouth on command, so it fails.
  3. Brute force. Fail 5 times in a minute (someone else's face, or the photo) and watch the lockout and the alert in the log.

Blue team Defences in place

  • Random liveness challenge. 2 of: blink, turn left, turn right, open mouth. The idea behind presentation attack detection (ISO/IEC 30107).
  • Continuous identity. The same face must stay in view during the challenge; swapping faces fails it.
  • Rate limiting. 5 failed attempts in 60 s lock the face step for 30 s. NIST SP 800-63B also caps failed biometric attempts.
  • Protected enrollment. Re-enrolling is only possible after unlocking, so nobody can swap in their own face.
  • Encryption at rest. The vault is AES-256-GCM encrypted with a key derived from your secret; bypassing the lock only reveals ciphertext.
  • Audit trail. Every attempt is logged below and can be exported as ECS-style JSON for a SIEM.

Failed attempts in the last 60 s: 0 / 5

SOC Security events

Kept in memory only (gone when you close the tab). No images or face data, just events and distances.

No events yet.

    Threat model: how could someone get in?
    AttackWithout defencesIn this demoWhat real systems add
    Photo of the owner (print or phone)UnlocksBlocked by the random liveness challengeDepth / infrared cameras (e.g. Face ID)
    Video of the owner (replay)UnlocksUsually blocked: it must do the right random action within 7 sDepth sensing, screen-reflection and texture analysis
    Someone else's face, again and againUnlimited triesRejected by distance; 5 failures lock it for 30 sLockouts that survive a reload, fallback to a passcode
    Enroll your own face over the owner'sTakes overRe-enroll only after unlockingPasscode required to change biometrics
    Edit the JavaScript in DevToolsBypasses everythingPasses the lock (checks run in your browser), but the vault stays encryptedMatching inside secure hardware or on a server
    Copy the vault and guess the secret offlinePlain text, nothing to guessEach guess costs 600,000 PBKDF2 rounds. A 6-digit gesture PIN (15,625 options) still falls in under an hour; a long passphrase does notHardware retry limits (a phone can wipe its keys after 10 wrong passcodes)
    Reload the page to reset the lockoutResetsNot defended: the lockout lives in memoryCounters stored in tamper-resistant storage
    Steal the stored face templateReadable in localStorageOnly 128 numbers, not a photo; delete anytimeEncrypted templates in a secure enclave

    The last three rows are the honest part: a browser demo can show the ideas, but anything that runs fully on the client can be changed by the client.