add passkey implementation #3748

BillyWooo · 2025-10-05T21:32:09Z

Passkey Challenge System: New challenge generation and verification mechanism for secure passkey operations： executor-storage/src/passkey_challenge.rs
Passkey Storage & Management: Storage layer for passkey credentials with CRUD operations: executor-storage/src/passkey.rs
WebAuthn Crypto Support: Full passkey cryptographic operations including signature verification: executor-crypto/src/passkey.rs
RPC Endpoints: New API methods for passkey lifecycle management
- omni_requestPasskeyChallenge - Generate authentication challenges
- omni_attachPasskey - Register new passkeys to accounts
- omni_removePasskey - Remove passkeys from accounts

claude · 2025-10-05T21:32:34Z

Claude finished @BillyWooo's task —— View job

PR Review: Passkey Implementation

I've completed a comprehensive review of the passkey implementation. Overall, this is a well-structured implementation with good security practices. Here's my analysis:

Todo List:

Read repository CLAUDE.md for guidelines
Review core passkey implementation files
Analyze RPC endpoint implementations
Evaluate test coverage and quality
Check for security concerns
Assess performance considerations
Provide comprehensive feedback

Summary

This PR implements a comprehensive passkey system with three main components:

Cryptographic operations (executor-crypto/src/passkey.rs) - WebAuthn attestation and signature verification
Storage layer (executor-storage/src/passkey.rs & passkey_challenge.rs) - CRUD operations for passkeys and challenge management
RPC endpoints - Three new API methods for passkey lifecycle management

Code Quality & Best Practices ✅

Strengths:

Well-structured code with clear separation of concerns
Comprehensive error handling with specific error types
Good use of Rust idioms and type safety
Proper documentation and comments
Consistent naming conventions
CBOR/WebAuthn standard compliance

Areas for improvement:

Some functions are quite long (e.g., extract_credential_and_key_from_auth_data at 70+ lines)
Consider breaking down complex parsing logic into smaller helper functions

Security Analysis 🔒

Strong security measures:

✅ RP ID verification: Critical check in verify_auth.rs:395 prevents phishing attacks
✅ Challenge-response: Proper nonce-based challenge system with expiration
✅ User presence/verification flags: Validates WebAuthn UP and UV flags
✅ Origin verification: Prevents cross-origin attacks
✅ Challenge consumption: One-time use prevents replay attacks
✅ Cryptographic verification: Proper ECDSA P-256 signature validation

Potential concerns:

Challenge cleanup timing: The 24-hour grace period for cleanup (passkey_challenge.rs:121) seems long. Consider reducing to 1-6 hours for better storage hygiene.
Error information leakage: Some error messages in RPC endpoints might reveal system internals. Consider using more generic error messages for client-facing APIs.
Rate limiting: No rate limiting on challenge generation - could be abused for DoS. Consider implementing per-account rate limits.

Performance Considerations ⚡

Efficient design:

✅ Composite key indexing (omni_account + credential_id) for O(1) lookups
✅ Blake2 hashing for key generation
✅ Lazy cleanup strategy reduces overhead

Potential optimizations:

Batch cleanup: The current cleanup iterates through all records. For large datasets, consider batching or indexing by expiration time.
Memory usage: CBOR parsing loads entire objects into memory. For very large attestation objects, consider streaming parsing.
Database operations: Consider connection pooling if not already implemented in StorageDB.

Test Coverage 🧪

Excellent test coverage:

✅ Unit tests for all core functionality
✅ Integration tests covering end-to-end flows
✅ Edge cases (expiration, duplicates, concurrency)
✅ Error conditions properly tested
✅ Challenge lifecycle thoroughly tested

Test quality is very high - comprehensive scenarios including concurrent sessions and error conditions.

Potential Bugs & Issues 🐛

COSE key parameter mapping (passkey.rs:337-338): The code maps COSE parameters -2 and -3 to x and y coordinates, but according to COSE spec, -2 is x-coordinate and -3 is y-coordinate. This appears correct but should be double-checked.
Hex decoding error handling (verify_auth.rs:381): The error message "Invalid auth data hex format" could be more specific about what went wrong.
Time precision (passkey_challenge.rs:276): Tests use 1-second sleep but time precision is in seconds. This could cause flaky tests on fast machines.

Recommendations 📋

High Priority:

Add rate limiting to challenge generation endpoints
Reduce cleanup grace period from 24h to 2-6h
Add input validation for credential_id length and format

