Skip to main content
Site Store Pro supports an optional custom security layer that replaces Laravel’s standard bcrypt/argon password hashing with a RIPEMD-256 HMAC scheme keyed on unique per-user tokens. This layer is fully opt-in and activates with a single environment variable.

Custom Hashing & Login Security

Activating Custom Security

Set the CUSTOM_LOGIN_SECURITY environment variable to any non-empty value in your .env file:
The value itself is not significant — any non-null, non-empty string activates the feature. When this variable is absent or empty, Site Store Pro uses standard Laravel password hashing (bcrypt by default).

Per-User Security Tokens

When CUSTOM_LOGIN_SECURITY is active, every new user registration automatically generates two unique random strings stored on the user record: These tokens are generated at registration time and are unique to each user.

RIPEMD-256 HMAC Password Hashing

Passwords are stored as an HMAC hash computed using the RIPEMD-256 algorithm, keyed with the user’s unique user_token_1:
The resulting hash is what gets stored in the users table — not a bcrypt or argon hash.
Once CUSTOM_LOGIN_SECURITY is enabled and users have registered, do not disable this flag without a password migration strategy. Existing users’ stored hashes are RIPEMD-256 HMAC values and will not validate against standard Laravel hashing.

Seamless Authentication Fallback

The custom hashing layer is designed for transparent integration:
  • Login and credential confirmation requests automatically detect the active hashing mode
  • Standard Laravel auth guards continue to function normally
  • OAuth adapters (Google, Facebook, GitHub) are not affected
  • No changes to login views or form submissions are required
When a user authenticates, the system retrieves their user_token_1, recomputes the HMAC hash of the submitted password, and compares it to the stored value — all within the normal authentication pipeline.

Social OAuth Authentication

Site Store Pro supports social login through Laravel Socialite for the following providers:

Google

Sign in with Google OAuth 2.0

Facebook

Sign in with Facebook Login

GitHub

Sign in with GitHub OAuth

Social Login Setup

Supports:
  • Google
  • Facebook
  • GitHub (Note: If using a GitHub App, the app must have “Email addresses” selected under Permissions > Account permissions in your App settings under Settings > Developer settings > GitHub Apps > [App Name] > Permissions & Events)
Generate your domain’s social login app credentials through:
  • Google Developer Console
  • Meta Developer Console
  • GitHub Developer Settings (OAuth Apps / GitHub Apps)
Add:
Callback URLs:

Missing Email Address Fallback

If a social provider does not provide the user’s email address, the user is temporarily redirected to /auth/collect-email to supply a valid, unique email address.
  • Direct social registration (where email is provided) automatically sets email_verified_at to now().
  • Social registration where the email is collected manually keeps email_verified_at as null so they must verify their email.

To configure social OAuth providers, add the relevant credentials to your .env file