Application Security

This section covers application-level security measures that developers implement in their code, including input validation, secure coding practices, secure storage, and application security headers.

Security Principles

The Arculus Authentication system is designed with security as a fundamental principle:

• FIDO2/WebAuthn Compliance: Adherence to industry-standard authentication protocols

• Public Key Cryptography: No shared secrets between client and server

• Hardware-Based Security: Cryptographic operations performed on secure hardware

• Defense in Depth: Multiple layers of security controls

• Least Privilege: Minimal access and permissions required

Authentication Security

FIDO2/WebAuthn Security

• Public Key Cryptography: No shared secrets between client and server

• Challenge-Response Protocol: Prevents replay attacks

• Origin Binding: Phishing protection through origin verification

• User Verification: PIN-based verification on hardware authenticator

• Attestation Verification: Optional verification of authenticator authenticity

Attestation Verification

The PyFIDO Server supports configurable attestation verification:

• None: No attestation verification (development/testing)

• Direct: Direct attestation statement verification

• Indirect: Attestation verification via FIDO Metadata Service (MDS)

Configuration Options:

• Optional FIDO Metadata Service (MDS) integration

• AAGUID whitelist support

• Attestation type configuration (none, direct, indirect)

Input Validation and Sanitization

All user inputs are validated and sanitized to prevent injection attacks:

• Username Validation: Only alphanumeric characters, dots, underscores, and hyphens allowed (regex: ^[a-zA-Z0-9._-]+$)

• PIN Validation: Must be 4-8 digits only (numeric characters only)

