Security - Article

Overview

The Security settings page centralizes the core controls that protect your Eurekos platform against unauthorized access, automated abuse, and misconfigured access policies. These settings are designed to help administrators manage security proactively—rather than reacting to incidents after they occur.

In real-world environments, learning platforms are exposed to many of the same risks as other web applications. These include:

• Automated bot attacks targeting login and signup forms
• Credential stuffing using leaked usernames and passwords
• Unauthorized account sharing or misuse
• Malicious file uploads and content exploitation
• Geographic or domain-based access risks

Eurekos addresses these challenges through a layered security model, where multiple controls work together to reduce risk across different entry points and behaviors. Instead of relying on a single mechanism, the platform combines prevention, detection, and enforcement:

• Prevention → blocking automated abuse and limiting attack attempts
• Detection → identifying suspicious login behavior and anomalies
• Enforcement → restricting access based on IPs, domains, or geographic location

This approach aligns with common cybersecurity principles such as defense in depth and least privilege access, while remaining configurable to match your organization’s risk profile.

Administrators can use these settings to define how open or restricted the platform should be—whether supporting a public training environment with thousands of external users, or a tightly controlled internal academy with strict compliance requirements.

Rather than applying a one-size-fits-all model, Eurekos provides the flexibility to:

• Balance security and user experience
• Adapt to different audiences and business models
• Continuously refine protection based on real usage patterns

In practice, this means that security is not a static configuration—but an ongoing process of monitoring, adjusting, and aligning with both risk and operational needs.

Configurations

The Configurations tab contains active, real-time protections that govern login behavior, signup processes, and session handling. These controls are primarily designed to protect against automated attacks, credential abuse, and unauthorized access patterns, while still allowing legitimate users to access the platform without unnecessary friction.

Login Flood Control

Login forms are one of the most common targets for automated attacks, including brute-force attempts and credential stuffing using leaked usernames and passwords. Attackers may attempt thousands of login combinations in short bursts, either targeting a single account or testing many accounts from the same source.

Login flood control protects the platform by introducing rate limiting on failed login attempts, both for individual accounts and for IP addresses.

• Limits failed login attempts by user account
• Limits failed login attempts by IP address
• Supports temporary blocking and escalation to blacklist

Once the defined thresholds are exceeded:

• The affected user account or IP address is temporarily blocked from further login attempts
• A corresponding event is recorded in the platform’s security logs (Flood Events)
• In repeated or aggressive cases, the IP may be escalated and added to the IP Blacklist

User-based protection helps prevent targeted attacks against a specific account (e.g., repeated password guessing). IP-based protection helps mitigate broader automated attacks, even when multiple accounts are targeted.

How to think about this:

• User-based thresholds protect individual accounts from targeted attacks
• IP-based thresholds protect the platform from automated or distributed attacks
• Together, they significantly reduce the effectiveness of brute-force and credential-stuffing attacks

Administrative impact:

Stricter thresholds improve protection, but may temporarily block legitimate users who mistype credentials multiple times. More relaxed thresholds reduce friction, but increase exposure to automated attack attempts.

Typical use cases:

• Public platforms → stricter thresholds recommended
• Internal or trusted environments → moderate thresholds may be sufficient

Parallel Sessions

Parallel session control governs whether a user account can be active on multiple devices at the same time. While not primarily a defense against external attacks, it plays a key role in controlling account usage, access integrity, and license compliance.

When parallel sessions are unrestricted, a single account may be used across multiple users or devices simultaneously. This can lead to unintended account sharing, reduced auditability, and misuse of paid or restricted access.

• Disabled → users can log in on multiple devices, but each new login replaces the previous session
• Enabled → only one active session is allowed; logging in on a new device will terminate the existing session

For commercial or certification-based platforms, unrestricted sessions can undermine both security and business models, as one account may effectively be shared across multiple individuals. 

Restricting parallel sessions may impact user experience (e.g., switching between devices). Allowing parallel sessions increases flexibility but reduces control over how accounts are used.

How to think about this:

• This is an access control mechanism focused on usage integrity rather than attack prevention
• Restricting sessions improves control and traceability
• Allowing sessions improves flexibility and user convenience

