2011-07-05 18 views
5

Buenas tardes,Registro de usuario (y autenticación posterior): ¿mi método o uso OpenID?

Estoy trabajando en un script para permitir que los usuarios de noticias se registren en un sitio web.

En pocas palabras, estos son los pasos que he planeado:

  1. register.php - Nuevo usuario rellena un formulario, introduciendo su nombre de usuario, datos de la dirección, razón social y dirección de correo electrónico. Los datos se vuelven a publicar en el script a través de SSL.

  2. register.php - El script comprueba que el nombre de usuario o dirección de correo electrónico aún no están almacenadas en la base de datos. Si no lo son, utiliza esos datos para generar un token, que se envía por correo electrónico a la dirección de correo electrónico en forma de hipervínculo, con ese token y el resto de los datos como parámetros de hyperlinlk. El token utilizado está hecho de una cadena secreta; de este modo, solo este script puede crear un código que pueda reconstruirse utilizando el resto de los datos.

  3. email - Se hace clic en el hipervínculo (SSL), pasando los datos a través de $ _GET al siguiente script mediante SSL.

  4. verify.php - El token se reconstruye utilizando los datos $ _GET pasados ​​y una cadena secreta conocida. Si el hash es idéntico, sabemos que el token fue generado por uno de nuestros scripts. Se le solicita al usuario que ingrese una contraseña (dos veces), antes de hacer clic en "enviar" (que publica los datos a sí mismo, a través de SSL).

  5. verify.php - El script comprueba el nombre de usuario o dirección de correo electrónico no existe, antes de introducir los nuevos datos de usuario en la base de datos, junto con una contraseña con algoritmo hash y la sal.

  6. correo electrónico - Una notificación por correo electrónico se envía al administrador, para decirles que un nuevo usuario se ha registrado -. El nuevo usuario debe ser aprobado antes de que puedan entrar en el correo electrónico contiene un enlace a la siguiente secuencia de comandos , con la ID del nuevo usuario que se transfiere a $ _GET. SSL es usado.

  7. confirm.php - La secuencia de comandos utiliza la ID aprobada del nuevo usuario para mostrar todos los detalles que se han registrado, en campos editables (no la contraseña o el salt). Al hacer clic en "confirmar", los datos del formulario se vuelven a enviar al mismo script, a través de SSL.

  8. confirm.php - El script actualiza el registro para ese usuario y establece el nuevo registro de usuario en "confirmado". El nuevo usuario recibe una notificación por correo electrónico y ahora puede iniciar sesión.

Esto puede parecer largo, pero hay una serie de pasos que deben completarse.

Todos los usuarios nuevos deben verificar su dirección de correo electrónico antes de almacenar los datos en nuestra base de datos. La contraseña no se pasa más de lo necesario. Solo se pasa en su forma original al script "verify.php" a través de POST, que luego lo procesa. Me aseguraré de que los datos POST para los paquetes SSL no estén registrados en el servidor. De esa forma, no debería haber registro de la contraseña sin procesar en el servidor, ¿verdad?

Se genera y almacena una sal aleatoria para cada usuario, para proteger contra tablas de arcoíris.

¿Me perdí algo? Mi único concierto es la transmisión de la contraseña sin formato a través de SSL. Aunque SSL protege contra el olfateo, todavía me inquieta recibir la contraseña sin procesar en el servidor. Dicho esto, no quiero hacer que el proyecto sea vulnerable a los ataques de "intermediarios", simplificándolo por el lado del cliente.

¿Alguien puede sugerir algún defecto en mi método? Intenté buscar en Google esto, y aunque hay algunas publicaciones aplicables, nada parece empatar en todo el proceso. Espero que este hilo beneficie a los futuros visitantes de esta página, así como a mí mismo.

Gracias.

+0

debe volver a utilizar un marco de autenticación existente siempre que sea posible, ya que, en realidad, es compleja. Por ejemplo, eche un vistazo a https://github.com/delight-im/PHP-Auth, que es tanto agnóstico como independiente de la base de datos. – caw

Respuesta

2

Tuve que hacer lo mismo hace 2 meses y lo hice a su manera. Excepto por este punto:

Antes de solicitar al usuario que ingrese todo, el primer paso debe ser validar y confirmar el correo electrónico. Una vez completado, le preguntamos todo lo demás.

Se alcanzan 2 objetivos: 1- los usuarios tienen miedo en algún momento de ingresar mucha información. Si ya enviaron su correo electrónico, generalmente están más dispuestos a continuar el proceso. 2- usuarios que ya se registraron y que están en la página incorrecta: puede suponer que perdieron su correo electrónico y proponer una solución (si el correo electrónico ya está en el db)

... pero personalmente creo que es el mejor Lo importante es seguir con openId ;-) La próxima vez, eso es lo que intentaré usar.

HTH

+0

Gracias Jean. Adoptaré sus recomendaciones, porque tienen mucho sentido. Creo que continuaré escribiendo estos guiones, ya que aprendí mucho de este proyecto y creo que será una buena oportunidad para aprender un poco más. –

Cuestiones relacionadas