2Bme: Know Who's Really at the Keyboard

Your session can stay the same even when the person using it changes. 2Bme looks for that change.

Inspiration

2Bme started with something that happened to my grandmother.

She received a call from someone pretending to be an Amazon employee. He convinced her that there was a problem with her account and persuaded her to give him remote access to her laptop. Once he was inside, he was able to navigate her already-authenticated computer and ultimately transfer money into a blockchain account.

What stuck with us was that, from the computer's perspective, almost nothing looked wrong.

She had legitimately logged into the device. Her accounts were already authenticated. The browser session was valid. Once another person took control of that session, the applications she was using had very little way of knowing that the human behind the keyboard had changed.

That made us ask a different security question:

What if a computer could recognize not just who logged in, but whether the person using the session still behaved like its owner?

That question became 2Bme.

Instead of relying only on passwords, cookies, or one-time authentication events, we wanted to explore whether a computer could continuously learn the behavioral patterns of its owner — how they type, move their mouse, scroll, pause, and switch between tasks — and notice when those patterns suddenly change.

And importantly, we wanted to do it without reading what the person types or tracking what they are doing.

Our goal became:

Detect when the human behind an authenticated session changes, then ask for stronger verification before something important happens.

If a system like this had been running during our grandmother's scam, the goal would not have been to magically know that the caller was a scammer. It would have been to recognize that the behavior controlling the authenticated session had changed and require another form of verification before a sensitive action could continue.

That's the problem 2Bme is trying to solve.

What it does

2Bme learns a user's behavioral fingerprint from the way they interact with their computer.

We analyze privacy-safe signals including:

  • keystroke timing and typing cadence
  • key-hold and inter-key latency
  • mouse velocity, acceleration, and trajectory
  • scrolling behavior
  • idle patterns
  • task and application switching timing

These signals are combined into a continuously updating trust score.

During normal use, the score stays high. If another person begins using the same authenticated computer and their interaction patterns differ from the owner's baseline, trust begins to fall.

Importantly, behavior alone never blocks the user.

Instead, behavioral changes trigger step-up authentication when something sensitive happens. In our demo, an intruder attempts a $50 checkout after taking over an authenticated session. 2Bme notices the behavioral shift and pauses the transaction for either:

  • a voice identity challenge, or
  • a TOTP one-time code.

If verification fails, our desktop overlay can lock the device.

This allows normal activity to remain frictionless while adding verification when both behavioral risk and action risk are high.

Privacy by design

Behavioral biometrics can easily become invasive, so privacy became one of the most important constraints of the project.

2Bme measures how you interact, not what you are doing.

We do not record:

  • typed text or passwords
  • clipboard contents
  • document contents
  • URLs or window titles
  • the actual keys a user presses

Keyboard events are transformed locally into timing-based categories and discarded. Only aggregated statistics — such as median inter-key timing for a block of activity — leave the laptop.

We even built a "What left this laptop" view so users can see exactly which behavioral features are being transmitted.

How we built it

2Bme is an end-to-end system spanning local behavioral capture, machine learning, cloud infrastructure, authentication, and user interfaces.

Behavioral capture

A lightweight macOS agent built with Python and PyObjC observes keyboard, mouse, scrolling, idle behavior, and application-switch timing.

Raw interaction events are transformed locally into roughly 80 privacy-safe behavioral features.

Behavioral ML

Instead of training a traditional classifier that requires examples from thousands of people, we use an owner-specific, one-class model.

The model learns what normal behavior looks like for one user and detects deviations from that baseline.

We combine behavioral models with cross-conformal scoring and a fusion engine that weighs each modality according to the amount of evidence available.

This produces a continuously updating trust estimate rather than a simple "owner / intruder" classification.

Our /lab interface exposes the ML evaluation directly, including modality-level performance, ablations, and detection timing.

Real-time infrastructure

The laptop streams behavioral feature blocks through a secure WebSocket to our backend.

Our backend runs on Vultr using FastAPI, where the trust engine performs real-time scoring and returns an updated trust value approximately every five seconds.