Typical use cases:

• Certification or paid content → restrict parallel sessions
• Internal training or flexible learning → allow multi-device access
• Role-based control → restrict participants while allowing instructors or managers more flexibility

IP Tracking

Not all security risks come from repeated failed attempts—some come from unexpected behavior patterns. For example, if a user logs in from two geographically distant locations within a short timeframe, this may indicate a compromised account.

IP tracking introduces a behavioral detection layer, helping identify anomalies without actively blocking access. Instead, it raises awareness through alerts, allowing users or administrators to take action.

• Maximum IP distance → defines the allowed distance (in kilometers) between consecutive login locations; exceeding this threshold triggers a security alert
• Retention policy → determines how long IP and login activity data is stored (in days) before being automatically deleted

If unusual login behavior is detected, the user receives a security notification prompting them to review their account activity and take corrective action, such as updating their password. The notification email can be configured in Settings → Email sending → Account.

How to think about this:

• This is a detection mechanism, not a blocking mechanism
• Useful for identifying compromised accounts or shared credentials

Example:

A user logs in from Denmark and shortly after from another continent → triggers alert.

Password Policy

Passwords remain one of the most common entry points for unauthorized access. Weak, reused, or outdated credentials significantly increase the risk of account compromise—particularly in scenarios involving credential leaks or reuse across multiple platforms.

The password policy enforces credential lifecycle management, ensuring that user passwords are regularly updated and cannot be reused indefinitely. This reduces long-term exposure and aligns with common security and compliance practices.

• Expiration period → defines the number of days before a password expires, counted from the last password update
• Advance notification → users receive an email reminder before expiration (default: 5 days)
• Password reuse restriction → previously used passwords cannot be reused within a 1 year + 1 month period

If a password is not updated within the defined expiration period, the account is automatically blocked, regardless of whether the user has been active or inactive during that time  .

Important considerations

• Password expiration is disabled by default (“Never expires”) and must be explicitly configured
• Expiration policies apply only to Eurekos-managed accounts
• Users authenticated via SSO (Single Sign-On) are not subject to this policy and will instead follow the password rules defined in their identity provider
• Users linked to removed SSO accounts will not receive expiration emails or be blocked by this mechanism

Users are notified in advance when their password is about to expire, allowing them to take action before access is restricted. These notifications can be configured in Settings → Email sending → Account.

How to think about this:

• Enforcing expiration reduces long-term credential risk but introduces user friction
• Disabling expiration improves usability but increases reliance on user behavior and external security controls (e.g., SSO, MFA)

Typical use cases:

• Compliance-driven environments → enforce expiration and reuse restrictions
• Open or low-risk platforms → may leave expiration disabled
• SSO-enabled environments → rely on external identity providers for password governance

Signup Flood Control

Signup forms are a primary target for automated abuse, including bot registrations, spam accounts, and attempts to exploit platform functionality (e.g., free access, data scraping, or phishing setups).

Signup flood control introduces rate limiting and automated blocking mechanisms to prevent repeated signup attempts from the same IP address or email within a defined time window.

• Limits attempts by IP address and email
• Supports both temporary and permanent blocking
• Automatically escalates repeated violations to the IP blacklist

Once the defined thresholds are exceeded:

• The user is temporarily blocked from signing up
• A corresponding record is created in the Flood Events log
• If abuse continues or exceeds stricter limits, the IP is permanently blocked and added to the IP Blacklist 

User experience:

• If the IP limit is exceeded, the user will see “Sorry, too many failed signup attempts from your IP address. This IP address is temporarily blocked. Try again later.”
• If the email limit is exceeded, the user will see “Too many failed signup attempts. Try again later.”

The user will not be able to retry until the configured time window has passed or the limit resets. Onscreen messages can be configured in Settings → Translations.

How to think about this:

• This protects the platform’s entry point, which is often the most exposed surface
• Combines rate limiting (temporary blocks) with escalation (blacklisting)
• Helps maintain both system performance and data quality

Administrative visibility:

• Temporary blocks → visible in Flood Events
• Permanent blocks → visible in IP Blacklist
• Administrators can review and clear events if legitimate users are affected

Typical use cases

