Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fx-biocoder opened this issue Oct 28, 2023 · 13 comments
Open

Comments

@fx-biocoder
Copy link

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
Copy link

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
Copy link

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

@Kazte
Copy link

Kazte commented Oct 28, 2023

Bycrypt podría ser una opcion y usar JWT?

@pardo-bsso
Copy link

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
Copy link

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
Copy link

(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
Copy link

Me respondo a mi mismo,

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

@pardo-bsso
Copy link

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

@fx-biocoder
Copy link
Author

fx-biocoder commented Oct 28, 2023

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

@jgutiez
Copy link

jgutiez commented Oct 29, 2023

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
Copy link

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
Copy link

Malows commented Oct 29, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants