search

mxabierto / debate

(sin mantenimiento) Debate público sobre la Política Nacional de Datos Abiertos en México. Powered by DemocracyOS.
http://politica.datos.gob.mx
1 stars 0 forks source link

Rediseñar el sign-in y sign-up #32

Closed defvol closed 10 years ago

defvol commented 10 years ago

Los campos a mostrar serán:

La forma servirá tanto para el registro como el login.

thumbnail

cristiandouce commented 10 years ago

Esto es gracioso. Pasamos de ese formato al actual. @gvilarino tiene un muy buen argumento al respecto.

gvilarino commented 10 years ago

En rigor, debería ser configurable. En la implementación para el Partido de la Red es importante la validación de identidad, por eso somos rigurosos con el Nombre y el Apellido.

Como puede inferirse de #32, en el contexto de esta implementación, es más importante la cantidad de usuarios registrados que cualquier otra cosa, y al no haber validación de identidad tampoco tiene mucho sentido diferenciar por nombre y apellido.

defvol commented 10 years ago

Siendo sincero, esta idea salió de un brainstorming sin mucho fundamento. Yo personalmente veo innecesario este over-engineering.

Pero bueno, nuestra prioridad es disminuir pasos y ser un poco permisivos en cuanto a la identidad (pero evitando bots), por eso no requerimos apellido ni validación de emails.

Sin embargo me preocupa el spam. Estaba pensando integrar re-captch o meter un layer de seguridad como rack-attack.

gvilarino commented 10 years ago

Comparto disminuir pasos innecesarios y over-engineering.

Tanto re-captcha como rack-attack me parece un poco de over-engineering para el estado en que estamos (sin lanzar) y en particular re-captcha algo que no sólo no sirve sino que perjudica:

  1. Es mucho más tediodos para un usario completar un re-captcha que un campo común. Es cierto que no es más tedioso que validar un email.
  2. Los bots rompen los re-captcha con facilidad hoy en día (es nuestra experiencia con este sistema).

Yo lanzaría como está, incluso si desean quitando el campo de apellido y dejando sólo nombre, y la validación x email; y vería cómo se comporta. Faltando tan pocos días para que cierre la política, cada día que retrasamos la salida es un día menos de difusión y participación.

Y todos los cambios/mejoras/upgrades se pueden hacer con la plataforma en vivo; no hay problema con eso.

cristiandouce commented 10 years ago

Me parece mucho más simple validar un email que completar un re-captcha cada X cantidad de acciones.

gvilarino commented 10 years ago

:+1: @cristiandouce

defvol commented 10 years ago

nota: la fecha de participación la podemos aplazar, de hecho estamos considerando abrir el proceso todo marzo :)

@gvilarino conozco ataques sobre algunos tipos de captcha, pero no he visto nada mainstream sobre el re-captcha, tienen alguna referencia?

@cristiandouce totalmente de acuerdo, pero podríamos hacer que el re-captcha sea el equivalente a la validación vía correo. Es decir, sólo una vez ingresaría el re-captcha y con esto la cuenta se crearía validada.

cristiandouce commented 10 years ago

VK que es el facebook de Rusia utiliza un captcha cada vez que alguien quiere realizar una acción en su red... hasta que acepten ingresar un telefono celular al cual envian un código y luego de ingresar quedan validados. Y así no requieren volver a ingresar un captcha para mensajear o postear.

Yo quizá hasta haría las 2 cosas. Que de la validación por link enviado al email te lleve a una página donde deba ingresar un captcha por confirmar para que la cuenta quede validada.

Lo que si pueden hacer es implementar el método de esta red social que les digo. Dejar a los usuarios interactuar y navegar por la aplicación... solicitando captcha hasta que validen una cuenta de correo.

Thoughts?

Otra cosa interesante es la que hace STEAM. Cada vez que un usuario ingresa desde una máquina diferente, envía un correo electrónico con un nuevo código para agregar dicho dispositivo a una lista de terminales "seguras" para el usuario. Pero esto ya es hablar de seguridad, no anti-bot.

defvol commented 10 years ago

Buenos ejemplos.

Nuestro objetivo más que cuidar el robo de contraseñas, es simplificar la validación del registro.

Es por eso que creo que no necesitamos identificar accesos desde otras máquinas, ni validar más de una vez con captchas.

Trataré de tener un PR en unas horas.

cristiandouce commented 10 years ago

Entonces podrían directamente agregando el re-captcha al formulario de signup. Todo en 1 solo paso.

defvol commented 10 years ago

exacto

cristiandouce commented 10 years ago

Acabo de ver #35 y me surgió la siguiente pregunta:

¿Cómo recuperar contraseña sin cuenta de email validada?

Lo que se me ocurre es que en el momento que el usuario intenta recuperar su contraseña, si el email no estuviere validado, lo validen antes?

defvol commented 10 years ago

Se me ocurren los siguientes escenarios:

  1. (basado en el que mencionas), como el cambio de contraseña llega al correo registrado, matamos 2 pájaros de un tiro, es decir, el mismo cambio de contraseña se convierte en una validación de correo.
  2. Otra idea es remover la validación de correo, y que en el sign-up sea requisito llenar el captcha.

¿Cómo ves?

cristiandouce commented 10 years ago

Si quitas la validación del correo, entonces deberías quitar también la recuperación de contraseña.

De qué otra manera arreglarían que un usuario olvidara su contraseña?

cristiandouce commented 10 years ago

Ah, ya entendi.

A mi lo que no me gustaba era enviar un token de reset de contraseña a un email que no se sabe si pertenece o no a ese usuario. Pero, es lo mismo que al registrarse enviar el email de validacion de cuenta a un extraño. Así que si, se podría eliminar el paso si les parece.