Seguridad en encriptado de datos en la DDBB

MisKo

Pues para quien no lo haya leído, básicamente se hablaba en el foro de mediavida de pedir el teléfono a los usuarios y se han hecho comentarios sobre la seguridad de guardar esos datos en la base de datos ante posibles leaks, forzar hashes con ataque de fuerza bruta y cosas asi.

Para no repetir todo lo de allí, básicamente empieza en https://www.mediavida.com/foro/mediavida/make-mv-great-again-709093/76#2242 y llega hasta 2324.

Así que nada, básicamente es llevar lo que estamos hablando allí a un hilo propio para no saturar ese. Cualquier comentario es bienvenido =)

1
AikonCWD

Retomando el tema y partiendo de la base en que queremos como objetivo almacenar en una BD una relación de usuario <> telefono. Mi propuesta es la siguiente:

  • Usar sal a la hora de cifrar el telefono para romper la estructura de 9 caracteres y solo numeros. No almacenar la sal junto al hash como se suele hacer, para dificultar más el crakeo.
  • Cifrar dicho texto y usar un sistema de derivación de clave, con un porrón immenso de iteraciones. (PBKDF2 o Argon)

Al no tratarse del password, nos da igual que el coste de computo sea elevado, ya que solo se calculará una vez por registro de usuario nuevo. Haciendo que la tarea de fuerza bruta por parte de un hacker sea inviable.

1 1 respuesta
MisKo

Para completar el hilo, pongo el funcionamiento de bcrypt:

En inglés (original)
En castellano (chatgpt)

Fuente: https://nordvpn.com/es/blog/what-is-bcrypt/

1
Runig666

#2

Cifrar dicho texto y usar un sistema de derivación de clave, con un porrón immenso de iteraciones

Esto es lo unico util. Como ha dicho antes MisKo. Puedes cascarle BCrypt y ponerle el computo de trabajo alto de cojones

...otra cosa es que te sigue sirviendo de poco cuando cada vez las graficas hacen hash de manera más rapida y la cantidad de hashes que tienes disponibles es un numero bastante pequeñito

1 1 respuesta
MisKo

#4 El "cost factor" de bcrypt está pensado justo para eso, conforme el hardware evoluciona, se aumenta el cost factor para seguir aumentando el tiempo de generación de hashes e impedir la fuerza bruta

1 1 respuesta
AikonCWD

Sí, el coste de computo no deja de ser una función de derivación de clave.

No veo que otra cosa más se puede hacer. Quizás la solución sea no almacenar el telf y buscar una alternativa a la generación de cuentas secundarias/clon, respetando GDPR y el derecho al olvido.

Runig666

#5 Claro pero a día de hoy, pongamos que lo subimos a 10, creo que es lo que has dicho antes, y se tarda 11 segundos...que ya 11 segundos de registro es digno pero bueno, aceptemos el pulpo.

A día de hoy, un ordenador estandar tarda 11 segundos, pero es que me juego una cena a que una 4090 puesta para eso va a más de 10 por segundo. Y sabiendo que la pool de combinaciones es pirrica, cuanto vamos a tardar en generar todos los telefonos posibles?

Aquí el problema no es tanto el sistema del hash, si no la pool de opciones. Una encartación funciona cuando el pool es tan gigante que no sale rentable "generarlo de antes". Pero es que en este caso podriamos ahorar generar la lista de todos los numeros que sean 6XXXXXXXX y tienes ya el 90% del trabajo hecho...que ya me sorprende que a nadie se le haya ocurrido hacerlo

1 respuesta
desu

¿Para qué queréis el móvil?

2 respuestas
Kaledros

¿Es imprescindible almacenar el teléfono?

2 respuestas
MisKo

#7 El cost actual creo que está en 12 o algo así, cuando salio estaba en 6 si no me equivoco y va cambiando dependiendo de lo del hardware como te decía.

Sobre lo de la generación previa, como he comentado en el otro hilo, no entiendo a fondo la encriptación, pero juraría que sin tener el salt (que se genera al azar al crear el hash) la tabla de hashes que generes no te vale.

Es decir, si partimos del ejemplo que puse en el otro hilo, el mismo código que antes me ha dado este hash
"$2y$18$vPyjJU0V5OiDf025Ip4fC.X4Oit/YNKga1Jgzb4fEGfM7ExKHh9Bq"

ahora me ha dado este
"$2y$18$IUIf/6DICm/8.zhO7gfc1eM0heaqiQrN1W6kqDQFAYzVbiAYf34cC"

El funcionamiento de "verificación" no es comparar un hash con otro, si no generar un hash nuevo con el mismo salt y el string que hayas indicado y comprobar que coincide con el que tienes en la ddbb, de ahí que no puedas crear un diccionario de hashes para el bruteforce.

#8 #9 eso es un supuesto que ha salido en el hilo de mv xD

2 respuestas
PaCoX

podeis usar el World ID de WLD para autenticar humanos unicos xD

desu

#10 Para registro no se necesita nunca guardar el número.

Y si es para cosas de policía y seguridad con un Oauth puedes mover el puro a Google o un servicio que sí tenga el número.

1 respuesta
MisKo

#12 Eso una cosa que han puesto en el hilo de mediavida (en concreto aqui: https://www.mediavida.com/foro/mediavida/make-mv-great-again-709093/75#2242 ) donde lo han sugerido, la idea de traer este tema a desarrollo es por el tema de la encriptación de datos, no de la propia funcionalidad xD

Runig666

#8 Eso ya va por otro lado...porque algunos lucidos si no pueden tener una forma de denunciar a alguien del foro no son felices.
#9 No, y es una idea pésima que solo algunos garrulos ven util, esto ya va de hablar de manera tecnica.

#10 Se me había olvidado que estabamos hablando de Bcrypt y la sal me la he comido. He hecho una unión rara y he empezado hablando de decrypt y luego y vuelto a sha256

2 respuestas
Kaledros

Yo es que la premisa ya me parece insensata sólo desde el punto de vista legal.

MisKo

#14 La idea puede ser util o no, pero insultar a la gente que tiene una opinión u otra es innecesario.

1 1 respuesta
AikonCWD

La premisa no va por el tema de denuncias ni nada, Si no para evitar multicuentas, clones y trolls.

También podemos debatir otro sistema para evitar eso. Se ha propuesto de momento usar el num de teléfono para registros nuevos.

Y de ahí, la necesidad de almacenar esa info de forma segura.

3 respuestas
PiradoIV

Primero habría que ver si realmente es necesario. Si se puede buscar una alternativa (moderación, ignorar usuarios, etc) sin tener que guardar este tipo de datos personales, pues mejor.

Para mí, el valor que aporta es bastante flojo, comparado con otras muchas cosas en las que emplear el tiempo de desarrollo.

Dr_Manhattan

Si el teléfono es obligatorio me cerraría la cuenta, lo bueno de un foro es que sea "más o menos anónimo" si ya hay que identificarse pues next.

PD: imagina tener en cuenta la opinión de Runhigo777, no se cansa el colega de hacer el ridículo

1 respuesta
Kaledros

#17 Creo que esto es un problema XY: si lo que se quiere es evitar los trolls no hay por qué usar el teléfono para registrarse, basta con tener una buena moderación. Si eso no se puede conseguir (y creo que es algo que ni siquiera está definido, cada user tiene una opinión sobre lo que es una buena moderación) entonces empezamos a ver otras opciones. Pero registrarse con el teléfono es una locura.

PiradoIV

Para evitar multicuentas y clones ya hay herramientas en MV. Los usuarios o los moderadores reportan cuentas a los admins y los admins verifican y banean a mano.

desu
#14Runig666:

porque algunos lucidos si no pueden tener una forma de denunciar a alguien del foro no son felices.

lo bueno de tener Oauth es que puedes hacer que sea obligatorio para tener X funcionalidades y ahi poder denunciar.

es una manera de no tener que gestionar nada y tener toda la proteccion legal.

1
Runig666

#17 Si...bueno...esa es la teoria y como te lo venden. Ya te digo yo que alguno es más por las denuncias, porque varios que dicen lo del movil, estaban encantados de forzar el DNI

#19 Mucho mejor tener en cuenta la tuya, donde va a parar. Tu siéntate y escucha.

1 respuesta
AikonCWD

#23 lol

1 respuesta
Runig666