• Public registration → strict thresholds required
• Closed/internal platforms → lower importance, but still recommended

Honeypot Protection

Many automated bots target publicly available forms to submit spam, create fake accounts, or exploit workflows. Unlike more advanced attacks, these bots often behave in predictable ways—such as filling in every available field in a form.

Honeypot protection introduces a hidden field that is invisible to real users but detectable by bots. If this field is completed, the submission is flagged as automated and blocked before it reaches the platform.

This provides a low-friction, invisible layer of protection without requiring user interaction (e.g., CAPTCHA).

Honeypot protection can be enabled for the following forms:

• Signup form → prevents automated account creation and bot registrations
• Contact form → blocks spam messages and malicious submissions
• Course on demand form → prevents abuse of request-based workflows (e.g., fake training requests or lead generation spam) 

Additionally, a time-based validation can be configured:

• Honeypot timer range → defines the minimum time required before a form can be submitted

Submissions that occur too quickly (faster than a human could realistically complete the form) are flagged as suspicious and blocked.

How to think about this:

• Works as a first-line defense against low- and medium-complexity bots
• Completely invisible to real users—no added friction
• Complements stricter mechanisms like signup flood control

Example:

A bot automatically fills out all fields in a signup form—including the hidden honeypot field—and submits it instantly. The system detects this behavior and blocks the request before an account is created.

Honeypot protection should generally be enabled on all available forms, especially in public-facing platforms, as it provides high value with no impact on user experience.

Flood Events

Security controls such as login flood control and signup flood control continuously monitor and react to suspicious activity. The Flood Events tab provides visibility into these actions by listing all temporary blocks triggered by these protections.

In practice, this means that whenever a user or IP exceeds configured thresholds (e.g., too many failed login or signup attempts), a corresponding record is created here.

Administrators can:

• Review failed login and signup attempts triggered by flood control mechanisms
• Identify patterns of abuse (e.g., repeated attempts from the same IP or email)
• Remove temporary blocks to allow legitimate users to retry

Deleting a flood event removes the temporary restriction, allowing the user or IP to attempt access again. However, if the IP has already been escalated to the blacklist, removing the flood event will not restore access  .

How to think about this:

• This is the operational log of real-time security actions
• Reflects events triggered by configured thresholds in login and signup flood control
• Used for monitoring, troubleshooting, and fine-tuning thresholds

Example:

A user enters the wrong password multiple times and is temporarily blocked → the event appears here and can be cleared by an administrator if needed.

IP Blacklist

The IP Blacklist tab represents the final enforcement layer for repeated or severe abuse detected by the platform’s security mechanisms.

IP addresses are typically added to the blacklist automatically when:

• Signup flood control thresholds are repeatedly exceeded
• Login flood control detects persistent or aggressive attack patterns

Administrators can also manually add or remove IP addresses as needed.

Once an IP is blacklisted:

• All access to the platform is blocked for that IP address
• The restriction remains in place until the IP is manually removed
• This applies regardless of user account or activity

This ensures that persistent sources of abuse are fully blocked from interacting with the platform  .

How to think about this

• This is a permanent enforcement mechanism, not a temporary restriction
• Acts as escalation from flood control → repeated abuse → full block
• Should be used for confirmed malicious or repeated unwanted behavior

Example:

An IP repeatedly attempts to create accounts or brute-force logins → after multiple violations, it is automatically added to the blacklist and blocked entirely.

Country restrictions

Country restrictions allow administrators to control platform access based on the geographic location of users, helping reduce exposure to high-risk regions, enforce compliance requirements, or limit access to specific markets.

This feature relies on IP-based geolocation and requires configuration of the integrated MaxMind service to resolve a user’s country based on their IP address. Without this configuration, country-based restrictions cannot be enforced.

Administrators can:

• Allow or block access from specific countries
• Restrict login, signup, or general platform access based on location
• Align access policies with legal, contractual, or security requirements

When a user attempts to access the platform:

1. Their IP address is evaluated
2. The IP is mapped to a country using the integrated MaxMind service
3. Access is allowed or denied based on the defined country rules

How to think about this