• XSS Prevention: Dangerous characters (<>"'&) are removed from all inputs

• Length Limits: Maximum 255 characters for string inputs

• Request Size Limits: Maximum 8KB request body size to prevent DoS attacks

Implementation: Backend servlets perform server-side validation before processing requests. Mobile applications also perform client-side validation using ValidationUtils classes.

Example Validation Rules:

// Username: alphanumeric, dots, underscores, hyphens only
if (!username.matches("^[a-zA-Z0-9._-]+$")) {
    throw new IllegalArgumentException("Invalid username format");
}

// PIN: 4-8 digits only
if (!pin.matches("^[0-9]+$") || pin.length() < 4 || pin.length() > 8) {
    throw new IllegalArgumentException("PIN must be 4-8 digits");
}

// XSS prevention: remove dangerous characters
value = value.replaceAll("[<>\"'&]", "");

Security Headers

Backend services implement comprehensive security headers:

• X-Content-Type-Options: nosniff: Prevents MIME type sniffing

• X-Frame-Options: DENY: Prevents clickjacking attacks

• X-XSS-Protection: 1; mode=block: Enables XSS filtering in browsers

• Strict-Transport-Security: max-age=31536000; includeSubDomains: Enforces HTTPS connections

• Content-Security-Policy: Uses nonces instead of unsafe-inline for scripts/styles (where implemented)

Implementation Example:

response.setHeader("X-Content-Type-Options", "nosniff");
response.setHeader("X-Frame-Options", "DENY");
response.setHeader("X-XSS-Protection", "1; mode=block");
response.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains");

CORS Configuration

Cross-Origin Resource Sharing (CORS) is configured with restrictive policies:

• Origin Whitelist: Only specific allowed origins are permitted (no wildcard fallback)

• Limited Methods: Only POST, OPTIONS, and GET methods allowed

• Credential Handling: Proper credential configuration for authenticated requests

• Preflight Handling: OPTIONS requests are handled correctly for CORS preflight

Security Note: CORS origin validation prevents unauthorized domains from accessing backend APIs.

Implementation Example:

String origin = request.getHeader("Origin");
if (origin != null && isAllowedOrigin(origin)) {
    response.setHeader("Access-Control-Allow-Origin", origin);
}
response.setHeader("Access-Control-Allow-Methods", "POST, OPTIONS, GET");
response.setHeader("Access-Control-Allow-Credentials", "true");

Secure Token Storage

Mobile applications use platform-specific secure storage:

• Android: Tokens stored in Android Keystore (hardware-backed encryption when available)

• iOS: Tokens stored in iOS Keychain (encrypted at rest)

• OAuth2 Tokens: Access tokens, refresh tokens, and ID tokens are encrypted

• No Plaintext Storage: Sensitive data is never stored in plaintext

Implementation:

• Android: KeyStore API with KeyGenParameterSpec for hardware-backed keys

• iOS: Keychain Services API with kSecAttrAccessibleWhenUnlockedThisDeviceOnly

Error Handling Security

Error responses are designed to prevent information disclosure:

• Generic Error Messages: User-facing errors don't expose internal system details

• Secure Logging: Detailed error information is logged server-side but not returned to clients

• Appropriate Status Codes: HTTP status codes accurately reflect error conditions without revealing vulnerabilities

• No Stack Traces: Stack traces and exception details are not exposed to clients

Best Practice: Log detailed errors server-side for debugging, but return generic messages to clients.

Backend-Proxied Pattern Security

The backend-proxied deployment pattern provides additional security benefits:

• FIDO2 Server Isolation: FIDO2 server is only accessible from backend services, not directly from clients

• Network Isolation: FIDO2 server can bind to localhost/127.0.0.1 only, preventing external access

• No Direct Client Access: Mobile applications never communicate directly with FIDO2 server

• Server-Side Validation: All FIDO2 operations validated on backend before reaching FIDO2 server

• Session Management: Backend manages FIDO2 server session cookies, maintaining security boundaries

Security Benefits:

1. Prevents client-side tampering with FIDO2 requests

2. Isolates FIDO2 server from internet exposure

3. Enables centralized validation and logging

4. Maintains clear security boundaries

Session Security

Session Management

• Session Timeout: Configurable session timeout (default: 60 seconds)

• Secure Session Storage: Sessions stored securely with encryption

• Session Expiration: Automatic expiration of inactive sessions

• No Session Persistence: Sessions not persisted across server restarts

• Session Validation: Backend validates session ownership before operations

Cookie Security

FIDO2 server session cookies are managed securely:

• Cookie Extraction: Backend extracts cookies from FIDO2 server Set-Cookie headers

• Cookie Cleaning: Backend cleans cookies (removes attributes) before forwarding to FIDO2 server SDK

• Session Continuity: Cookies maintain session state between Phase 1 (begin) and Phase 3 (complete) operations

• Expiration Handling: Expired sessions return appropriate error codes (408) with clear messages

Cookie Attributes: Cookies use secure attributes (HttpOnly, Secure, SameSite where applicable) when set by FIDO2 server.

JWT Authentication

Optional JWT-based authentication for API access:

• JWT Signing: Configurable JWT secret for token signing

• Token Expiration: Configurable token expiration

• Secure Storage: JWT secrets stored in secrets management service

• Token Validation: JWT tokens validated on backend before processing requests

Multi-Tenant Security

The PyFIDO Server supports secure multi-tenant deployments:

• Tenant Isolation: Separate credential storage per tenant

• Domain-Based Routing: Automatic tenant detection from request origin

• Header Override: X-ArculusFido-RelyingParty header for explicit tenant selection

• Configurable Policies: Per-tenant authentication policies

• Data Segregation: Complete data isolation between tenants

For multi-tenant configuration, see:

• 1.3 Multi-Tenant Support - Multi-tenant support overview

Security Best Practices

Application Development

• Input Validation: Always validate and sanitize all user inputs (username, PIN, request parameters)

• Security Headers: Implement all recommended security headers in backend services

• CORS Configuration: Use origin whitelisting, never use wildcard (*) for CORS

• Secure Storage: Use platform secure storage (Android Keystore / iOS Keychain) for tokens

• Error Handling: Never expose internal system details in error messages

• Request Size Limits: Implement request body size limits to prevent DoS attacks

• Backend-Proxied Pattern: Use backend-proxied deployment for production (recommended)

• TLS/SSL: Use TLS/SSL for all communications, even in development

• Regular Updates: Keep SDKs and dependencies up to date

Production Application Security

• Enable MDS Verification: Use FIDO Metadata Service (MDS) for attestation verification

• AAGUID Whitelist: Configure AAGUID whitelist for authenticator validation

• Session Timeouts: Configure appropriate session timeouts based on use case

• Comprehensive Logging: Enable detailed security event logging (without exposing sensitive data)

• Security Audits: Regular security audits and penetration testing

• Dependency Scanning: Regular vulnerability scanning of dependencies

• Code Reviews: Security-focused code reviews for all changes