Registro de usuario de pagina web con correo de activación de cuenta

El sitio actualmente corre en Drupal, que es software libre así que puedes ver el código directamente, pero es PHP.

Estamos trabajando en una versión del sitio hecha en Java, el código lo puedes ver aquí pero todavía no tenemos hecha esa parte.

Hash no es encriptación, es una digestión, es irreversible. Se usa generalmente para almacenar passwords y eso sí ya lo tenemos hecho.

Gracias por responder, entonces ya tienen hecha la parte de almacenar passwords digeridos, me gustaría ver esa parte. Bajaré el proyecto que ya vi, que está algo complicado de clonar, pero lo lograré, jaja.

Por lo de correos de activación tienes algún material de referencia que pudieses proporcionarme para leer o alguna idea de como lo van a hacer.

Clonar? Veras que no es complicado, aqui te dejo este tutorial para que te bajes el proyecto javaMéxico 2.0.
Instalando el proyecto Java México 2.0 by @santos.r09

Saludos.

O otra opción es bajar

No necesitas siquiera tener base de datos instalada, solo lo bajas y lo ejecutas.

El mecanismo es como sigue:

1. El usuario se registra en la página, pone sus datos esenciales, entre ellos su username, mail y password, y pedimos captcha para validar que es humano.
2. El sistema inserta el nuevo registro en la tabla Usuario, con status de que está pendiente de activar, y genera un token que guarda también con el usuario (luego detallo esto del token)
3. Se envía un correo al usuario con una liga que contiene el token y, de manera codificada, la llave primaria del usuario. La liga apunta a un Servlet, servicio, página o lo que sea en la aplicación web que debe activar el usuario.
4. El usuario activa la liga y con eso invoca el servicio en nuestra app que primero decodifica la llave primaria del usuario, lo busca en la base de datos, verifica que tenga el status adecuado (pendiente de activación). Si todo coincide, entonces valida el token que viene en el URL, el cual debe coincidir con el que se tiene en la base de datos. Si coincide, entonces ya se le pone status activo al usuario, y se le pide que haga login (ya puso su password cuando se dio de alta).
5. Para mayor seguridad contra spam, en vez de activar al usuario en ese momento, se le puede pedir una última prueba, ya sea otro captcha o algo así. Nosotros pensamos además poner algunos candados de tiempo. Por ejemplo que no puedas agregar comentarios a blogs o foros sino hasta después de 10 minutos de haberte activado, no puedas poner nuevos posts en un foro o en tu blog sino hasta unos 20 minutos después de haberte activado, poner un límite de comentarios por hora o por minuto (o un tiempo mínimo entre comentarios)... tal vez analizar el texto que se quiere postear (sea donde sea) y en caso de que contenga ligas, pedir un captcha, cosas así. Puede hacer más incómoda la experiencia para algunos usuarios pero con eso se evita tanto spam que nos afecta actualmente.

En cuanto al token, hay varias maneras de hacerlo. Una muy sencilla es hacer un hash (MD5, SHA-1, SHA-256, etc) de datos que el usuario dio y de datos que el usuario no tiene (es ESENCIAL que se usen datos que el usuario no tiene, para que no puedan falsificar el URL sin ver el mail). Los datos que el usuario no tiene pueden ser simplemente aleatorios, por ejemplo generar 16 bytes aleatorios y pegarlos con el mail, nombre, password y sacar el hash de eso, ese el token.

El objetivo es que el token no se pueda falsificar, de modo que haya que abrir el correo y obtener la liga. Es bueno que el correo contenga otras ligas al mismo sitio, en formato muy similar, para confundir al software más avanzado que ya realiza el proceso complejo de registrarse en un sitio y luego revisar el correo para obtener la liga de activación. Pero aunque se pongan varias ligas, una es la de activación, por lo que si este software es modificado para seguir TODAS las ligas que vengan en el correo, se va a activar de todas maneras. Por eso es recomendable que incluso después de seguir la liga se le pida nuevamente alguna pueba para determinar que sea humano, como otro captcha o hacer alguna pregunta sencilla de responder para un humano pero no para un programa.

Recientemente leí de un mecanismo que requiere Javascript y que consiste en que se realicen cálculos en el navegador que sean algo costosos en CPU, de modo que un usuario normal no lo note mucho (si acaso un retraso de un par de segundos) pero para un programa que quiera realizar esa operación de manera simultánea porque quiere dar varios usuarios de alta, le cuesta mucho más tiempo. No sé qué tan eficiente sea y ciertamente no es sencillo de implementar, pero pues son opciones para combatir el spam.

Gracias por sus comentarios, acabo de leerlos, y voy a ponerlos en práctica, instalaré el proyecto y haré pruebas, gracias ezamudio por especificar los pasos a seguir para el correo de activación, y en definitiva creo que es imposible protegerte al 100% de accesos no autorizados, pero pues se tiene que dejar la app lo menos vulnerable posible.

Cualquier duda les escribo. :)

Si tu proyecto usa Spring, Spring Security es una buena opción, provee mecanismos para autorización y autenticación.

Yo lo acabo de implementar en un proyecto y no es tan complicado, ya provee el uso de roles, permisos, acceso a diferentes tipos de recursos, integración con datasource y cifrado vía md5, sha, etc...

Saludos.