#24 Porque esta en Flames, pero cuando sacamos el otro foro en el famoso hilo de "En 2 semanas os cuento" ya salió lo del móvil y luego se tiro al DNI. Casualmente los mismos.

Y al final a base de calentar al personal era para denunciar a casco porro

Que la idea la hemos tenido todos alguna vez, pero la privacidad con validación de móvil no se lleva bien.

eXtreM3

Este hilo NO es para debatir si es bueno o malo pedir el teléfono. Estamos aquí por la pura duda técnica de como anonimizarlo mejor y evitar hackeos.

Runig666

#16 Es completamente necesario, porque algunos no se dan ni cuenta de la burrada que estan pidiendo. Estan pidiendo que un telefono sea algo super privado...pero a su vez mandarle un SMS por X servicio que en cualquier caso si o si va a dejar registro. Algunos de por aquí estamos haciendolo más por diversión que como algo a implementar...pero ya te digo yo que a más de alguno le parece una idea cojonuda y sin problemas.
---
Lo que me he dado cuenta, al depurar con el patito de goma, es que si lo cifro en BCrypt CREO y solo CREO que no puedo hacer una comprobación de si "ya existe" facil. Me explico:

Si lo hago en MD5, (No es ni encriptación, es un ejemplo), y tengo el telefono 655165165, el resultado que me va a dar siempre es b6cacee032cce15c9b58ebae19ddf75b. Entoces si me llega otra vez 655165165 la forma de saber si tengo ese telefono en BD es pasar ese telefono a MD5 y buscarlo entre los guardados. Hasta aquí tiene sentido. Una misma cadena siempre va a dar lo mismo, así que hacer una consulta where es facil.

Pero es que en BCrypt no puedo hacer eso. Si yo cojo el mismo numero ahora mismo Bcrypt me va a dar esto $2a$12$tK7HDn5GhjO5Bauxt7KNaOuNeskglYj/E/fozqIF1WppC2iNMFbR...pero es que dentro de 5 segundos me va a dar esto $2a$12$bgAfVdasfaeW5l.MoT2JKO8Vwldlh3AQr8kJypkUIvFonRwZtyf6.

Entonces la única forma que tengo de saber si un teléfono ya esta en BD sería ir fila a fila preguntándole al Bcrypt de turno si el telefono cifrado equivale al teléfono que me han dado. Lo cual a más grande sea la base de datos de más tardara, sabiendo que encima tienes que darle bastante "poder" para que sea difícil de descifrar a lo bruto, la tarea se transforma bastante titánica

Para las contraseñas es cojonudo, porque solo tienes que mirar una fila, nada más, aquella que equivalga al email/nombre de usuario. Y si alguien repite contraseña te la sopla...pero tu no podrias saber que alguien ha repetido la contraseña, porque como bien has dicho antes, un mismo texto va a dar infinitos resultados

1
desu

No necesitáis guardar el teléfono para comprobar que es el mismo.

Puedes usar el teléfono como llave privada y generar hashes, y después verificar la firma.

hash(666 666 666) = abc
hash(666 666 666) = def
pub(666 666 666) = 123
verificar(abc, 123) = true
verificar(def, 123) = true
verificar(xyz, 123) = false

para guardar en DB me suena de un doble salting y algoritmos de hash que tienen estas propiedades. podeis buscar como lo hace alguna FAANG que seguro que tienen algun blog.

porque de hecho, me acuerdo de cuando se guarda user/password, no se guarda la password hasheada. sino un atributo para después poder verificarlo. asi evitan ataques en DB y que se haga leak de la DB.

yo es que no estoy familiarizado con guardar, conozco casos como el que comento en que no guardas nada pero validas todo, como tokens por ejemplo.

1 respuesta
Runig666

#28 El problema es que 2 de ahí deberían de dar false

hash(666 666 666) = abc
hash(666 666 666) = def
verificar(abc, 123) = true
verificar(def, 123) = true

El segundo debería de petar puesto que es un telefono que ya ha sido verificado. Entonces si o si tienes que tener una manera de saber que teléfonos han sido validados.

eXtreM3

El problema que se plantea aquí es que te han hackeado toda la infraestructura, servidores, código, red, cloud storage... Entonces siempre siempre siempre se va a tener acceso a cómo se generó y hacerlo de nuevo.

1 1 respuesta