Security Documentation

Our security architecture requires three independent proofs for every authenticated request. This triplet approach ensures that even if one component is compromised, additional layers continue to protect your account.

Tier 1: Entry Gate

Every visitor must complete a Proof of Work challenge before accessing the site. This computational barrier blocks automated attacks and bots while being nearly invisible to legitimate users.

Tier 2: Identity Binding

When you log in, your identity becomes cryptographically bound to your PoW proof. The powxd cookie is mathematically derived from your PoW computation, user ID, and session ID - it cannot be forged.

Tier 3: Continuous Enforcement

Every API request validates all three cookies and reconstructs the expected powxd to verify authenticity. Sessions can be revoked instantly via WebSocket notification.

Our defense in depth strategy requires multiple independent validations before any request proceeds. An attacker would need to defeat all validations simultaneously, which is computationally infeasible.

Attack Surface Reduction

We minimize attack surface by using httpOnly cookies (JavaScript cannot access), constant-time signature comparison (prevents timing attacks), and reconstruction-based validation (Redis tampering is detected).

Zero trust means we don't trust any request by default. Every API call must present all three cookies, pass browser validation, and survive HMAC reconstruction. There are no shortcuts.

Core Zero Trust Principles

Validation Flow Per Request

The withApiAuth middleware wraps every protected API route, automatically performing all validation steps. Routes can optionally require folder ownership or bot ownership for additional authorization.

Security boundaries define where trust ends and verification begins. Moving from one zone to another requires passing through validation gates that verify the appropriate level of authentication.

Trust Zones

Boundary Enforcement

Data Isolation

User data is strictly isolated using Redis key prefixing. A session for user A cannot access data belonging to user B. All security keys use the {auth} prefix for Redis cluster slot co-location.

{auth}:pow_session:{powId}    -> Session data with binding components
{auth}:pow_proof:{powId}      -> PoW challenge, nonce, resultHash
{auth}:user:{userId}          -> User profile
{auth}:user_pow_sessions:{id} -> Set of user's active powIds

Your password is only the first line of defense. Passwords can be stolen through phishing, data breaches at other services, or malware. Two-Factor Authentication adds a second, independent verification that only you possess: a time-based code from your phone.

How 2FA Protects You

The Statistics

Enabling 2FA takes less than 2 minutes and provides permanent protection. There is no security measure with a better effort-to-protection ratio.

TOTP (Time-based One-Time Password) is an open standard used by banks, tech companies, and security-conscious organizations worldwide. It generates a new 6-digit code every 30 seconds based on the current time and a shared secret.

The TOTP Algorithm

Security Properties

Why TOTP is Secure

Setting up 2FA is straightforward and takes about 2 minutes. Once enabled, you'll need both your password and a code from your authenticator app to log in.

Step-by-Step Setup

Recommended Authenticator Apps

We recommend open-source, privacy-respecting authenticator apps that don't require accounts or collect telemetry. These apps keep your secrets local and under your control.

Mobile Apps

Desktop Apps (Local/Offline)

After Setup

Once 2FA is enabled, every login will require both your password and the current 6-digit code from your authenticator app. The code changes every 30 seconds, so make sure to enter the current code displayed.

KeePassXC handles TOTP differently from mobile authenticator apps. Instead of scanning a QR code with your camera, you'll manually enter the secret key that's displayed below the QR code during 2FA setup. This approach offers maximum security since your TOTP secrets never leave your local machine and are stored in an encrypted vault.

Step 1: Create a Root Entry

Before you can configure TOTP, you need to create an entry in your KeePassXC database to store your Memescale credentials and authentication codes.

Step 2: Configure TOTP for the Entry

Now that you have an entry, you'll configure it to generate TOTP codes using the secret key provided during Memescale's 2FA setup process.

Step 3: Generate and Copy TOTP Codes

Once TOTP is configured, you can generate 6-digit codes whenever you need to log in to Memescale with 2FA enabled.

Verifying Your Setup

After configuring TOTP in KeePassXC, you'll need to verify it works by entering a generated code back on the Memescale 2FA setup screen.

The 2FA login flow adds minimal friction while dramatically improving security. You'll enter your password first, then be prompted for your authenticator code.

Login Sequence with 2FA

Code Timing

TOTP codes change every 30 seconds. If your code is about to expire (shown in most apps with a countdown), wait for the new code to appear. We accept codes from the current period and one previous period to account for minor time differences.

Failed Attempts

