1

> En app_engine.php, al cargar el plugin securitylayer se sanean por defecto los datos de POST.

Su afirmación es incorrecta.
SecurityLayer solo se activa si la directiva SECURITY_LAYER_ENGINE se establece en On (case sensitive).
Cualquier otro valor, produce que SecurityLayer no sea activado.

> En userController, el metodo guardar llama a __validar_pwd que entre otras cosas verifica que la longitud de la contraseña no sea menor a 6, sin embargo, como los datos de POST ya fueron saneados y hasheados esta verificacion siempre pasa, permitiendo escribir contraseñas de menos de 6 caracteres.

Nuevamente, usted hace una afirmación incorrecta.
Suponiendo que SECURITY_LAYER_ENGINE se haya establecido en On, la directiva SECURITY_LAYER_ENCRYPT_PASSWORD debe ser establecida en True para que SecurityLayer aplique el algoritmo de encriptación especificado en la directiva SECURITY_LAYER_ENCRYPT_PASSWORD_HASH.

Cuando SECURITY_LAYER_ENCRYPT_PASSWORD se establece en True, a los campos de contraseña cuyos nombres coincidan con alguno de los contemplados por SecurityLayer, no se les aplica ningún filtro de saneamiento.

> No si si lo que propongo sea una solucion y si lo es no se que tan buena sea. ¿Podria modificarse el plugin para que guarde en POST el pass saneado y deje intacto el pass original?

EuropioEngine es Software Libre. Esto significa que usted tiene (entre otras libertadas concedidas por la versión 3 de la licencia GPL), la libertad de estudiar el código fuente y efectuar las modificaciones que considere necesarias.

> Gracias por cualquier ayuda o aclaracion :)

Tenga en cuenta que el módulo de Usuarios por defecto que acompaña a EuropioEngine, codifica el campo de contraseña mediante EuropioCode, generando que las contraseñas se envíen en texto plano alfanumérico, para evitar así, las inyecciones de código y/o la ejecución de código malicioso.

Por otra parte, como principio básico de la seguridad informática, las contraseñas solo deben ser validadas contra una política de contraseña, pero no deben ser "saneadas" como cadenas de texto, puesto que restan seguridad a la misma.

Gracias por las respuestas, pero aun me quedan dudas.

Gracias por la aclaracion con respecto a las constantes usadas en security layer, la verdad ya lo habia revisado y me habia dado cuenta. No me di cuenta de que a los campos de contraseña que coinciden con los contemplados en europio no se les aplica saneamieno.

Mi problema es el siguiente:

Entiendo que al modificar el valor de las constantes evito que se aplique el hash al pass. Por defecto en config.ini los valores de estas constantes permiten que se aplique md5 y esto no permite realizar la comprobacion de la longitud de la contraseña, y ese es mi punto, es el "problemilla" con el que me tope, lo veo como un problema en la logica de la aplicacion por que al activar security layer y setear a true la encriptacion del pass se hace "imposible" (ya se que no es imposible) verificar la longitud.

Entiendo que puedo modificar el codigo si lo necesito y es lo que hare con la mejor logica que encuentre, lo que necesito es un consejo que me ayude a hacerlo mejor.

> Entiendo que al modificar el valor de las constantes evito que se
aplique el hash al pass. Por defecto en config.ini los valores de estas
constantes permiten que se aplique md5 y esto no permite realizar la
comprobacion de la longitud de la contraseña, y ese es mi punto, es el
"problemilla" con el que me tope, lo veo como un problema en la logica
de la aplicacion por que al activar security layer y setear a true la
encriptacion del pass se hace "imposible" (ya se que no es imposible)
verificar la longitud.

Aprovechando que no existe un archivo de configuración por defecto, usted simplemente podría establecer en False el valor de la directiva SECURITY_LAYER_ENCRYPT_PASSWORD y obtener una contraseña en texto plano, dado que el problema que usted plantea no es de "lógica", sino de requerimientos. Tenga en cuenta, además, que el módulo de usuarios no forma parte del núcleo. Solo acompaña al código a fin de servir como guía a usuarios sin experiencia en desarrollos modulares basados en núcleos.

> Entiendo que puedo modificar el codigo si lo necesito y es lo que hare
con la mejor logica que encuentre, lo que necesito es un consejo que me
ayude a hacerlo mejor.

Supongo que está empleando el término de lógica para referirse al flujo de la información del requerimiento específico. En ese caso, usted debe plantearse qué es lo que desea hacer y resolverlo como habitualmente lo haría sin dejar que EuropioEngine interfiera en su análisis. El objetivo de la aplicaciones basadas en núcleo, justamente, es que el núcleo no interfiera en los requerimientos del programador.

- Si siente que SecurityLayer interfiere en su trabajo, desactívelo ya que no forma parte del núcleo y es un complemento opcional.

- Si siente que el problema es obtener una contraseña cifrada pero prefiere mantener activo SecurityLayer, establezca en False la directiva SECURITY_LAYER_ENCRYPT_PASSWORD.

- Si desea mantener SECURITY_LAYER_ENCRYPT_PASSWORD en True para conservar el intacto el módulo de usuarios incluido a modo de ejemplo, en sus propios desarrollos, evite nombrar a sus campos de tipo password con nombres que contengan alguna de las siguientes cadenas: 'pass', 'clave', 'contrasenia', 'pwd'. Puede utilizar nombres alternativos como 'contrasenya'.

- Si cree que el problema es que el módulo de usuarios no satisface sus requerimientos, desarrolle uno nuevo empleando sus propio flujo de datos y no olvide quitar el actual para que no interfiera con su trabajo. Si esta fuese su alternativa, por favor, considere en su desarrollo, los 3 puntos anteriores.

Muchas gracias por las respuestas Eugenia, llevo poco tiempo estudiando el codigo de europio y poco a poco aprendo un poco mas, hay una especie de brecha entre saber lenguajes de programacion y ser capaz de programar un sistema con una logica interna consistente y bella, leyendo tu codigo se encuentra una buena guia para desarrollar esas habilidades.