uniqid() no crea un hash criptográficamente seguro, y el envío de datos confidenciales a través de canales de texto plano como el correo electrónico o http significa que cualquier persona intermedia puede leerlos.
¿Esto es un problema? No, en realidad no (con la excepción establecida en el último párrafo).
La información que envías consiste en la dirección de correo electrónico del usuario y una clave de confirmación. Esto también es lo que está almacenado en la base de datos. No hay forma de enviar un correo electrónico sin revelar la dirección de correo electrónico del destinatario, por lo que transmitir esa dirección en texto sin formato como parte de una URL tampoco es un problema. Si algún Gran Mal va a suceder, entonces ya ha sucedido.
Ahora, ¿qué pasa con la clave de confirmación?
Podrías estar dando enteros consecutivos como claves de confirmación (¡en realidad uniqid() no está muy lejos de eso!), y no importaría. Una persona malintencionada podría interceptar la clave de otra persona o podrían generar su propia cuenta de forma trivial, pero ninguna de ellas le permitirá registrar una cuenta falsa, ya que la consulta de la base de datos busca el par < username, confirm_key & gt ;. Una clave de confirmación robada o aleatoria / falsa / calculada, por lo tanto, no funciona con otro nombre de usuario (aleatorio), no tiene valor para un atacante.
El único ataque que es razonablemente plausible es que alguien pueda interceptar su correo electrónico y confirmar su cuenta legítima con la dirección de correo electrónico y la clave de confirmación correctas antes de poder hacerlo.
De hecho, esto es un problema si su sistema está diseñado para que la confirmación de una cuenta de usuario también lo inicie automáticamente en su primera sesión (¡algunos sitios hacen eso mismo!).