Skip to content

Security

The AbLead application uses a secure, industry-standard authentication stack and is designed with defense-in-depth and multi-tenant data isolation as core principles.

Technology Stack

  • Backend: Python/Flask with Flask-SQLAlchemy for database interactions.
  • Password Hashing: Uses Werkzeug's cryptographic password hashing (scrypt and PBKDF2-SHA256) with per-password random salts. Passwords are never stored in plain text; only their cryptographic hashes are stored in the database.
  • Passwordless and FIDO2/WebAuthn: Implements standard WebAuthn/FIDO2 credentials using the webauthn library, supporting public-key cryptography (ECDSA, RSASSA, and EDDSA) directly integrated with modern browsers.
  • Password Strength: Integrates the zxcvbn library to enforce high-entropy passphrases. Initial account setup and passphrase changes require a minimum of 12 characters, a complexity score of at least 3 out of 4, and cannot reuse the current passphrase.
  • Session Management and Instant Revocation: Uses Flask's cryptographically signed sessions paired with server-side session_version tracking. Changing or resetting a passphrase, completing account activation, timing out due to inactivity, or having an administrator disable or sign out an account immediately increments session_version and invalidates all existing browser sessions across all devices.
  • Email and Verification Security: Dispatches automated onboarding and password reset links with 256-bit cryptographically secure tokens (secrets.token_urlsafe(32)), host-header allowlist validation, encrypted SMTP connections (STARTTLS on port 587), and HTTPS transport.

Security Assessment

AbLead implements several layers of defense to protect user data:

Strong Hashing and Brute-Force Throttling

Memory-hard and computationally intensive hashing (scrypt / PBKDF2-SHA256) resists offline brute-force and dictionary attacks. Online authentication endpoints enforce strict rate limiting per client IP (request.remote_addr) for both login attempts and password-reset requests, and TOTP / recovery-code verification enforces a 5-attempt lockout that clears the pending authentication state and requires full re-authentication.

Signed Sessions and Global Session Invalidation

The application uses a unique, high-entropy SECRET_KEY to sign session cookies so session payloads cannot be forged or modified by a client. On every request, the server verifies the user's active status, account expiration, inactivity window, and session_version counter against the database.

CSRF Mitigation

The application configures session cookies with HttpOnly=True, SameSite="Lax", and Secure (on HTTPS deployments). In addition, all state-changing operations across user workspaces, trash management, and administrative controls strictly require POST or DELETE requests rather than GET navigation links, preventing cross-site request forgery via image tags, link pre-fetching, or third-party navigation.

SQL Injection Protection

All database communication is performed via the SQLAlchemy ORM using parameterized queries, ensuring that user input is never concatenated into raw SQL or executed as code.

Multi-Tenant Data Isolation and Access Control

Private application routes and API endpoints are protected by the @login_required decorator, which validates identity, active status, and session state on every request. Resource-level routes enforce strict ownership and granular permission checks:

  • Projects and Analysis Tools: Every project view, calculation endpoint, and export verifies get_project_permissions (read, write, grant, and is_owner). Read-only shared users and restricted (is_read_only) accounts are blocked from modifying sequences, custom liability rules, engineering variants, metadata, or project settings.
  • Organization-Scoped Sharing: Project sharing (ProjectShare) is strictly restricted to active users within the same organization (company_id or verified organization domain). Users without write access cannot grant or revoke write permissions, and soft-deleted projects in Trash are immediately inaccessible to non-owners.
  • Sub-Resource Ownership: NGS libraries (LibraryProject), custom KBC scoring and format sets (KbcScoringSet and KbcFormatSet), project labels (Label), residue observations (ResidueObservation), and 3D structure files all verify user ownership and parent-project permissions before reading or mutating data.

Multi-Factor and Passwordless Authentication

AbLead supports multiple methods of advanced identity verification to protect user accounts:

  • Two-Factor Authentication (2FA): Supports the Time-based One-Time Password (TOTP) standard alongside one-time hashed recovery codes. Both TOTP and recovery-code verification enforce maintenance-mode restrictions, concurrent organization seat-token limits, and brute-force attempt limits.
  • Passwordless Authentication (Passkeys/WebAuthn): Supports cryptographically secure, passwordless authentication using FIDO2/WebAuthn. Users can register biometric sensors (Touch ID, Face ID, and Windows Hello) or physical security keys (YubiKey) from their profile. Passkey registration and login flows rely on challenge-response cryptography, protecting against phishing, credential stuffing, and replay attacks.

Model Context Protocol (MCP) and OAuth 2.0 Security

