A dedicated authentication portal now provides one clear security address
The new portal gives the Auto Secure Login portfolio a central address for authentication work instead of asking every application to invent a different multi-factor setup. Visitors and authorized users can recognize auth.autosecurelogin.com as the sign-in domain, while individual products can continue to operate on their existing addresses. The portal is served over an automatically renewable HTTPS certificate so passwords, temporary codes and session information are protected in transit.
The authentication process runs as its own restricted service. Its application listener is available only on the server itself and public requests pass through the established web gateway. Sensitive enrollment records are encrypted at rest, login attempts are rate limited, and the server clock is synchronized because accurate time is essential for time-based codes. These controls do not make any system invulnerable, but they reduce avoidable risk and create an auditable foundation for future product integrations.
Delivered in this update
- Dedicated HTTPS address at auth.autosecurelogin.com
- Isolated service and loopback-only internal listener
- Encrypted factor storage and controlled file permissions
- Time synchronization and protection against repeated login attempts
Authenticator apps can now generate time-based one-time passwords
The first enrolled account uses a standards-based time-based one-time password, commonly called TOTP. A compatible authenticator app scans a private QR code once and then generates a six-digit code that changes every thirty seconds. The code is entered after the normal password, so a copied password alone is not enough to complete sign-in. This works with common authenticator applications that implement the TOTP standard and does not require a text message for every login.
Authenticator codes are useful, but they must be described honestly. TOTP reduces exposure to password reuse and many credential-stuffing attacks, yet a convincing phishing page can still trick someone into entering a current code. Users should confirm that the browser is on the exact auth.autosecurelogin.com address before entering credentials. Enrollment QR codes are equivalent to secrets and must never be posted, emailed casually or stored in public project files.
Delivered in this update
- Standards-based six-digit codes that rotate every thirty seconds
- No SMS delivery required for ordinary authenticator login
- One-time code replay protection after a code is accepted
- Clear guidance to protect enrollment QR codes and verify the sign-in domain
Passkeys and security keys add a stronger phishing-resistant direction
The portal is also prepared for WebAuthn passkeys and physical security keys. These methods bind authentication to the real website origin and can require a device gesture, biometric check or hardware-key touch. That makes them more resistant to phishing than a typed one-time code. TOTP remains valuable for broad compatibility, while passkeys are the preferred direction for administrators and other higher-risk accounts as integrations mature.
Strong authentication also needs a responsible recovery plan. A secure team should enroll more than one approved factor where appropriate, maintain a controlled administrative recovery process and promptly remove a lost device. Recovery must not become an easy bypass around multi-factor protection. The initial administrator setup material was delivered only into protected local files, and no QR secret, password, credential or private operating detail is included in this public update.
Delivered in this update
- WebAuthn support for passkeys and compatible hardware security keys
- User verification required when a registered authenticator supports it
- Multiple-factor and lost-device planning before wider rollout
- No credentials, enrollment secrets or protected implementation details published
Application integration will be staged instead of forcing a risky mass cutover
The new address does not automatically replace the user database or login screen of every product. Repo Runner, Sentinel, Outside Access, ASL Direct, StubSafe and the other applications have different users, roles and consequences. Each integration needs a defined callback, account mapping, authorization policy, logout behavior, session lifetime, audit trail and recovery path. OpenID Connect or protected gateway integration will be enabled only when the receiving application has a real registered callback and a tested rollback plan.
That staged approach keeps current applications available while the identity layer is verified. The next work is to select the first internal application, connect a small administrator group, test authenticator and passkey sign-in, verify role boundaries, and then expand only after the evidence is reviewed. Automated email recovery is intentionally not advertised as active until a dedicated working mail credential is installed. Today’s release is a usable authenticator foundation and a concrete security improvement, not a claim that every portfolio account has already been migrated.
Delivered in this update
- Per-application callback, role and session review before activation
- Small pilot group and rollback path for the first integration
- Existing application logins remain unchanged during verification
- Email recovery stays limited until a dedicated delivery credential is validated