search

SIU-Toba / framework

Framework para desarrollo rápido de aplicaciones web
http://toba.siu.edu.ar
21 stars 24 forks source link

Usar las nuevas funciones de hasheo de PHP 7+ #3

Closed enfoqueNativo closed 6 years ago

enfoqueNativo commented 7 years ago

Hay que dejar de usar Crypt y pasar a password_hash, que autogenera su salt de manera segura. Hay que ver como hacer con los viejos metodos de hasheo, MD5, SHA-256, etc que todavia pueden estar dando vueltas en las instancias.

enfoqueNativo commented 7 years ago

@sergiovier , @andres-blanco sale cambio de contraseña masivo?

sergiovier commented 7 years ago

Estaría bueno que se pueda forzar el cambio de clave al usuario y al momento de actualizar, que ahí use el nuevo algoritmo. No se si nos queda otro camino.

andres-blanco commented 7 years ago

Hola! Deberíamos tener un documento con la desición de cambiar de algoritmo de hasheo. Esto afecta también (y más de lleno me parece) a Araí-Usuarios. Tendríamos que definir que estrategia tomamos y ser bien claros. Ser obligatorios y forzar a todos es muy raro. Quizá de alguna manera tercializar la responsabilidad del force a los proyectos?

enfoqueNativo commented 7 years ago

Deberíamos tener un documento con la desición de cambiar de algoritmo de hasheo. Esto afecta también (y más de lleno me parece) a Araí-Usuarios.

El documento donde se detalle el cambio se puede hacer, no es problema. Que parte de Araí-Usuarios afectaría esto?..la auth no la maneja el simplesaml derecho viejo?.

Ser obligatorios y forzar a todos es muy raro. Quizá de alguna manera tercializar la responsabilidad > del force a los proyectos?

La vez anterior se le dejó la responsabilidad a los proyectos. El problema es que hay lugares que aún usan la función vieja de hasheo de PHP, que no es compatible con crypt, ni con password_hash, con lo cual estamos manteniendo codigo viejo para hacer uso de una funcion vulnerable, eso tiene que desaparecer.. es un tumor.

sergiovier commented 7 years ago

@andres-blanco @enfoqueNativo que les parece si con el instalador y luego de una actualización, se verifique el método del algoritmo de los usuarios y los marque para forzar el cambio de clave? Ya con eso se da un método para dar el salto de forma transparente.

Arai-Usuarios hoy maneja crypt, el hash se genera desde el proyecto, se usa un salt incluso... y hay soporte a muchos algoritmos dando vueltas por ahi.

enfoqueNativo commented 7 years ago

@sergiovier No creo que deba hacer eso el instalador, es un tema de la plataforma y meterse por ese camino lo pegaria demasiado a cuestiones muy especificas generando un acoplamiento innecesario.

Decidir quien si y quien no, va a ser complicado.. porque pueden estar usando SHA-2 como algoritmo a traves de crypt o de hash, todo dependió en su momento de lo que tenia disponible PHP en esa distro en ese momento. Esos 2 hash ya no son iguales, la otra es buscar marcadores en el hash derecho viejo... pero se me hace muy delirante.

Para terminar con esa dualidad tiene que ser todo o nada, ya sea que lo haga Toba o los proyectos... el nada, los deja durmiendo en esas versiones. ZZZZZzzzzzz

Si Arai-Usuarios viene usando crypt entonces no deberia tener inconveniente ya que los hashes son compatibles, la mejora de password_hash va por el lado de generar el salt internamente, que es mucho mejor a menos que ya vengas usando openssl para ello. Van a seguir con esa API para lo que es passwords.. así que parece coherente migrar ahí, para el resto de los hashes con crypt y un buen salt via openssl va.

sergiovier commented 7 years ago

Otra solución factible (lo hacen los mas grandes, no estamos reinventando acá) es marcar como deprecated esa función en su uso, así logras varias cosas:

Hasta parece viable para otras cosas...

enfoqueNativo commented 7 years ago

Es cierto, en parte esto paso por tratar de hacer las cosas lo mas transparentes posibles para el programador y el usuario, deberíamos haber sido mas jodidos +:100:.