Multiple failed 2FA attempts are logged and may trigger security alerts. This protects against attackers who have your password but are trying to guess or brute-force your 2FA codes.

Losing access to your authenticator app doesn't have to mean losing access to your account. However, recovery requires proof of identity since 2FA is specifically designed to prevent unauthorized access.

Prevention is Best

If You're Locked Out

Disabling 2FA

If you have access to your account and want to disable 2FA (not recommended), you can do so from Account Settings. You'll need to enter your password and a valid 2FA code to confirm the action. This prevents attackers who might have stolen your session from disabling 2FA.

Every 2FA interaction is recorded for security and transparency. These logs help you identify unauthorized access attempts and verify that your 2FA configuration hasn't been tampered with.

Logged Events

Monitoring Your Account

Traditional session management relies on periodic checks - your browser asks the server 'am I still logged in?' every few seconds. This creates a dangerous window where a compromised session could continue to operate after you've revoked it.

The Revocation Timeline

This speed matters in security emergencies. If you suspect someone has access to your account, every second counts. Instant revocation ensures that the moment you take action, the threat is neutralized.

When you log in, your browser establishes a WebSocket connection alongside your regular session. This connection stays open, allowing the server to send you messages at any time - including the critical 'your session has been revoked' notification.

Connection Lifecycle

Security Events Delivered via WebSocket

Every WebSocket connection must prove its identity before receiving security notifications. This prevents attackers from listening in on your revocation events or establishing unauthorized connections.

Authentication Requirements

Zombie Connection Detection

Sometimes connections appear open but are actually dead - the network dropped, the device went to sleep, or the browser crashed. These 'zombie' connections could receive notifications that never reach you.

If your connection doesn't respond to a ping within 10 seconds, we know it's a zombie and terminate it. This ensures that when we send a revocation notification, it actually reaches a live connection.

Connection Limits

To prevent resource abuse, we limit the number of WebSocket connections per session and per user:

No technology is perfect. Network issues, firewalls, or proxy servers might block WebSocket connections. That's why we implement a defense-in-depth strategy with multiple protection layers.

Two-Layer Protection

Automatic Reconnection

If your WebSocket connection drops unexpectedly, your browser automatically attempts to reconnect with exponential backoff:

After 5 failed attempts, we stop retrying to avoid battery drain and unnecessary network requests. The heartbeat fallback continues protecting you during this time.

As our platform grows, your WebSocket connection might be handled by any one of our servers. When you revoke a session, we need to notify all servers instantly so the notification reaches the right connection.

How Multi-Server Revocation Works

Reliability Guarantees

Our architecture prioritizes safety: even if real-time delivery fails, the session is always revoked in the database. The heartbeat ensures this revocation is eventually enforced.

We designed the revocation experience to be informative without being alarming. You'll know exactly what happened and what to do next.

The Revocation Modal

When your session is revoked (either by you from another device, or by our security systems), you'll see a modal with:

After Revocation

Once revoked, the session cannot be restored. Any attempt to use that session's credentials will fail. You'll need to log in fresh with your current password (and 2FA code if enabled).

Every time you log in from a new device or browser, a session is created. The Sessions tab gives you complete visibility into all active sessions, helping you spot unauthorized access and take immediate action.

What You'll See

Each session entry displays:

Risk Level Indicators

A 'Dangerous' risk level doesn't always mean your account is compromised, but it's worth investigating. Review the device details and revoke the session if you don't recognize it.

Attackers often try to blend in by using common browsers and devices. However, certain patterns can reveal unauthorized access if you know what to look for.

Red Flags to Watch For

Common Attack Patterns

Time is critical when responding to a potential breach. Follow these steps in order to minimize damage and secure your account.

Immediate Response Steps

After Securing Your Account

Preventing Future Breaches

After recovering from a breach, take steps to prevent it from happening again:

You have several options for revoking sessions, each suited to different situations.

Revoke Single Session

Use this when you want to end access for a specific device while keeping other sessions active.

Revoke All Other Sessions

Use this during a security emergency or when you want to start fresh with only your current device logged in.

Post-Revocation Confirmation

After revoking sessions, especially during a security event, you'll be offered the option to:

Developing good security habits reduces your risk of account compromise and makes it easier to spot problems when they occur.

The Security Essentials Checklist

Password Security

Session Hygiene

We maintain a comprehensive log of security events for your account. This log is immutable - once an event is recorded, it cannot be modified or deleted.