For historical analysis, Tiger Data / TimescaleDB stores behavioral and trust events as time-series data using hypertables, compression, and continuous aggregates.

This lets us reconstruct how trust changed throughout a session without putting the database in the latency-sensitive scoring path.

Step-up authentication

When trust drops during a sensitive action, 2Bme can request additional verification.

Our voice challenge uses ElevenLabs to generate a random phrase and ElevenLabs Scribe for transcription. We combine the challenge with speaker embeddings, spectral/DSP features, and an anti-spoofing model to experiment with detecting both incorrect speakers and synthetic voices.

A TOTP code provides a fallback when voice verification is unavailable.

User experience

We built:

  • a Next.js web dashboard
  • a live trust gauge
  • behavioral explanations
  • a $2,000 checkout simulation
  • a voice verification flow
  • trust history
  • a security-team admin dashboard
  • an Electron desktop overlay
  • a full-screen device lock flow

The result is not just a behavioral ML model — it is a working pipeline from human interaction → behavioral inference → security decision → user action.

Challenges we ran into

Separating identity signals from normal behavioral variation

People do not type or move a mouse exactly the same way every time.

They get tired. They switch tasks. They use different applications. Sometimes there simply isn't enough interaction data to make a confident decision.

That forced us to stop thinking of behavioral biometrics as a binary classifier and instead build around accumulating evidence and continuously changing trust.

Avoiding privacy-invasive features

Some of the easiest behavioral signals to collect would also reveal what a user is doing.

We deliberately restricted ourselves to timing and motion statistics, which made feature engineering harder but produced a system much closer to the privacy guarantees we would want from a real product.

Connecting everything in real time

The project spans a macOS monitoring agent, feature extraction, ML inference, WebSockets, a cloud backend, a time-series database, voice verification, a web application, and a desktop overlay.

Getting all of those pieces to behave like one continuous security system rather than separate hackathon demos was one of our biggest engineering challenges.

Evaluating behavioral identity with limited data

Behavioral authentication ultimately requires significant longitudinal data across users, devices, environments, and conditions.

During a hackathon, we could only collect a small set of real recordings.

Our current evaluation is therefore preliminary, and we intentionally distinguish measured results from scripted presentation scenarios rather than presenting demo behavior as proven model accuracy.

Accomplishments that we're proud of

We're most proud that 2Bme became an end-to-end system rather than just an idea or ML notebook.

During the hackathon we built:

  • real behavioral capture on macOS
  • owner enrollment and model training
  • continuous behavioral scoring
  • live anomaly explanations
  • real-time cloud communication
  • time-series behavioral history
  • voice and TOTP step-up verification
  • a risk-aware checkout flow
  • an on-device security overlay
  • device locking
  • a security-team monitoring interface

Seeing one person use the computer, hand it to someone else, and watching the system react to that behavioral change made the original idea tangible.

What we learned

The biggest thing we learned is that continuous identity is not the same thing as continuous authentication.

A behavioral model should not constantly ask:

"Is this definitely Pranav?"

Instead, it should ask:

"How consistent is the evidence we're seeing with the behavior we've learned from this user?"

That distinction completely changed our architecture.

It led us toward trust scores instead of hard classifications, multiple behavioral modalities instead of one metric, and step-up authentication instead of automatically locking users whenever something looks unusual.

We also learned how important privacy constraints are when working with behavioral data. Designing the system around those constraints from the beginning influenced everything from our feature engineering to our UI.

What's next for 2Bme

The biggest next step is validation.

We want to collect longer behavioral sessions from more users and measure:

  • false acceptance and rejection rates
  • time-to-detection during real takeovers
  • which behavioral features remain stable over days and weeks
  • which features are most distinctive between users
  • how behavior changes across applications and devices
  • how accessibility needs affect behavioral models

From there, we want to explore adaptive multimodal models that learn which signals are most reliable for each individual.

Longer term, we see 2Bme becoming a behavioral security layer that applications can query when deciding whether a sensitive action should proceed:

The password tells you who logged in.
2Bme asks whether they're still the one at the keyboard.

Built With

Share this project:

Updates

Submission history