Un portal de autenticación dedicado ofrece una dirección de seguridad reconocible
El nuevo portal crea una dirección central para el trabajo de autenticación del portafolio, en lugar de pedir que cada aplicación invente una configuración diferente de múltiples factores. Las personas autorizadas pueden reconocer auth.autosecurelogin.com como el dominio de acceso, mientras los productos conservan sus direcciones actuales. El portal usa un certificado HTTPS con renovación automática para proteger contraseñas, códigos temporales e información de sesión durante la transmisión.
El proceso de identidad funciona como un servicio independiente y restringido. Su interfaz interna solo escucha dentro del servidor y las solicitudes públicas pasan por la puerta web establecida. Los registros sensibles de factores se cifran, los intentos repetidos se limitan y la hora del servidor está sincronizada porque los códigos temporales dependen de un reloj exacto. Ningún control vuelve invulnerable un sistema, pero esta combinación reduce riesgos evitables y crea una base revisable para futuras integraciones.
Entregado en esta actualización
- Dirección HTTPS dedicada en auth.autosecurelogin.com
- Servicio aislado y puerto interno disponible solo dentro del servidor
- Almacenamiento cifrado de factores y permisos de archivo controlados
- Sincronización de tiempo y límites ante intentos repetidos de acceso
Las aplicaciones de autenticación ya pueden generar códigos temporales
La primera cuenta inscrita utiliza una contraseña de un solo uso basada en tiempo, conocida como TOTP. Una aplicación compatible escanea una imagen QR privada una sola vez y después genera un código de seis dígitos que cambia cada treinta segundos. El código se introduce después de la contraseña normal, por lo que una contraseña copiada no basta para completar el acceso. El método funciona con aplicaciones comunes que implementan el estándar TOTP y no necesita un mensaje de texto para cada inicio de sesión.
Los códigos de autenticación son útiles, pero deben explicarse con precisión. TOTP reduce la exposición causada por contraseñas repetidas y muchos ataques automatizados, aunque una página falsa convincente todavía puede pedir un código vigente. Antes de escribir credenciales, la persona debe confirmar que el navegador muestra exactamente auth.autosecurelogin.com. La imagen QR de inscripción equivale a un secreto y nunca debe publicarse, enviarse sin protección ni guardarse en archivos públicos del proyecto.
Entregado en esta actualización
- Códigos estándares de seis dígitos que cambian cada treinta segundos
- Sin depender de SMS para el acceso normal con autenticador
- Protección contra la reutilización de un código ya aceptado
- Orientación clara para proteger el QR y verificar el dominio de acceso
Las llaves de acceso y llaves físicas ofrecen una dirección más resistente al phishing
El portal también está preparado para llaves de acceso WebAuthn y llaves físicas compatibles. Estos métodos vinculan la autenticación con el origen real del sitio y pueden exigir un gesto en el dispositivo, una verificación biométrica o tocar una llave. Por eso resisten mejor el phishing que un código escrito. TOTP conserva una compatibilidad amplia, mientras las llaves de acceso son la dirección preferida para administradores y cuentas con mayor riesgo a medida que maduren las integraciones.
La autenticación fuerte también necesita una recuperación responsable. Un equipo debe registrar más de un factor aprobado cuando corresponda, mantener un proceso administrativo controlado y retirar con rapidez un dispositivo perdido. La recuperación no puede convertirse en un atajo que evite los múltiples factores. El material inicial del administrador se entregó solamente en archivos locales protegidos; esta publicación no contiene contraseñas, secretos QR, credenciales ni detalles operativos reservados.
Entregado en esta actualización
- Compatibilidad WebAuthn para llaves de acceso y llaves físicas
- Verificación de usuario cuando el autenticador registrado la admite
- Planificación de factores adicionales y pérdida de dispositivos
- Sin publicar credenciales, secretos de inscripción ni detalles protegidos
La integración de aplicaciones será gradual y no un cambio masivo arriesgado
La nueva dirección no reemplaza automáticamente la base de usuarios o pantalla de acceso de todos los productos. Repo Runner, Sentinel, Outside Access, ASL Direct, StubSafe y las demás aplicaciones tienen usuarios, funciones y consecuencias distintas. Cada integración necesita una devolución registrada, mapeo de cuentas, política de autorización, cierre de sesión, duración de sesión, auditoría y recuperación. OpenID Connect o la protección mediante puerta de acceso se habilitarán solo cuando la aplicación receptora tenga una dirección real registrada y un plan de reversión probado.
Este enfoque mantiene disponibles las aplicaciones actuales mientras se verifica la capa de identidad. El siguiente trabajo es elegir la primera aplicación interna, conectar un grupo pequeño de administradores, probar autenticador y llave de acceso, verificar límites de funciones y ampliar solo después de revisar la evidencia. La recuperación automática por correo no se presenta como activa hasta instalar una credencial de entrega dedicada y funcional. La versión de hoy es una base utilizable y una mejora concreta, no una afirmación de que todas las cuentas ya fueron migradas.
Entregado en esta actualización
- Revisión de devolución, funciones y sesiones para cada aplicación
- Grupo piloto pequeño y plan de reversión para la primera integración
- Los accesos actuales no cambian durante la verificación
- La recuperación por correo queda limitada hasta validar una credencial dedicada