Events We Log

Using the Audit Log

The audit log is available in your Account Settings under the 'Security' tab. Use it to:

Every session in Memescale is anchored to a Proof of Work computation and bound to your browser. Sessions are stored in Redis with automatic expiration after 7 days of inactivity.

Session States

State Transitions

Memescale uses three distinct tokens that work together. Unlike traditional systems with a single session cookie, our triplet ensures no single token grants access.

Token Types

Token Generation

The powId and sid are generated using UUID v4 (cryptographically random). The powxd is not random - it is derived using HMAC-SHA256 from your PoW proof combined with your userId and sid.

powId:  550e8400-e29b-41d4-a716-446655440000 (UUID)
sid:    7c9e6679-7425-40de-944b-e07fc1f90ae7 (UUID)
powxd:  a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 (32 hex chars)
JWT:    eyJhbGciOiJIUzI1NiIs... (signed payload)

Token Security Properties

Session data is stored server-side in Redis, keyed by powId. The critical security property: we store the binding components (challenge, nonce, resultHash, userId, sid, timestamp) and reconstruct powxd on every request rather than storing it.

Session Data Structure

{
  "powId": "550e8400-e29b-41d4-a716-446655440000",
  "userId": "user_abc123",
  "username": "johndoe",
  "powXdHash": "sha256:abc123...",
  "challenge": "random_challenge_string",
  "nonce": "12345678",
  "resultHash": "0000abcd...",
  "sid": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "bindingTimestamp": 1706123456789,
  "createdAt": "2024-01-15T10:30:00Z",
  "lastActivity": "2024-01-15T14:22:00Z",
  "ipHistory": [{"ip": "192.168.1.1", "firstSeen": "...", "lastSeen": "...", "requestCount": 42}],
  "browser": "Chrome",
  "browserVersion": "12",
  "os": "Windows"
}

Storage Security

Browser binding is a critical security feature. When you log in, we store your browser's fingerprint (name + version). Every subsequent request must come from the same browser type, or the session is rejected.

Binding Mechanism

Fingerprint Examples

Why Not Full Fingerprinting?

Session visibility gives you complete control over where your account is logged in. The dashboard shows every active session with browser, OS, IP addresses used, and activity timestamps.

Session Information Displayed

Session Control Actions

Session Limits

You can have up to 10 active sessions. When you create an 11th session, the oldest session is automatically revoked. This prevents session accumulation while allowing reasonable multi-device use.

When a session is revoked, it is immediately and permanently terminated. The session data is removed from Redis, a WebSocket notification is sent for instant logout, and an audit event is logged.

Revocation Triggers

Revocation Process

Unlike traditional fingerprinting systems that collect dozens of attributes, Memescale uses a simple but effective approach: we identify your browser by name and major version. This catches cross-browser attacks while respecting your privacy.

What We Collect

What We Don't Collect

Fingerprint generation happens at session creation (login or account creation). The server parses the User-Agent header to extract browser information, then truncates the version for stable comparison.

Generation Process

Truncation Examples

User-Agent: Mozilla/5.0 ... Chrome/120.0.6099.129
Major Version: 120
Truncated: 12
Fingerprint: Chrome12

User-Agent: Mozilla/5.0 ... Firefox/121.0
Major Version: 121
Truncated: 12
Fingerprint: Firefox12

User-Agent: Mozilla/5.0 ... Safari/17.2.1
Major Version: 17
Truncated: 17
Fingerprint: Safari17

Supported Browsers

Fingerprint validation is simple and fast: we compare the current browser fingerprint to the stored one. If they don't match exactly, the request is rejected with BROWSER_MISMATCH.

Validation Process

Validation Outcomes

Error Response

When validation fails, the server logs the mismatch (stored vs current fingerprint) and returns HTTP 403 with error code BROWSER_MISMATCH. The user must log in again to create a new session.

Browser updates are frequent - Chrome updates every few weeks. To avoid forcing users to re-login after every update, we truncate the version number so that minor updates don't change the fingerprint.

Truncation Effect

Why This Design?

Edge Cases

We track IP addresses for each session to help you monitor where your account is being accessed. This information appears in the session list and can help identify unauthorized access.

IP Data Collected

IP History Structure

"ipHistory": [
  {
    "ip": "192.168.1.100",
    "firstSeen": "2024-01-15T10:30:00Z",
    "lastSeen": "2024-01-15T14:22:00Z",
    "requestCount": 47
  },
  {
    "ip": "10.0.0.50",
    "firstSeen": "2024-01-16T09:00:00Z",
    "lastSeen": "2024-01-16T17:30:00Z",
    "requestCount": 123
  }
]

IP Display in Dashboard

Activity Updates

IP history and activity timestamps are updated at most every 5 minutes to reduce Redis writes. The current IP is checked and added/updated in the history array, with the oldest entry removed if 20 IPs are already tracked.

Memescale never stores plaintext passwords. All passwords are processed through a multi-layer hashing system that provides protection against dictionary attacks, rainbow tables, and database theft.

Password Hashing Process

Security Parameters

Password Requirements

Legacy passwords using SHA-256 are automatically upgraded to bcrypt on successful login. This transparent migration ensures all users benefit from the stronger algorithm without requiring password resets.

Login is a multi-step process that validates credentials, assesses risk, and establishes a secure session bound to the user's device. Each step must succeed for login to complete.

Login Sequence

Login Response States

Failed Login Handling

Session enhancement transforms a basic session into a fully secured, device-bound session. This process occurs immediately after login and adds all the security metadata needed for ongoing protection.

Enhancement Steps

Enhanced Session Data

{
  "sessionId": "sess_abc123...",
  "state": "ACTIVE",
  "fingerprint": {
    "hash": "sha256:def456...",
    "components": {
      "screenResolution": "1920x1080",
      "timezone": "America/New_York",
      "language": "en-US",
      "platform": "Win32",
      "hardwareConcurrency": 8,
      "deviceMemory": 16,
      "colorDepth": 24
    }
  },
  "binding": {
    "token": "bind_xyz789...",
    "hash": "sha256:ghi012..."
  },
  "ipAddress": "192.168.1.100",
  "userAgent": "Mozilla/5.0..."
}

Re-authentication provides an additional verification step for sensitive operations. Even with a valid session, users must prove they know the current password before performing high-risk actions.

Operations Requiring Re-auth

Re-auth Flow

The password reset flow provides a secure way to recover account access when the password is forgotten. The process uses cryptographically secure tokens with strict expiration and usage limits.

Reset Request Flow

Reset Completion Flow

Velocity tracking monitors the frequency of login attempts across multiple dimensions: per-user, per-IP, and globally. Abnormal patterns trigger protective actions before damage occurs.

Velocity Metrics

Velocity Data Structure

Key: {auth}:velocity:{userId}
Type: Sorted Set
Members: Timestamps of login attempts
Score: Unix timestamp (ms)
TTL: 1 hour (auto-cleanup)

Example:
  Member: "1705321200000:success:192.168.1.1"
  Score: 1705321200000

Rate Calculation

Beyond simple velocity limits, our anomaly detection system learns normal behavior patterns and flags deviations. This catches sophisticated attacks that operate below velocity thresholds.

Detected Anomalies

Behavioral Baseline

Anomaly Response

The risk scoring engine combines all available signals into a single score that determines the authentication response. This enables nuanced decisions rather than binary allow/deny.

Risk Factors

Score Calculation

Base Score: 0

For each factor:
  Low Risk:    +0 points
  Medium Risk: +15 points
  High Risk:   +30 points

Multipliers:
  Previous account lock:     1.5x
  Recent password reset:     1.2x
  First login ever:          0.8x

Final Score = Sum of factors × Multipliers

Score Thresholds

Account locking is a protective measure that prevents further authentication attempts when suspicious activity is detected. We use tiered locking to balance security with user convenience.

Lock Types

Lock State Data

{
  "locked": true,
  "lockType": "hard",
  "lockedAt": "2024-01-15T10:30:00Z",
  "lockedUntil": "2024-01-15T11:30:00Z",
  "reason": "10 consecutive failed login attempts",
  "failedAttempts": 10,
  "lockingIP": "192.168.1.100",
  "lockingUserAgent": "Mozilla/5.0..."
}

Lock Progression

Brute force protection combines rate limiting, account locking, and IP blocking to make automated password guessing impractical. Each layer adds friction for attackers while minimizing impact on legitimate users.

Protection Layers

Attack Resistance Analysis

Distributed Attack Defense

Distributed attacks using botnets bypass IP-based rate limiting. We counter this with account-level locks that apply regardless of source IP. An account with 5 failures is locked whether those failures came from 1 IP or 5 different IPs.

The audit trail captures all security-relevant events in your account. Each event includes who did what, when, from where, and the outcome. This data is essential for security investigations and regulatory compliance.

