Consulta

Buen día
Se ha logrado lo del recordatorio de la clave, hasta el punto que el mail llega bien al usuario, pero se interrumpe la parte final

Al abrie el correo y dar clic en el link respectivo del mensaje Este mail fue enviado a esta cuenta porque se solicito un cambio de contraseña.Si usted solicito dicho cambio haga click en el siguiente link: Click Aqui El mismo sera valido unicamente por 24hs.

el link lleva a una ventana de la gráfica adjunta, pero me imagino que debe indicar en la misma otro mail con la clave pero NO muestra nada

Te agredezco que me orientes en este caso

Cordial Saludo


error link mail contraseAa.png

error link mail contraseAa.png

Buen día
Encontramos el problema y es que en la tabla apex_usuario el campo atentificacion debe ser bcrypt, y lo tenemos ‘plano’,
como podemos actualizar toda la BD, a bcrypt en masa ya que al aplicar el UPDATE valida con la tabla de apex_usuario_pwd_usados y no se permite?

Cordial Saludo

Hola Jhon,

Tienen una clase propia de usuario en el proyecto que redefina algunos metodos de la clase original?
Te consulto por lo siguiente, no hay forma que un usuario nuevo tenga como algoritmo algo distinto de sha256 o bcrypt desde la version 2.4 de Toba al menos.
El algoritmo original de Toba (0.9) en su momento fue smd5, con lo cual tampoco es viable que se guardaran los passwords en plano.

Tiene que haber codigo que este garantizando que eso siga asi hasta el dia de hoy.

como podemos actualizar toda la BD, a bcrypt en masa ya que al aplicar el UPDATE valida con la tabla de apex_usuario_pwd_usados y no se permite?

La mejor forma es ejecutando una SQL como la siguiente:

UPDATE apex_usuario SET forzar_cambio_pwd = 1;

Para forzar que todos los usuarios realicen el cambio de password, ya que el hash a almacenar se calcula al momento de actualizar el mismo.

Saludos

Richard, gracias por responder

Si efecitvamente esa es la opción que intentamos, pero como al estar la autentificación en ‘plano’, la funcionalidad de toba para forzar cambio, se interrumpe y NO llega a la interfaz de dicho cambio de contraseña, probamos con un usuario nuevo con bcrypt y funciona.

Lo de plano, se hizo un update intencional, para ver las claves, y poderselas recordar a los usuarios, pero ahora quisieramos reversar para aplicar dicha seguridad.
Lo que tengo pensado sería limpiar la base de datos y hacer un insert con dicha autentificacion.

Cordial Saludo

Hola Jhon,

La unica opcion que disponen entonces es generar un proceso que recupere la clave de los usuarios y luego utilice una llamada a toba_usuario::set_clave_usuario() para impactar sobre la base con la clave hasheada. Luego de dicho proceso, deberian forzar el cambio de clave.

Lo de plano, se hizo un update intencional, para ver las claves, y poderselas recordar a los usuarios, pero ahora quisieramos reversar para aplicar dicha seguridad.
Este tipo de practicas ha sido responsable de las peores filtraciones y problemas de seguridad a nivel mundial, ya que una vez filtrados los datos.. cualquiera puede acceder a la cuenta de cualquiera de esos usuarios, sin mayor conocimiento que hacer un copy-paste.

Un usuario jamas va a necesitar que le recuerden la clave, si que se le permita cambiarla en caso de olvido.

Lo que tengo pensado sería limpiar la base de datos y hacer un insert con dicha autentificacion.
No es necesario eso, con el procedimiento que te comente al ppio podrian lograr tener las claves encriptadas. Luego de ello tienen que vaciar la tabla que registra los passwords usados... de lo contrario quedarian los passwords en plano en dicho lugar.

Saludos