• This is a preventive access control mechanism, not a reactive one
• Complements other protections like IP blacklisting and flood control
• Effectiveness depends on the accuracy of IP geolocation data
• IP-based location is approximate and may be affected by VPNs or proxies

Example:

An organization operates only within the EU and wants to prevent access from outside regions. Country restrictions are configured to allow EU countries only, blocking all other traffic at the access level.

Signup Domain Management

Signup is one of the most critical—and most exposed—entry points to your platform. It must balance two often competing goals: providing a fast, frictionless onboarding experience for legitimate users, while ensuring that unauthorized or irrelevant users are prevented from gaining access.

The updated signup flow supports this balance by combining in-form password creation and email verification into a single, guided experience. Users can complete registration without unnecessary steps, while still validating their identity as part of the process.

Signup domain management builds on this by giving administrators control over how different users move through that flow, based on their email domain.

In practice, this means you can:

• Fast-track trusted users through a simplified signup experience
• Enforce stricter validation for unknown or external users
• Block unwanted domains entirely before accounts are created

This is particularly relevant for organizations that:

• Operate B2B or partner-based platforms
• Need to restrict access to specific companies or audiences
• Want to prevent registrations from public email providers (e.g. gmail.com) or disposable domains

What This Protects Against

Signup forms are a primary entry point to the platform. Without domain control, organizations risk:

• Registrations from irrelevant or unauthorized audiences
• Abuse from disposable or temporary email services
• Increased need for manual moderation and cleanup

Domain management introduces controlled onboarding, ensuring that registration behavior aligns with your intended audience and security posture. Administrators configure domain rules:

• Trustlist → approved domains with simplified validation flow
• Excludelist → blocked domains that cannot register
• Unlisted domains → standard validation applies

Each domain is evaluated during signup and directly influences how the user proceeds through the registration flow.

Impact on the signup flow

The signup process includes password creation and in-form email verification, and domain rules determine how this validation is applied.

Trustlisted domains:

• Users complete signup within a streamlined, single flow
• Email validation is handled seamlessly as part of the process
• Designed to reduce friction for known or trusted users

Unlisted domains:

• Users must complete explicit email verification within the signup form
• Verification is triggered via a modal during registration
• Ensures confirmation of email ownership before access is granted

Excluded domains:

• Signup is blocked immediately
• The user cannot proceed and is informed accordingly
• Prevents unwanted registrations at the earliest stage

How to think about this:

This is a signup flow control mechanism, not just a filter.

• Controls who is allowed to register
• Defines how strict the validation process should be
• Enables differentiated onboarding experiences based on audience

It allows you to balance:

• Low friction for trusted users
• Controlled verification for unknown users
• Strict restriction for unwanted domains

Example:

• Employees (@company.com) → streamlined signup experience
• External users → verified during signup
• Public email domains (e.g. gmail.com) → optionally blocked
• Known spam domains → excluded entirely (blocked)

File Types

File uploads are a common attack vector in many systems. Malicious files—such as executables or disguised scripts—can introduce security risks if not properly controlled.

The File Types tab ensures that only safe and approved file formats can be uploaded to the platform.

• Control allowed and blocked file extensions
• Validate MIME types
• Test file uploads before allowing them

Certain unsafe file types are always restricted at system level and cannot be overridden.

Why this matters:

Without restrictions, users could upload:

• Malicious executables
• Scripts disguised as documents
• Unsupported or harmful file formats

Typical use cases:

• Allow: PDFs, videos, presentations, learning assets
• Block: Executables, unknown or unsafe formats

⚠️ File type restrictions primarily apply to uploads made through standard user interfaces. Certain system-generated content or external integrations may not be subject to these limitations. Since validation is based on file type rather than deep file inspection, it is recommended to combine this setting with role-based permissions and content governance policies for stronger protection.

Account (Self-service account deletion)

The Account setting allows users to delete their own account directly from the platform. This is primarily a user-rights and privacy feature, enabling individuals to manage their personal data and remove their account when it is no longer needed.

From a regulatory perspective, this aligns with common privacy frameworks (such as GDPR), where users have the right to request deletion of their personal data. Providing a self-service option simplifies this process and reduces administrative overhead.

• Most relevant for open or externally facing platforms, where users register and manage their own accounts
• Less relevant for internal platforms or SSO-managed environments, where account lifecycle is controlled through identity providers or provisioning systems
• Should be evaluated in the context of data retention policies, compliance requirements, and business processes

Deleting an account is typically irreversible and may result in the removal of user data, access, and historical activity. Administrators should ensure this aligns with organizational policies for data retention, reporting, and compliance before enabling the feature.

How to think about this:

• This is a user autonomy and compliance feature, not a direct security control
• Supports privacy rights and data lifecycle management
• Reduces manual handling of account deletion requests

Example:

A public training platform allows users to sign up independently. Enabling account deletion allows users to remove their data without contacting support, ensuring compliance with privacy regulations and improving user trust.

Recommended Security Configurations

Security settings should be configured based on how your platform is used. The following presets combine practical recommendations and threshold guidelines to help administrators quickly establish a suitable security posture.

Security operates on a spectrum—from open and accessible to highly controlled and compliance-driven.

• Open Defaults prioritize accessibility and low friction
• Balanced Defaults provide strong protection for most use cases
• Strict Defaults enforce maximum control and auditability

Administrators should select a starting point based on their audience and risk profile, and adjust over time.

Recommended Defaults (Balanced)

For most platforms, this configuration provides a balanced approach between security and usability. It is well-suited for environments with external users while maintaining protection against common threats.

In this section you should consider:

• Enable login and signup flood control with moderate thresholds to prevent automated attacks without blocking legitimate users
• Enable honeypot protection on all public forms to silently filter bot activity
• Allow parallel sessions unless restricting account sharing is required
• Enable IP tracking to detect suspicious login behavior without blocking access
• Use domain verification or trustlists to control who can register
• Restrict file uploads to standard, safe formats such as documents and media files
• Enable self-service account deletion if operating an open platform, to support user privacy rights and reduce administrative overhead

When to adjust these defaults

• Increase restrictions for compliance-driven or enterprise environments
• Relax restrictions for open, low-risk training platforms focused on accessibility
• Monitor Flood Events regularly to fine-tune thresholds based on real usage

Strict Defaults (High-Security / Compliance)

This configuration prioritizes maximum protection, control, and auditability. It is designed for regulated environments or platforms with strict access requirements.

In this section you should consider:

• Apply strict login and signup flood control thresholds to minimize attack surface
• Enable honeypot protection across all forms
• Disable parallel sessions to prevent account sharing and ensure identity control
• Enforce password expiration and reuse restrictions
• Enable IP tracking with tighter thresholds for anomaly detection
• Restrict access using domain trustlists and country whitelisting
• Maintain and actively manage the IP blacklist
• Restrict file uploads to a minimal set of approved formats
• Evaluate whether self-service account deletion should be restricted or managed administratively to align with audit, retention, and compliance requirements

When to adjust these defaults

• Slightly relax thresholds if legitimate users are frequently blocked
• Increase monitoring of Flood Events to validate impact
• Align settings with internal security and compliance policies

Open Defaults (Low-Friction / Public Access)

This configuration prioritizes accessibility and ease of use while maintaining baseline protection against common threats.

In this section you should consider:

• Enable login and signup flood control with higher thresholds to reduce friction
• Enable honeypot protection as a low-impact safeguard against bots
• Allow parallel sessions for flexibility across devices
• Enable IP tracking for visibility without strict enforcement
• Allow open signup with optional email verification
• Apply standard file type restrictions to prevent unsafe uploads
• Enable self-service account deletion to support user autonomy and compliance with privacy expectations in open environments

When to adjust these defaults

• Tighten thresholds if abuse or bot activity increases
• Introduce domain restrictions if audience control becomes necessary
• Monitor Flood Events to identify emerging attack patterns

Final Note For Administrators

These presets are starting points—not fixed rules.

Effective security comes from:

• Monitoring real usage patterns
• Adjusting thresholds incrementally
• Balancing protection with user experience

There is no “perfect” configuration—only the one that best fits your platform’s risk profile and audience. Some settings—such as account deletion—are not strictly security controls, but part of broader governance, privacy, and lifecycle management decisions.