Medium Priority:

Improve error messages to be less revealing of internal structure
Add metrics/logging for security events (failed authentications, etc.)
Consider adding passkey enumeration endpoint for UI purposes

Low Priority:

Refactor large functions for better maintainability
Add benchmark tests for performance validation
Consider adding passkey metadata (device info, last used, etc.)

Dependencies & Security 🔐

New dependencies look appropriate and are well-maintained:

ciborium for CBOR parsing
p256 for ECDSA cryptography

All dependencies are industry-standard choices for WebAuthn implementation.

Overall Assessment ⭐

This is a high-quality implementation that follows WebAuthn standards correctly and implements proper security measures. The code is well-tested, properly structured, and handles edge cases appropriately.

Recommendation: Approve with minor suggestions - The implementation is solid and secure, with only minor improvements suggested for production readiness.

claude · 2025-10-21T19:29:34Z

Claude finished @BillyWooo's task —— View job

PR Review: Passkey Implementation

This is a comprehensive and well-implemented passkey system that follows WebAuthn standards with proper security measures. Here's my detailed analysis:

Todo List:

Read repository CLAUDE.md for guidelines
Review core passkey implementation files
Analyze RPC endpoint implementations
Evaluate test coverage and quality
Check for security concerns
Assess performance considerations
Provide comprehensive feedback

Summary

This PR implements a complete passkey system with three main components:

Cryptographic operations (executor-crypto/src/passkey.rs) - WebAuthn attestation and signature verification
Storage layer (executor-storage/src/passkey.rs & passkey_challenge.rs) - CRUD operations for passkeys and challenge management
RPC endpoints - Three new API methods for passkey lifecycle management

Code Quality & Best Practices ✅

Strengths:

Well-structured code with clear separation of concerns
Comprehensive error handling with specific error types
Good use of Rust idioms and type safety
Proper documentation and comments
Consistent naming conventions
CBOR/WebAuthn standard compliance

Areas for improvement:

Some functions are quite long (e.g., extract_credential_and_key_from_auth_data at 70+ lines)
Consider breaking down complex parsing logic into smaller helper functions

Security Analysis 🔒

Strong security measures:

✅ RP ID verification: Critical check in verify_auth.rs:433 prevents phishing attacks
✅ Challenge-response: Proper nonce-based challenge system with expiration (5 minutes)
✅ User presence/verification flags: Validates WebAuthn UP and UV flags in verify_auth.rs:442-453
✅ Origin verification: Prevents cross-origin attacks in passkey.rs:92-94
✅ Challenge consumption: One-time use prevents replay attacks
✅ Cryptographic verification: Proper ECDSA P-256 signature validation

Potential concerns:

Challenge cleanup timing: The 24-hour grace period for cleanup (passkey_challenge.rs:121) seems long. Consider reducing to 1-6 hours for better storage hygiene.
Error information leakage: Some error messages in RPC endpoints might reveal system internals. Consider using more generic error messages for client-facing APIs.
Rate limiting: No rate limiting on challenge generation - could be abused for DoS. Consider implementing per-account rate limits.

Performance Considerations ⚡

Efficient design:

✅ Composite key indexing (omni_account + credential_id) for O(1) lookups
✅ Blake2 hashing for key generation
✅ Lazy cleanup strategy reduces overhead

Potential optimizations:

Batch cleanup: The current cleanup iterates through all records. For large datasets, consider batching or indexing by expiration time.
Memory usage: CBOR parsing loads entire objects into memory. For very large attestation objects, consider streaming parsing.
Database operations: Consider connection pooling if not already implemented in StorageDB.

Test Coverage 🧪

Excellent test coverage:

✅ Unit tests for all core functionality
✅ Integration tests covering end-to-end flows
✅ Edge cases (expiration, duplicates, concurrency)
✅ Error conditions properly tested
✅ Challenge lifecycle thoroughly tested

Test quality is very high - comprehensive scenarios including concurrent sessions and error conditions.

Potential Bugs & Issues 🐛

COSE key parameter mapping (passkey.rs:337-338): The code maps COSE parameters -2 and -3 to x and y coordinates. According to COSE spec, -2 is x-coordinate and -3 is y-coordinate. This appears correct but should be double-checked.
Hex decoding error handling (verify_auth.rs:421): The error message "Invalid auth data hex format" could be more specific about what went wrong.
Time precision (passkey_challenge.rs:276): Tests use 1-second sleep but time precision is in seconds. This could cause flaky tests on fast machines.