AbLead's Model Context Protocol (MCP) integration is protected by OAuth 2.0 with PKCE and strict per-user authorization:

  • OAuth 2.0 with PKCE (S256): Authorization requests require Proof Key for Code Exchange (S256), validate redirect_uri against registered client callback URIs, and require an explicit POST user consent confirmation before issuing a short-lived, single-use authorization code.
  • Hashed Bearer Tokens: Access and refresh tokens are stored exclusively as SHA-256 hashes in the database (McpOAuthToken) with enforced expiration windows and revocation checks.
  • Per-Tool Permission Enforcement: Every MCP tool requires an authenticated user context (user_id resolved from the verified OAuth Bearer token or API key) and enforces the exact same get_project_permissions (read and write) and library ownership checks as the web interface.

File Upload, Archive, and Script Export Sanitization

  • Archive Decompression Quotas and Path Containment: Project ZIP imports enforce strict member count limits, uncompressed byte quotas (250 MB maximum), symlink rejection, and secure_filename sanitization to prevent Zip Slip path traversal and decompression bombs. Server-side result file pointers (FILE:) are canonicalized with os.path.realpath and restricted to the designated results directory.
  • Structure and Script Export Sanitization: Structure downloads and ZIP exports sanitize filenames via secure_filename. Exported PyMOL scripts validate antibody and residue identifiers (^[A-Za-z0-9_.\-]+$) and strip newline characters from comment headers to prevent script injection, and administrative CSV exports neutralize leading spreadsheet formula characters (=, +, -, and @).

Email Transport and In-Transit Protection

All transactional emails (onboarding invitations, evaluation workspace provisioning, and password reset requests) are protected by multi-layered transport security:

  • SMTP Transport Encryption (STARTTLS): Outbound emails are dispatched over port 587 with explicit STARTTLS encryption between the application server and the outbound mail relay, preventing packet sniffing and man-in-the-middle (MITM) snooping on local networks and intermediate hops.
  • MTA-to-MTA Encryption and Routing Security: Mail relays enforce modern TLS transport in transit to recipient mail servers, protected by standard email domain authentication protocols (SPF, DKIM, and DMARC) alongside MTA-STS and DANE policies where supported by recipient mail exchange servers.
  • Trusted Host and HTTPS Link Generation: All verification and activation URLs are generated against an explicit allowlist of trusted application domains over HTTPS, preventing Host-header poisoning and ensuring end-to-end TLS encryption.

Verification Token Lifecycle and Onboarding Controls

Account invitation, onboarding, and self-service password recovery workflows employ defense-in-depth token management controls:

  • High-Entropy Cryptographic Tokens: Activation and reset tokens are generated using secrets.token_urlsafe(32) providing 256 bits of cryptographic entropy from the OS CSPRNG, making brute-force guessing or URL enumeration mathematically infeasible.
  • Strict Time-to-Live (TTL): Onboarding and evaluation tokens automatically expire within 24 hours (and password reset tokens within 2 hours). Expired tokens are rejected by the server.
  • Single-Use Invalidation: Activation endpoints are restricted to uninitialized accounts, and password-reset endpoints are restricted to active, initialized accounts. Tokens are permanently invalidated and cleared from the database immediately upon the first successful form submission, while incrementing session_version.
  • POST-Based Activation: The activation endpoint requires an explicit POST submission to accept the legal disclosure and establish credentials. Automated mail scanners and pre-fetch link crawlers performing GET requests cannot accidentally trigger or consume activation tokens.
  • Zero Prior Data Exposure: Newly provisioned evaluation and invited accounts contain no proprietary sequence or project data prior to onboarding. Isolated copies of example workspaces are seeded only after successful activation.
  • Real-Time Administrator Audit Alerts: Activation of new evaluation accounts immediately triggers automated notification alerts to system administrators with user and timestamp details for audit tracking.

Data Protection and Backups

To ensure business continuity and protect against data loss, AbLead implements a multi-layered backup strategy:

  • Nightly Database Backups: The core application database (containing all sequences, structural data, and project metadata) is backed up nightly.
  • Automated Volume Backups: The primary application server utilizes an automated Bronze Backup Policy via Oracle Cloud Infrastructure (OCI). This includes monthly and yearly incremental snapshots of the entire boot volume, allowing for rapid disaster recovery of the full operating environment (including codebases, configurations, and models).
  • Disaster Recovery: In the event of a catastrophic system failure, the environment can be restored from the latest volume snapshot, ensuring minimal downtime and preserving all system-level configurations.

Inactivity Timeout

To protect sessions on shared or public terminals, the system includes a configurable inactivity timeout (typically 30 to 60 minutes). If no activity is detected within this window, the session is invalidated both client-side and server-side (clearing last_activity and incrementing session_version), and the user is automatically logged out.

Overall, the authentication architecture, access control model, and data handling in AbLead adhere to modern web security best practices for enterprise biotherapeutic software.