Skip to content

Security

The AbLead application uses a secure, industry-standard authentication stack and is designed with security as a core principle.

Technology Stack

  • Backend: Python/Flask with Flask-SQLAlchemy for database interactions.
  • Password Hashing: Uses Werkzeug's PBKDF2 with SHA-256 hashing. Passwords are never stored in plain text; only their cryptographic hashes are stored in the database.
  • Passwordless & FIDO2/WebAuthn: Implements standard WebAuthn/FIDO2 credentials using the webauthn library, supporting public-key cryptography (ECDSA, RSASSA, EDDSA) directly integrated with modern browsers.
  • Password Strength: Integrates the zxcvbn library to enforce high-entropy passphrases. Initial account setup requires a minimum of 12 characters and a complexity score of at least 3 out of 4.
  • Session Management: Uses Flask's signed sessions (cryptographically signed cookies). This prevents users from tampering with their session data.
  • Email & Verification Security: Dispatches automated onboarding and password reset links with 256-bit cryptographically secure tokens (secrets.token_urlsafe(32)), leveraging encrypted SMTP connections (STARTTLS on port 587) and HTTPS transport.

Security Assessment

AbLead implements several layers of defense to protect user data:

Strong Hashing

PBKDF2 is a specialized "slow" hashing algorithm designed to resist brute-force and dictionary attacks by making each attempt computationally expensive.

Signed Sessions

The application uses a unique, secure SECRET_KEY to sign session cookies. This ensures that session data cannot be forged or modified by a client.

CSRF Mitigation

The application utilizes SameSite="Lax" cookie attributes for sessions. This is a modern browser-level defense that significantly reduces the risk of Cross-Site Request Forgery (CSRF) by preventing sessions from being sent with cross-site requests.

SQL Injection Protection

All database communication is performed via the SQLAlchemy ORM. This approach uses parameterized queries for all operations, which effectively eliminates the risk of SQL injection by ensuring that user input is never executed as code.

Robust Access Control

Private application routes are protected by a @login_required decorator. This system verifies the user's identity, active status, and session validity on every single request. Furthermore, project-level routes enforce strict, granular authorization controls, ensuring users can only access or modify projects they own or have been explicitly granted shared access to (Read-Only or Write). Shared access can only be granted to users within the same organization (same company or email domain).

Multi-Factor & 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. This provides an additional layer of security by requiring a 6-digit verification code from a trusted mobile device (e.g., Google Authenticator, Authy) during the login process. Users can manage their 2FA settings from their account profile.
  • Passwordless Authentication (Passkeys/WebAuthn): Supports cryptographically secure, passwordless authentication using FIDO2/WebAuthn. Users can register biometric sensors (Touch ID, Face ID, 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.

Email Transport & 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 & 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.
  • HTTPS Link Endpoints: All verification and activation URLs use HTTPS endpoints, ensuring end-to-end TLS encryption between the user's browser and the web application when opening the link.

Verification Token Lifecycle & 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 and purged automatically.
  • Single-Use Invalidation: Tokens are permanently invalidated and cleared from the database immediately upon the first successful form submission, preventing token reuse or replay attacks.
  • 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. 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 & 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 dynamic inactivity timeout (typically 60 minutes). If no activity is detected within this window, the session is invalidated, and the user is automatically logged out.

Overall, the login system and data handling in AbLead adhere to modern web security best practices for professional biotherapeutic software.