search

Las-Fuerzas-Del-Cielo / Sistema-Anti-Fraude-Electoral

Sistema Open Source para Identificar potenciales fraudes electorales, minimizar su ocurrencia e impacto.
MIT License
1.01k stars 125 forks source link

Cambiar encriptación MD5 por otra más segura para contraseñas #56

Open fx-biocoder opened 1 year ago

fx-biocoder commented 1 year ago

Linea 24 de fiscales_db.sql:

...
`password` varchar(64) NOT NULL COMMENT 'MD5',
...

Dado que se descubrió que el algoritmo criptográfico MD5 posee vulnerabilidades (ver post de StackExchange), recomiendo que las claves se creen usando un algoritmo distinto. En ese enlace verán algunas alternativas.

dbareiro commented 1 year ago

Claro. Por el tema de las colisiones con el hash MD5. Blowfish puede ser una mejor opción, creo. De todas maneras, podría ser interesante incorporar 2FA.

juanFernigrini commented 1 year ago

Pero si eso se lo dejamos al back podemos almacenarlas directamente haseadas en Json Web Token. y trabajamos con Bearer tokens

Kazte commented 1 year ago

Bycrypt podría ser una opcion y usar JWT?

pardo-bsso commented 1 year ago

Voy a hacer un comentario de lurker greybeard.

Todo ese tipo de cosas ya están resueltas, testeadas y probadas en la vida real por gente con mucha más experiencia que casi cualquiera de nosotros.

No hay mucho tiempo para estar reinventando esto.

A pesar de que no es algo que me super guste Laravel resuelve esto y un montón de otras cosas de una.

KonixDev commented 1 year ago

Es un post de hace 11 años. Se debe chequear si la misma vulnerabilidad a dia de hoy existe. Creo que el mejor algoritmo es hacer hashing ya que no es posible revertirlo al string original.

pardo-bsso commented 1 year ago

(estoy asumiendo que vieron el revuelo, hate y bajada a la realidad que el proyecto dio para charlar en un par de antros)

Hay menos de dos semanas para tener esto funcionando, en paralelo con instruir fiscales. Enfocarse en esto no ayuda. El post es de hace 11 años y esa falencia de MD5 sigue.

El punto que quiero recalcar es que desde auth compatible con cualquier proveedor que se te ocurra, orms y generación de admins/backoffice prácticamente sin codear y enchufando una cosa con otra ya están listas.

Acá dejo un par de canas pero una vez pensado un poco el tema de como estructurar los datos todo esto con Django sale en un finde. (sé que estoy siendo sesgado pero django es mi go-to para armar mvps sin importar en qué se vayan a implementar luego)

De yapa miren esto: https://viewflow.io/ La usé para más de un laburo y vale la pena el esfuerzo inicial para aprender. Pagar la versión pro también, pero es un tema aparte.

pardo-bsso commented 1 year ago

Me respondo a mi mismo,

no perder de vista el bosque por un árbol y todo eso.

pardo-bsso commented 1 year ago

Por otro lado, es alentador ver que alguien hace reviews :)

fx-biocoder commented 1 year ago

Sería óptimo que tengamos una forma de hablar directamente con los que están llevando adelante esto

jgutiez commented 1 year ago

Como lo dijo alguien más arriba, y teniendo en cuenta el poco tiempo que se cuenta para el desarrollo de la aplicación, sería conveniente utilizar un servicio de autorización/autenticación ya existente; y de esta forma concentrar el esfuerzo en la implementación CORE del sistema. Una opción confiable, ampliamente probada y de fácil integración es Auth0. Los gastos podrían ser cubiertos a través de donaciones.

Gunslito commented 1 year ago

Keycloak como idP te podría salvar de ese lado, no tenes que reinventar nada. Gratuito y anda de diez.

Se puede configurar para que las passwords no vayan en plano y es bastante seguro.

Malows commented 1 year ago

Es un post de hace 11 años. Se debe chequear si la misma vulnerabilidad a dia de hoy existe. Creo que el mejor algoritmo es hacer hashing ya que no es posible revertirlo al string original.

@KonixDev el problema de MD5 es que se podía, a través de fuerza bruta, adivinar la contraseña que generaba ese hash. Con hardware de hace 11 años.

Hoy en día, alquilas un par de instancias con GPUs en AWS y lo rompes al toque.

Dejo dos recomendaciones, no usen algoritmos de la base de datos, usen algo que puedan controlar, porque sino quedan atados a esa db y esa versión. Y no junten la password y el user. Si lo hacen por separado tienen la flexibilidad de poder cambiar el algoritmo sin afectar al usuario que ya tienen

mastepanoski commented 1 year ago

Hola, acá les dejo algunas recomendaciones y recursos para tener en cuenta para la seguridad de NextJS con NestJS:

  1. Encriptación de contraseñas: Para encriptar las contraseñas en la base de datos para el inicio de sesión. NestJS proporciona una guía completa sobre cómo implementar la encriptación y el hashing. También pueden optar por usar una herramienta como Keycloak para que gestione los usuarios y contraseñas, además del acceso, que ya sigue muchas buenas prácticas de seguridad, además de que ofrece facilidad de integración con NodeJS. También pueden usarlo para autorizar accesos a endpoints. También Cerbos es una opción a considerar.

  2. Control de sesión con NextAuth: NextAuth es una opción para el control de acceso de aplicaciones de NextJS, sobre todo si en el equipo no cuentan con un experto en seguridad informática, ofrece un buen punto de incio. Un tutorial sobre cómo implementar la autenticación en una aplicación Next.js con NextAuth aquí.

  3. Protección contra CORS y CSRF: Es importante proteger la aplicación contra ataques de Cross-Origin Resource Sharing (CORS) y Cross-Site Request Forgery (CSRF).

  4. Autenticación OAuth: La autenticación OAuth con una expiración de segundos para los tokens es una buena práctica para asegurar las APIs. Un tutorial sobre cómo implementar la autenticación OAuth2.0 en NestJS .

  5. Uso de Server Actions en Next.js: Las Server Actions en Next.js permiten ejecutar código del servidor sin tener que crear un endpoint para las APIs. Esto puede ayudar acelerar el desarrollo y poner acceso a los endpoints del microservicio directamente en las server actions, validando allí si un usuario ha iniciado sesión y está autorizado para realizar una acción antes de hacer una llamada remota al microservicio.

  6. Seguridad del microservicio: Si el microservicio está dentro del mismo servidor, es recomendable que solo pueda ser llamado desde el mismo servidor en el que está la app de NextJS, cerrando los puertos para evitar su exposición externa. En caso de que se despliegue en otro servidor, se recomienda hacerlo a través de una VPN o LAN para evitar que el microservicio pueda ser accedido desde el exterior. Más información aquí.

Espero que estas recomendaciones sean útiles.