Authidenty: You Know Me?

The core rule: the answer pattern selects a candidate, and the enrolled device completes verification.
Live GPT-5.6 Sol match: Danny Kim, a masked phone route, 92% combined score, and a simulated OTP challenge.
Enrollment derives a style vector from three answers and encrypts the phone without storing the raw answer sentences.
The returning user answers three different questions without entering a name or phone number.
Final result: the pattern selected Danny Kim, while the one-time code proved control of the enrolled device.

## Inspiration

Identity checks repeatedly ask people for the same personal information: name, phone number, birthday, document, or selfie. Every new copy creates another privacy and breach risk.

We wanted to test a different question: can an account recognize how a person answers before asking them to repeat who they are?

Our first idea gave the LLM too much authority. Writing style can drift, be observed, or be imitated, so it cannot safely act as the only authenticator. We kept the conversational idea but changed its role: the response pattern selects a likely account, while the enrolled device completes verification.

## What it does

Authidenty asks different questions during enrollment and sign-in.

During enrollment, the user provides a display name, phone number, and three answers. Authidenty derives a small numerical writing-style profile from features such as:

answer length;
lowercase sentence starts;
contractions;
first-person terms;
hedges and connectors;
comma and exclamation usage.

Authidenty does not persist the raw answer sentences. It encrypts the phone number with AES-256-GCM and stores only the derived style vector.

When the user returns, they answer three different questions without entering their name or phone number. Authidenty then:

derives a new style vector;
ranks enrolled profiles with deterministic similarity;
sends only the best enrolled vector, returning vector, and a hashed safety identifier to GPT-5.6 Sol;
receives a structured similarity score and short explanation;
reveals the candidate name and masked phone only after a strong match;
sends a six-digit challenge to the enrolled device;
verifies the code outside GPT.

A weak match reveals no name, phone suffix, or challenge route.

The key security rule is simple:

Pattern selects. Device code verifies.

## How we built it

Authidenty uses:

Next.js 16, React 19, TypeScript, and Tailwind CSS 4;
SQLite with reversible migrations and immediate transactions;
AES-256-GCM encryption for phone destinations;
HMAC-SHA-256 digests for one-time codes;
OpenAI Responses API with GPT-5.6 Sol;
Zod Structured Outputs for bounded model responses;
store: false, no model tools, and no identity data in model input;
SimpleWebAuthn for the retained passkey module;
Vitest and Chromium for automated verification.

The server owns the final match threshold and OTP decision. GPT-5.6 cannot access the encrypted phone vault, send a code, verify a code, or create an authenticated session.

If the model is unavailable, Authidenty uses the deterministic similarity score and labels the result as a conservative fallback.

## Challenges

The main challenge was finding a useful role for an LLM without making it a security authority.

Conversational patterns are probabilistic. A person's writing may change with language, mood, device, disability, or assistive tools. An attacker may also imitate a visible writing style. We therefore use the pattern only to select a candidate and require a separate possession factor.

Privacy created another challenge. Authidenty still needs an enrollment record containing a name and phone number. We encrypt the phone at rest, never send identity fields or raw answers to GPT, reveal only a masked destination, and disclose nothing after a weak match.

Our first demo video also failed to show the product clearly. It technically used the application, but the automated interaction looked like static slides. We rebuilt it with visible typing, cursor movement, live GPT-5.6 analysis, the matched name and phone suffix, and final OTP verification.

## Accomplishments

Built a complete enrollment-to-verification browser journey.
Asked different questions during enrollment and return.
Matched Danny Kim with the masked destination ***-***-0184.
Recorded a combined match score of 0.92 using live GPT-5.6 Sol.
Kept names, phone numbers, raw answers, and OTPs out of the model request.
Added encrypted phone storage, generic weak-match responses, OTP expiry, attempt limits, and replay prevention.
Passed 74 tests across 23 test files.
Completed a clean production build.
Verified live API responses of 201, 201, and 200.
Recorded the browser journey with zero console errors.

## What we learned

An LLM can evaluate and explain a bounded identity signal without controlling authentication.

We also learned that reducing repeated identity entry does not eliminate personal data. The server still needs a protected enrollment record, and the notification provider must process the destination. Clear trust boundaries matter as much as encryption.

Finally, behavioral similarity works better as supporting evidence than as a secret. A production version should prefer 1:1 account confirmation and use a passkey or verified device as the final factor.

How we used Codex

Codex worked as the implementation partner throughout the project. It:

initialized and connected the GitHub repository;
analyzed the original authentication hypothesis;
researched security and privacy tradeoffs;
designed the SQLite schema and trust boundaries;
wrote failing tests before security-sensitive code;
implemented the derived style profile and GPT-5.6 integration;
built the Next.js interface and API routes;
diagnosed the first demo-video failure;
recorded and verified the live browser journey;
generated the final English narration, subtitles, and submission materials.

The Git history preserves these decisions in small English commits.

## What's next

replace simulated SMS with passkey or verified push approval;
prove device ownership during enrollment;
test false accepts and false rejects across languages and changing writing habits;
add drift handling without retaining raw conversations;
add rate limits and account-enumeration protection;
evaluate a safer 1:1 confirmation mode;
add managed key rotation, revocation, monitoring, and audit controls;
obtain an independent privacy, bias, and security review.

Authidenty is a hackathon research prototype. It recognizes an enrolled account pattern; it does not prove civil identity, legal name, age, or humanness.

Watch the demo

View the source code