Event Categories

Event Risk Levels

Full Event List

Our audit logging mechanism captures events in real-time with full contextual data. Events are logged before the triggering action completes, ensuring that even failed or interrupted operations are recorded.

Event Structure

{
  "eventId": "evt_abc123...",
  "type": "login_success",
  "riskLevel": "low",
  "userId": "user_xyz...",
  "username": "johndoe",
  "sessionId": "sess_def456...",
  "ipAddress": "192.168.1.100",
  "userAgent": "Mozilla/5.0...",
  "fingerprint": "sha256:abc...",
  "metadata": {
    "loginMethod": "password",
    "deviceType": "desktop",
    "location": "New York, US"
  },
  "outcome": "success",
  "timestamp": "2024-01-15T10:30:00.123Z"
}

Logging Pipeline

Captured Context

Audit storage uses Redis sorted sets for efficient time-range queries combined with hashes for full event data. This architecture supports both real-time monitoring and historical analysis.

Storage Structure

# User's audit log (sorted set)
Key: {auth}:audit:{userId}
Members: Event IDs
Score: Unix timestamp (ms)

# Individual event (hash)
Key: {auth}:audit_event:{eventId}
Fields: type, userId, sessionId, ipAddress, ...

# Event type index (sorted set)
Key: {auth}:audit_type:{type}:{userId}
Members: Event IDs
Score: Unix timestamp (ms)

Query Patterns

Storage Limits

Retention policies balance the need for forensic analysis against storage costs. Different event types may have different retention periods based on their security significance.

Retention Periods

Cleanup Process

When a security incident occurs, the audit trail provides the evidence needed to understand what happened, when it happened, and what the attacker accessed. This data is crucial for incident response and remediation.

Investigation Capabilities

Common Investigation Queries

Forensic Report Contents

1. Incident Summary
   - Detection time
   - Affected accounts
   - Severity assessment

2. Timeline
   - Chronological event listing
   - Key events highlighted

3. Attack Analysis
   - Entry point
   - Actions taken
   - Lateral movement

4. Impact Assessment
   - Data accessed
   - Actions performed
   - Persistence mechanisms

5. Indicators of Compromise
   - IP addresses
   - Fingerprints
   - Behavior patterns

Security alerts keep you informed about your account's security status. Each alert type has a specific purpose and requires different levels of attention.

Alert Categories

Alert Severity Levels

Alert Details

Each alert type has specific conditions that trigger it. These triggers are carefully calibrated to notify you of genuinely important events while avoiding alert fatigue.

Trigger Conditions

Suspicious Login Factors

Trigger Debouncing

To prevent alert floods, some triggers are debounced. For example, multiple failed login attempts within a short window generate a single aggregated alert rather than one per attempt.

Alerts are delivered through multiple channels to ensure you receive important security notifications promptly. The delivery method depends on alert severity and your preferences.

Delivery Channels

Dashboard Alerts

Email Notifications

Email notifications include a summary of the alert with key details. For security reasons, emails do not include sensitive information like full IP addresses or session tokens.

Subject: [Memescale] New login from unknown device

-----------------------------------------
A new login was detected on your account.
-----------------------------------------

Device: Chrome on Windows
Location: San Francisco, CA, US
Time: January 15, 2024 at 10:30 AM PST

If this was you, no action is needed.

If this wasn't you, please:
1. Log in and review your sessions
2. Terminate unknown sessions
3. Change your password

Review your security at:
https://app.memescale.ai/orders

The security dashboard provides comprehensive alert management capabilities. You can review, acknowledge, and act on alerts without leaving the dashboard.

Alert States

Alert Actions

Actionable Alerts

Some alerts include direct action buttons to streamline your response. These actions are pre-authenticated through your current session.

Bulk Operations

For users with many alerts, bulk operations are available. You can mark all alerts as read with a single click, or filter alerts by type to manage specific categories.

Encryption at rest ensures that data remains protected even if storage media is compromised. We employ multiple encryption strategies depending on the data sensitivity level.

Encrypted Data Types

Password Storage

Passwords use one-way hashing rather than reversible encryption. Even with full database access, original passwords cannot be recovered. We use bcrypt with 12 rounds and a server-side PEPPER.

$2b$12$[22 chars salt][31 chars hash]

Components:
- $2b$     : bcrypt version identifier
- 12       : cost factor (2^12 iterations)
- salt     : 22 base64 characters
- hash     : 31 base64 characters

