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.

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 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.

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.