design - online - name tags printable

¿Es este un proceso de registro de usuario razonable? (10)

¿Parece estar pasando por un gran esfuerzo para una aplicación interna? ¿Cuánto fraude estás esperando?

Estoy trabajando en un proceso de registro para una aplicación interna. Mi diseño inicial está abajo.

Mi pregunta principal es si realmente es necesario incluir un registration_confirmation_code . ¿Protege la aplicación de una amenaza realista o simplemente agrega complejidad innecesaria? No estoy seguro de eso.

El usuario ingresa la dirección de correo electrónico. Como se trata de una aplicación interna, debe ser una dirección de agencia.
Si es una dirección de agencia válida, la aplicación crea una nueva fila en la tabla de usuarios.
- La tabla tiene una columna registration_confirmed que es false por defecto. La aplicación no permitirá que un usuario inicie sesión a menos que registration_confirmed sea true .
- La tabla tiene una columna registration_confirmation_code que es una cadena generada aleatoriamente.
La aplicación envía un correo electrónico a la dirección ingresada por el usuario. Contiene un enlace a una página que permitirá al usuario confirmar su registro y establecer su nombre de usuario y contraseña.
El enlace tiene la id del usuario y el registration_confirmation_code en la cadena de consulta:
http://agencydomain.com/users?id=123&registration_confirmation_code=fab49dk34nw97d
Al hacer clic en el enlace, el usuario verifica que la dirección ingresada es válida y que tiene acceso a ella.
La aplicación encuentra al usuario por ID. Antes de permitirles visitar la página donde pueden establecer su nombre de usuario y contraseña, la aplicación verifica que ...
- registration_confirmed es false . Solo deberían poder confirmar su registro una vez.
- registration_confirmation_code param coincide con el valor en el DB para ese usuario. Esto garantiza que se trata de una confirmación de registro legítima por parte del usuario previsto y no de que otra persona acceda a la URL con identificaciones aleatorias que intentan secuestrar un registro.
Si todo sale bien, la aplicación los lleva a una página con un formulario para configurar su nombre de usuario y contraseña.
Cuando envían el formulario con datos válidos, la aplicación establece registration_confirmed como true y se registran.

Aún necesita enviarles un código de confirmación por correo electrónico.

Dependiendo de la aplicación, no quieres que las personas se registren usando la dirección de correo electrónico de un compañero de trabajo.

Dejaría entrar al usuario justo después de que hagan clic en el enlace del correo electrónico, y les enviaré un pase ficticio que pueden cambiar más adelante. (use el correo electrónico para nombre de usuario)

esto elimina un paso del proceso y hace que el registro sea mucho más fácil.

El sistema OpenID fue inventado básicamente para resolver este problema. Básicamente, alguien llega a su sitio y dice "Soy XYZ, y puede verificarlo consultando con ABC". Luego tiene su proveedor de OpenID (que probablemente sea un servidor de su empresa, si tiene LDAP, ya está casi todo el camino), verifique que son quienes dicen ser (ingresando en el sitio del proveedor de OpenID). Si puede confiar en el proveedor de OpenID y la cuenta de OpenID no se ha visto comprometida, entonces acaba de verificar su usuario. Probablemente pueda escapar sin un proceso formal de registro ... simplemente envíelas a la pantalla de configuración de la cuenta (suponiendo que necesita más que la contraseña + correo electrónico en su ejemplo, ya que ambas se proporcionan a través de OpenID) en su primer inicio de sesión.

Tenga en cuenta que OpenID solo puede verificar que el usuario tenga las credenciales para el OpenID dado, no que el usuario sea único o que sean quienes dicen ser. Pero esto no es realmente diferente de cualquier esquema existente.

Tiene la ventaja de no requerir que el usuario le proporcione una contraseña que pueda olvidar (y pueden cambiar su contraseña con el proveedor de OpenID y se cambiará para todos sus sitios que usan OpenID). Hay librerías OpenID disponibles para la mayoría de los principales idiomas, y rodar el suyo no debería ser demasiado complejo.

Es una buena práctica verificar cualquier tipo de entrada que reciba de un visitante. La regla de oro es asegurarse siempre de obtener lo que espera, y nada más. Diría que lo estás haciendo bien, incluida la verificación de correo electrónico.

Una pequeña pregunta sin embargo; ¿Por qué hacer que sea un proceso de dos pasos? ¿por qué no permitir que el usuario ingrese una contraseña de inmediato? Esto generalmente se siente mucho más cómodo para el usuario.

Además, en lugar de usar registration_confirmation_code, es posible que desee considerar el uso de un hash MD5 (o similar) de la dirección de correo electrónico de los usuarios. De esta forma, no necesita el campo adicional e incluso puede omitir el ID si lo desea.

-Dave

Me gustan los sitios que usan la dirección de correo electrónico como ID de inicio de sesión. Además, ¿por qué no obtener la contraseña por adelantado cuando se registran?

No confíe en las personas, incluso si son internas de su organización. Suena mal, pero a menos que estés tratando con un grupo muy pequeño, tu método es una buena elección.

Una cosa más, es posible que desee asegurarse de que su correo electrónico sea único.

Otro enfoque es usar una autenticación centralizada y omitir todo el proceso de registro.

En el primer intento de inicio de sesión, cree un perfil de usuario a partir de una plantilla.

La autenticación se puede hacer de varias maneras. Idealmente, algo así como LDAP (o Active Directory si así es como te balanceas). También es posible usar el servidor de correo para la autenticación, dependiendo de cómo esté configurado.

Proteger su aplicación de usuarios aún menos verificados de lo normal es algo bueno, pero aún mejor es que está protegiendo a personas al azar de recibir correo no deseado desde su sistema. Al solicitar la suscripción voluntaria, se está asegurando de que X no pueda registrarse para su servicio y se declare que es Y, y que envíe el correo electrónico a Y cada vez que desee contactar al usuario. También le da a Y la oportunidad de decir "qué? No, este no soy yo" y hacer clic en rechazar, enviar un informe de ARF, o de lo contrario, hacerle saber que alguien lo está esperando.

Si recopila direcciones de correo electrónico, siempre debe verificarlas.

El único ''ataque'' al que se dirige a través de la confirmación por correo electrónico es registrar cuentas nuevas usando direcciones de correo electrónico aleatorias.

IOW, si deja ese paso, un ''atacante'' podría:

Registre cuentas usando solo direcciones de galimatías al azar
registrar cuentas usando las direcciones de otras personas

Afortunadamente, en la mayoría de las aplicaciones, tal ataque no es muy destructivo. Puede ayudar al atacante a forjar la identidad de otra persona en una aplicación de red social, o hacer la vida un poco más fácil para un spambot, o podría usarse solo para molestar al propietario legítimo de una dirección de correo electrónico, pero eso es todo.

Yo diría que mantenga el requisito de registro por si acaso, pero deseche el proceso de dos pasos (deje que los usuarios creen un nombre de usuario + contraseña de inmediato).