yo usaria un one time password guardado en local, cifrado con la Public K del usuario (?)
#30 Bcrypt evita eso, pero también evita que puedas comprobar los telefonos guardados, al menos de manera comoda, que yo sepa.
El problema no es tanto validar el telefono y luego guardarlo para que nadie lo conozca. Hasta ahí hay infinitas posibilidades y todas buenas. El problema es reutlizar dichos telefonos cifrados para evitar que haya duplicados.
#31 si cifras y descifras con las claves público/privada del usuario, nunca va a poder hacer mv la comprobación de si el teléfono ya existe.
Es un tema interesante, la verdad.
El tema de la búsqueda después es un tema más complejo puesto que no se puede buscar como tal en campos con hash que se generan de manera aleatoria.
Nunca lo he implementado, pero hay un método llamado "blind index" que consiste en tener un campo en la db también encriptado, pero con un algoritmo que siempre de el mismo resultado (aquí tb tendriamos que tener en cuenta el tema de los salts y que se tarde en generarlo aunque siempre de lo mismo).
Digamos que por ejemplo tengo yo el numero 600123456:
Hash con bcrypt de coste 6:
$2a$06$zWTD4Vd0RG.Dc17cTUGEuewepqvR76ZomP9/Hm74G01bQ238Gbhpm
Su MD5 (por elegir uno, pero habría q buscar uno dificil y usar un salt, pero para el ejemplo vale):
5f095bd18e0729ceaa0e5fbd6c6b86ac
En este caso, en el "registro" de los usuarios, la búsqueda la haríamos usando el segundo campo (el del md5) y no el primero.
Esta "solución" sirve para tener campos encriptados en la ddbb sobre los que poder hacer búsquedas, pero si te entran hasta la cocina y tienen tu código, podrían sacarlo relativamente facil, por lo que solo te vale de "protección" en el caso de que solo te roben la ddbb xD
EDIT:
El campo para el blind index nunca sería el propio valor como tal, pero si debería de ser un proceso que siempre de el mismo valor, por ejemplo, en el caso del teléfono podríamos partir el teléfono en 3 partes (600, 123, 456), sacar el base64 de cada una, juntar las partes, ese ultimo valor pasarlo a sha256 por ejemplo y ese ultimo valor es el que se guardaría en la ddbb. Como he dicho, si solo te roban la ddbb, no lo sacan, si entran hasta la cocina, pues es cuestion de replicar el proceso e ir probando códigos xD
https://theobjective.com/espana/2024-04-15/ciberataque-expuestos-datos-personales-guardia-civil/
Un ciberataque deja expuestos los datos personales de toda la Guardia Civil y el Ejército
El ataque cibernético ha afectado a una empresa de reconocimientos médicos subcontratada por Interior y Defensa
y vosotros preocupados porque se filtren algunos hashes de números de teléfono aleatorios de usuarios 
#36 xddd
El tema va más para poder justificar el requisito de pedir el telefono, y poder demostrar que no "pasa nada" en temas de seguridad y privacidad.
https://www.smsonline.cloud/es
No lo he probado... pero imagino que como ese habrá decenas... y si no, de pago. A un troll no se le frena con bloqueos, es una lucha continua y activa. Poner trabas de este tipo solo perjudica a la gente "mas o menos normal" xD.
ke os flipais mucho los frikis ai con vuestros hash pero luego os meto un navajazo y no hay encriptado que os salve hahhahah
Si en algún punto se tiene que hacer [Token] -> [Telefono] y se tiene acceso a '->' ... no se me ocurre nada posible para prevenir saber [Telefono]... es la idea de que exista '->'.
Lo 'mejor' que se podría hacer es mover '->' a algo que lo maneje una entidad neutral que asegure que todo va de lujo certificada con 20 estándares distintos.
#17 Si el problema es exclusivamente la autentificación, y no el logueo de contraseñas via 2factor desde el teléfono, no hay que almacenar nada.
Tan solo enviarse el código de registro al teléfono que pida el user, y después añadir ese número de teléfono a un listado de teléfonos empleados, sin que haya posibilidad de reutilizar un número de teléfono. De esa forma no se asociaría user <-> tfno y no habría que guardar nada.
#43 no es para autenticar, si no para crear una nueva cuenta. se quiere encontrar un metodo que impida a un trol crearse 50 cuentas
De esa forma no se asociaría user <-> tfno y no habría que guardar nada.
Esto es a lo que más vueltas le he dado. Que sencillamente el telefono no se asocie al usuario.
Sería tan fácil como:
- Usuario pone el numero
- Se genera X código y se añade al usuario
- Si dicho usuario pone el código, guardo el teléfono en el listado de turno
Algo más de privacidad da, eso seguro. Lo que no me gusta es el paso 2-3...ya que "técnicamente" sería bastante fácil perder la unión código-telefono-usuario para la validación.
Eso y en el caso de que alguien se cambie el teléfono. Se que en teoría las compañías no reutilizan los teléfonos, pero no se cuanto fiarme de eso.
#44 Si el teléfono solo lo necesitas para el registro no necesitas almacenar ninguna información que relaciones el usuario con el teléfono.
Que el código recibido en el tfno se compruebe con el esperado y si coincide se da el OK al registro y se almacena exclusivamente el número de teléfono para no poder volver a recibir otro registro.
AikonCWD pide registro con el numero 666111222, codigo de registro C46Fv&gds%/d. AikonCWD mete el codigo al registrarse y tirando.
Mediavida almacena 666111222 como numero utilizado
AikonCWD es baneado
AikonCWD2.0 pide registro con el numero 666111222. Mediavida devuelve que el numero de tfno no es válido, pero sin saber quien lo utilizó en su momento.
¿Esto no es viable?
#46 El problema que le veo es con número reutilizados (parecido al problema de bloquear por IP)... pero bueno, igual es un problema a largo plazo.
Una PoC muy simple:
import hashlib
import os
hashes_and_salts = []
def hash_private_key(private_key):
salt = os.urandom(16)
hash_obj = hashlib.pbkdf2_hmac('sha256', private_key.encode(), salt, 100000)
return hash_obj, salt
def process_private_key(private_key):
new_hash, new_salt = hash_private_key(private_key)
collision_detected = False
for old_salt, old_hash in hashes_and_salts:
regenerated_hash = hashlib.pbkdf2_hmac('sha256', private_key.encode(), old_salt, 100000)
if regenerated_hash == old_hash:
collision_detected = True
print("Collision detected with previously used private key.")
break
if not collision_detected:
hashes_and_salts.append((new_salt, new_hash))
print("No collision detected: New hash and salt stored.")
print(f"Generated Hash: {new_hash.hex()}, Salt: {new_salt.hex()}")
process_private_key('phone1')
process_private_key('phone1')
process_private_key('phone2')
Output:
Generated Hash: f3c2793b7aef9e94fcba7b32ccccf4d21087837e47d1e3a8820c39076e4e6fcf, Salt: 5bde7dd3d6bc4f4836e2d20106958276
No collision detected: New hash and salt stored.
Generated Hash: 91d6c9dc7ae73ca5740758e0f591079618a465634ea45e726473d98bb6b70761, Salt: f28076a8c7bca40ab2a82da4f76f42ef
Collision detected with previously used private key.
Generated Hash: 91746c89c505f4839797559a6a1824ff00f8b97d61852fa196c7414fab193679, Salt: df11d03a66bce4ddf21aa75831143b9c
No collision detected: New hash and salt stored.
edit: habria que hacer las private_key inteligentes, no solo un número, y usar argon2 claro. aqui es donde me suena que el standard es usar un doble salt. fijaros que podriamos encriptar nuestro hash del servicio de la misma manera con otro salt, y de esta manera poder cambiar los hashes si nunca se leakea o tener rotaciones de seguridad.
Hay webs que te dejan usar un número virtual gratuitamente para usar donde quieras (lo he visto para gente que usa más de un perfil de Tinder) y recibir SMS de confirmación etc… erradicar las multicuentas lo veo algo muy positivo, pero quizás esta forma es “fácil” de hacer el bypass con las webs estas cuneras.
#45 Los números de teléfono si se reutilizan, no se lo que tardan en volverlos a dar una vez los dan de baja, pero usarse se utilizan xD
Por cierto, deberían de estar asociados al usuario, ya que si decide darse de baja voluntariamente, su información (entre la que se incluye el teléfono) debería de borrarse tambien.
#50 Si no he entendido mal tu código, para comprobar si ya se ha utilizado antes, generas un HASH pasando por todos los SALTs que ya tienes almacenados.
Es decir, que si hubieras guardado previamente 30mil teléfonos, para agregar uno nuevo tendrías que generar 30mil hash para comprobar que no se ha guardado previamente, lo cual, dependiendo del tiempo de generación de cada uno de los hash, sería inviable.
#52 tan solo demuestro la lógica para no tener que guardar los numeros, hay maneras de hacer la búsqueda eficiente usando hashes más avanzados, prefijos o un bloom filter en memoria por encima.
En el caso más fácil, podrías poner prefijos al hash, y haciendo un binary search sobre 30k hash te salen 15 iteraciones.
| N | Max Iterations |
|---|---|
| 100 | 7 |
| 1000 | 10 |
| 10000 | 14 |
| 100000 | 17 |
| 1000000 | 20 |
| 10000000 | 24 |
leakearias un poco de información que un número de teléfono tenga un hash mas bajo según su valor pero bueno... nada muy preocupante creo.
podrias tener:
00001+hash_1
00002+hash_2
00006+hash_3
00008+hash_4
00009+hash_5
Y si buscas algo que está entre 00001 y 00006, solo necesitas hacer 2 comprobaciones. Habría que ver el código perfecto de como resolverlo, dejo como trabajo al lector resolver este ejercicio.
A ver, habria que ver como no leaker informacion para que si te roban todo no te hagan un rainbow attack... pero si alguien roba la DB de mv y sabe hacer eso jajaj que robe los numeros de telefono que mas da? jajaj necesitarias la DB, los secretos usados... que pueden ser doble padding... en fin.
Por cierto, deberían de estar asociados al usuario, ya que si decide darse de baja voluntariamente, su información (entre la que se incluye el teléfono) debería de borrarse tambien.
Joder sabia que lo había descartado por algo
Total, me cojo cualquier teléfono de páginas random que las tienes a puñados y marchando...
Yo siempre hago lo mismo, me fijo en como lo tienen las multinacionales y si es una chapuza miro otra, lo que no entiendo es porque no se hace el registro por recomendados y san se acabó...
#53 En el caso de que te quiten hasta el código, daría un poco igual, pero si es solo la db, no valoras lo del "blind index"?
No manejo mucho de python, pero según internet quedaría un código más o menos así con los comentarios que he hecho anteriormente (el tema del coste es para que la generación tarde más y poder evitar los casos de fuerza bruta, algo así como bcrypt pero a lo cutre)
import base64
import hashlib
def generateBlindIndex(string, cost):
value = string
for i in range(cost * 100000):
parts = [value[j:j+3] for j in range(0, len(value), 3)]
encodedParts = [base64.b64encode(part.encode()).decode() for part in parts]
key = ''.join(encodedParts)
value = hashlib.sha256(key.encode()).hexdigest()
return value
# Ejemplo de uso
string = "example_string"
cost = 1
blind_index = generateBlindIndex(string, cost)
print(blind_index)
PD: En mi local funciona (mi local es una página warra de internet que compila python online xD)
PD2: el "code" de mediavida no indenta donde debe:
#56 Un blind index para buscar en la key es peor que tener un algoritmo que ordene las llaves por su contenido y acceder.
Tener el blind index y poder buscar es perder la propiedad de que dos hashes sean distintos.
Si vas a tener un blind index, mejor no tener nada, y tan solo guardar usando Argon2 el número y buscar el hash directamente.
Un algoritmo de hashing que ordene para este caso, no revelara información para ningún ataque. Lo que revelara potencialmente información es la manera en que lo haces.
Si tienes "666 123 456" puedes usar el prefijo "666" o puedes usar "666 123" o puedes convertir los números a texto para incrementar los bits de información. "seis seis seis uno dos tres".
Pero vamos, hacer el hash y 10 comprobaciones tampoco es el fin del mundo... lo puedes hacer en paralelo todo asíncrono y tardarás 400ms de cpu por hash? 4 segundos en comprobar el teléfono?
Algo que el usuario va a hacer 1 vez en su vida tardar 4 segundos, con 30 mil teléfonos, es decir 30 mil nuevos registros premium... jajaja
Os estáis comiendo la cabeza mucho.
#40 y le robas la cartera con el DNI, hasheadme esta.
Authenticator propietario de MV enlazado a los dispositivos físicos y listo