Database Encryption

Data in transit is protected using Transport Layer Security (TLS). All client-server communication and internal service communication uses encrypted channels.

TLS Configuration

HTTP Security Headers

Cookie Security

Cryptographic key management is critical to maintaining data security. Keys are stored securely, rotated regularly, and accessed only by authorized systems.

Key Types

Key Storage

Key Rotation Process

Data isolation ensures that one user cannot access another user's data, even if they discover internal identifiers or attempt to manipulate API requests.

Isolation Mechanisms

Key Namespace Structure

{auth}:user:{userId}           # User profile
{auth}:user_sessions:{userId}   # Session index
{auth}:audit:{userId}           # Audit events
{auth}:alerts:{userId}          # Security alerts
{auth}:velocity:{userId}        # Login velocity

Cross-reference keys:
{auth}:session:{sessionId}      # Session data
{auth}:username:{username}      # Username -> userId

Authorization Checks

Every API endpoint that accesses user data performs authorization checks. The pattern is consistent: extract user ID from session, verify requested resource belongs to that user.

// 1. Validate session
const session = await validateSession(request);
if (!session.valid) return unauthorized();

// 2. Extract user ID from session
const userId = session.userId;

// 3. Verify ownership of requested resource
const resource = await getResource(resourceId);
if (resource.userId !== userId) {
  return forbidden();
}

Every API request passes through the withApiAuth middleware, which enforces the complete session triplet validation. This happens on every single request - there's no caching of authentication state.

Middleware Pipeline

Validation Results

Protected Routes

Beyond authentication, the middleware can enforce authorization rules. Routes can require that the user has a folder (account with data), owns a specific bot, or respect certain rate limits.

Middleware Options

Bot Ownership Verification

// Example route with bot ownership requirement
export const POST = withApiAuth(
  async (req, { userId, bot, folderId }) => {
    // bot is verified to be owned by userId
    // folderId is the user's storage folder
    return NextResponse.json({ success: true });
  },
  { requireBotOwnership: { from: 'body', field: 'botId' } }
);

Rate Limit Configuration

Every successful request updates your session's lastActivity timestamp. However, to avoid hammering Redis with writes, updates are throttled to at most once every 5 minutes.

Activity Update Rules

What Gets Updated

Session Expiration

If you don't make any authenticated requests for 7 days, your session expires automatically via Redis TTL. The next request will fail with SESSION_NOT_FOUND and you'll need to log in again.

HMAC reconstruction is what makes session hijacking nearly impossible. Even if an attacker gains access to Redis, they cannot forge a valid powxd because the HMAC secret is never stored - it's only in the server's environment.

Reconstruction Process

The HMAC Formula

// Data components from Redis session
data = `${challenge}|${nonce}|${resultHash}|${userId}|${sid}|${timestamp}`

// HMAC computation (POWXD_SECRET is server-side only)
expectedPowXd = HMAC-SHA256(POWXD_SECRET, data)
  .digest('hex')
  .slice(0, 32)  // 128-bit = 32 hex chars

// Comparison
if (cookiePowXd !== expectedPowXd) {
  return { valid: false, code: 'INVALID_PROOF' }
}

Why Reconstruction Works

The security dashboard is your central control panel for account security. It displays real-time information about sessions, alerts, and activity, giving you complete visibility into your account's security posture.

Dashboard Sections

Security Status Indicators

Dashboard Location

The security dashboard is integrated into the bot management page. It appears at the bottom of the management tab, always visible regardless of whether you have active bots.

The active sessions view shows every device currently logged into your account. Each session displays device information, location, and last activity time.

Session Information

Session Actions

Session Sorting

Sessions are sorted with your current session first, followed by most recently active sessions. This makes it easy to identify and manage sessions you're currently using.

Login history shows all authentication attempts on your account, including successful logins and failed attempts. This helps you identify unauthorized access attempts.

History Fields

History Retention

Suspicious Patterns

The security dashboard provides quick access to common security actions. These actions are designed for rapid response to security concerns.

Available Actions

Emergency Response

If you suspect your account is compromised, follow this emergency response procedure from the security dashboard:

Action Confirmation

Destructive actions like terminating sessions require confirmation. A confirmation dialog shows exactly what will happen before proceeding.

Session Limits

The dashboard also displays your current session count and any applicable limits. While there's no hard limit on concurrent sessions, unusual session counts may trigger security reviews.