Seguridad en encriptado de datos en la DDBB

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.

#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

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

#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

#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.

#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

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

#23 lol

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.

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.