Recommendations 📋

High Priority:

Add rate limiting to challenge generation endpoints
Reduce cleanup grace period from 24h to 2-6h
Add input validation for credential_id length and format

Medium Priority:

Improve error messages to be less revealing of internal structure
Add metrics/logging for security events (failed authentications, etc.)
Consider adding passkey enumeration endpoint for UI purposes

Low Priority:

Refactor large functions for better maintainability
Add benchmark tests for performance validation
Consider adding passkey metadata (device info, last used, etc.)

Dependencies & Security 🔐

New dependencies look appropriate and are well-maintained:

ciborium for CBOR parsing
p256 for ECDSA cryptography

All dependencies are industry-standard choices for WebAuthn implementation.

Overall Assessment ⭐

This is a high-quality implementation that follows WebAuthn standards correctly and implements proper security measures. The code is well-tested, properly structured, and handles edge cases appropriately.

Recommendation: Approve with minor suggestions - The implementation is solid and secure, with only minor improvements suggested for production readiness.

Kailai-Wang

Thank you - the overall logic looks fine, I didn't go very detailed into e.g. passkey verification, attach/removal.

I mainly have questions regarding db read/write

tee-worker/omni-executor/executor-storage/.gitignore

Kailai-Wang · 2025-10-22T13:44:33Z

tee-worker/omni-executor/executor-storage/src/passkey.rs

+		Self { db }
+	}
+
+	fn generate_key(omni_account: &AccountId, credential_id: &str) -> [u8; 32] {


How long will the credential_id be? It makes sense to pre-hash it if it's very long - otherwise I'd rather keep it simple as use (AccountId, &'static str) as key, see e.g. HeimaJwtStorageKey.

Prehashing also makes it impossible to enumerate all entries if e.g. I want to "list all passkeys for a given user" (as what's implemented in the passkey_challenge) - correct me if I'm wrong @silva-fj

Kailai-Wang · 2025-10-22T13:56:57Z

tee-worker/omni-executor/executor-storage/src/passkey_challenge.rs

+			expires_at: current_time + timeout_seconds,
+		};
+
+		let challenge_key = challenge.as_bytes();


I would directly use &str or String as key - converting it to bytes first and then insert it would SCALE encode it again which could cause unexpected result

cc @silva-fj on this one too

Also does the key need to involve omni-account?

I would directly use &str or String as key - converting it to bytes first and then insert it would SCALE encode it again which could cause unexpected result

cc @silva-fj on this one too

Yes, we should use types for keys and values that implement Codec, our Storage trait takes care of the encoding

Kailai-Wang · 2025-10-22T14:25:00Z

tee-worker/omni-executor/rpc-server/src/methods/omni/attach_passkey.rs

+				ErrorCode::ParseError
+			})?;
+
+			let identity = Identity::try_from(params.user_id.clone()).map_err(|_| {


Since it's "attaching" passkey, shall we check the user_id can't be of passkey type?

Kailai-Wang · 2025-10-22T14:35:34Z

tee-worker/omni-executor/rpc-server/src/methods/omni/attach_passkey.rs

+							match e {
+								PasskeyChallengeError::ChallengeNotFound => {
+									error!("Challenge not found");
+								},
+								PasskeyChallengeError::ChallengeExpired => {
+									error!("Challenge expired");
+								},
+								PasskeyChallengeError::InvalidChallenge => {
+									error!("Invalid challenge");
+								},
+								_ => {
+									error!("Challenge verification failed: {:?}", e);
+								},
+							}
+							executor_crypto::passkey::PasskeyError::ChallengeVerificationFailed
+						})
+				},
+			)
+			.map_err(|e| {
+				error!("Client data verification failed: {:?}", e);
+				match e {
+					executor_crypto::passkey::PasskeyError::ChallengeVerificationFailed => {


Hopefully we could simpify this a bit after #3780 is merged

Kailai-Wang · 2025-10-22T14:44:10Z

tee-worker/omni-executor/rpc-server/src/methods/omni/get_hyperliquid_signature_data.rs

 	pub client_auth: Option<ClientAuth>,
 	pub action_type: HyperliquidActionType,
 	pub chain_id: ChainId,
+	pub attach_passkey: Option<AttachPasskeyData>,


Just for my understanding:
which rpc to call in reality, omni_attachPasskey or this rpc, or both?

silva-fj · 2025-10-06T10:52:50Z

tee-worker/omni-executor/executor-storage/src/passkey_challenge.rs

+		}
+
+		self.remove(&challenge_key).map_err(|_| PasskeyChallengeError::StorageError)?;
+		self.cleanup_expired24h_challenges()?;


I don't think we should call this on this method, we can spawn a task for this

silva-fj · 2025-10-06T10:57:54Z

tee-worker/omni-executor/executor-storage/src/passkey_challenge.rs

+	}
+
+	/// Check if a challenge exists and is valid (without consuming it)
+	pub fn is_challenge_valid(


is this only used in tests?

silva-fj · 2025-10-23T09:38:25Z

tee-worker/omni-executor/rpc-server/src/methods/omni/attach_passkey.rs

+						ErrorCode::ServerError(-32011) // Challenge mismatch
+					},
+					executor_crypto::passkey::PasskeyError::OriginVerificationFailed => {
+						ErrorCode::ServerError(-32012) // Origin mismatch


We should double check that these codes are not used in error_code.rs and it would probably be better to create the new constants and use them here

silva-fj · 2025-10-23T09:58:49Z

tee-worker/omni-executor/rpc-server/src/verify_auth.rs

+	use executor_storage::PasskeyStorage;
+
+	let passkey_identity =
+		Identity::from_web2_account(&passkey_data.user_id, Web2IdentityType::Passkey);


What identity is this? Identity::Passkey ?

silva-fj · 2025-10-23T10:13:05Z

tee-worker/omni-executor/executor-storage/src/passkey_challenge.rs

+			expires_at: current_time + timeout_seconds,
+		};
+
+		let challenge_key = challenge.as_bytes();


I would directly use &str or String as key - converting it to bytes first and then insert it would SCALE encode it again which could cause unexpected result

cc @silva-fj on this one too

Yes, we should use types for keys and values that implement Codec, our Storage trait takes care of the encoding

add implementation

167389b

BillyWooo requested review from Kailai-Wang, kziemianek and silva-fj October 5, 2025 21:32

BillyWooo marked this pull request as draft October 6, 2025 07:33

BillyWooo self-assigned this Oct 6, 2025

clean up space

ba73d43

BillyWooo changed the title ~~add implementation~~ add passkey implementation Oct 6, 2025

BillyWooo added 7 commits October 7, 2025 13:53

client_data_json needs decode.

c4cf8a5

fmt

ea08213

Merge remote-tracking branch 'origin/dev' into passkey-implementation

e79be7b

Merge remote-tracking branch 'origin/dev' into passkey-implementation

13fbe5e

fix errors

399bf68

Merge remote-tracking branch 'origin/dev' into passkey-implementation

fa34f67

Merge remote-tracking branch 'origin/dev' into passkey-implementation

88de8bd

BillyWooo marked this pull request as ready for review October 21, 2025 19:29

BillyWooo added 2 commits October 22, 2025 09:41

fix clippy

2b9e710

Merge remote-tracking branch 'origin/dev' into passkey-implementation

c4af37c

Kailai-Wang reviewed Oct 22, 2025

View reviewed changes

silva-fj reviewed Oct 23, 2025

View reviewed changes

add passkey implementation #3748

Are you sure you want to change the base?

add passkey implementation #3748

Uh oh!

Conversation

BillyWooo commented Oct 5, 2025

Uh oh!

claude bot commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: Passkey Implementation

Todo List:

Summary

Code Quality & Best Practices ✅

Security Analysis 🔒

Performance Considerations ⚡

Test Coverage 🧪

Potential Bugs & Issues 🐛

Recommendations 📋

High Priority:

Medium Priority:

Low Priority:

Dependencies & Security 🔐

Overall Assessment ⭐

Uh oh!

claude bot commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: Passkey Implementation

Todo List:

Summary

Code Quality & Best Practices ✅

Security Analysis 🔒

Performance Considerations ⚡

Test Coverage 🧪

Potential Bugs & Issues 🐛

Recommendations 📋

High Priority:

Medium Priority:

Low Priority:

Dependencies & Security 🔐

Overall Assessment ⭐

Uh oh!

Kailai-Wang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

claude bot commented Oct 5, 2025 •

edited

Loading

claude bot commented Oct 21, 2025 •

edited

Loading