Primero, debo dar un golpe obligatorio:
Conoce tu modelo de amenaza. Es posible que no pueda proteger su sistema a menos que tenga un modelo de amenaza que describa las amenazas que está evitando. Un script que le explora a usted es muy diferente al gobierno de EE. UU., Que también es muy diferente a un gobierno. tratando de obtener sus datos. Sin un modelo de amenaza, los algoritmos seguros son casi inútiles.
Respaldo la sugerencia de Lawri de usar SSL. Disminuye drásticamente cuánto tienes que pensar cuando demuestras que puedes defenderte de tu modelo de amenaza. También proporciona el cifrado que necesita para el siguiente paso.
Sin embargo, asumiré que por algún motivo no se puede acceder a SSH. Tal vez es una cosa de rendimiento.
¿Qué contiene tu modelo de amenaza? Aquí está mi conjetura
- Definición de dos partes: el interrogador que inicia el patrón de consulta / respuesta y el respondedor que responde.
- Ataques de reproducción: tanto un snooper como la transmisión y un nodo seguro que simula que aún tiene el identificador de lado al conservar el código hash para ese identificador.
- Ataques de fuerza bruta: al no observar ninguna información útil, el atacante envía solicitudes a ciegas
- Servicio de respuesta malintencionado: si le pide información a alguien, puede revelar que probablemente la tenga.
- Ataques en la red subyacente: considere xauth, que tiene un ataque problemático conocido donde un atacante crea paquetes TCP fraudulentos para falsificar la autenticación.
- Los atacantes no tienen acceso físico a las máquinas, ni pueden obtener acceso remoto con privilegios suficientes para leer los identificadores directamente de sus archivos.
El último que tendré que omitir en esta respuesta, porque no sé lo suficiente sobre su red subyacente. Sin embargo, debido a que eligió implementar su propia seguridad en lugar de usar una herramienta estándar como SSL, TENDRÁ que prestarle atención.
Los ataques de repetición muestran cómo debes manejar la sal. Si el Querier puede generar su propia sal, entonces no hay forma de que el Servicio de respuesta pueda determinar la diferencia entre una solicitud válida y una repetición. Como mínimo, el interrogador debe iniciar la sesión y el Respondedor debe elegir el salt. Debería ser una sal grande (yo solo usaría un número aleatorio de 64 bits). De esta manera, un ataque de repetición es imposible porque cada Respondedor tendrá una sal diferente.
Ahora podemos ver que la sal se puede enviar en texto sin formato, porque podemos ver que la sal no tiene ningún uso, excepto para las solicitudes de salado en esta sesión. No hay posibilidad de reproducción, y no se ha enviado información sobre los identificadores. Cuando los identificadores de hash se envían al Servicio de respuesta, en teoría, la función de un solo sentido los protege ...
... pero al elegir no usar un paquete de software estándar, ahora se ha puesto en riesgo. Tienes que elegir un hash, y no tienes una base masiva de expertos en seguridad que te advierten cuando el algoritmo de hash se está rompiendo como lo hace SSL. Asegúrate de elegir uno bueno
Ahora, en cuanto al número de sales, una sal es suficiente. Podemos usar el modelo de amenaza para probar que la única razón por la que estamos aprovechando es para evitar las repeticiones. Sin el modelo de amenaza, esto no está claro. El modelo de amenaza también deja en claro que incluso un Respondedor defectuoso no puede averiguar lo que solicitó un buscador, porque todo con lo que tienen que trabajar es un salt y un hash ¿o no? . Un respondedor malintencionado siempre podría ofrecer la misma sal, y tener una tabla arco iris de identificadores con sal para trabajar.
Sin un modelo de amenaza, este problema habría pasado. Ahora vemos que el salt debe tener entrada tanto del interrogador como del respondedor, no solo del respondedor. el interrogador debe enviar la mitad del hash, y el respondedor proporciona la segunda mitad. Quizás ambos envían un número aleatorio de 64 bits. Ahora, con nuestro modelo de amenazas, podemos ver que esto no compromete la sal más de lo que ya estaba, pero evita que un Respondedor malintencionado obtenga información con una tabla de arco iris.
Para una prueba final: ¿qué tan aleatorios son tus identificadores? No importa qué sistema diseñes, será posible intentar forzar con fuerza bruta estos identificadores si no tienen suficientes bits de entropía. Si no tienen suficientes bits de entropía, ningún sistema puede protegerlos si un atacante realiza una fuerza bruta ...
... que lleva directamente a SSL. SSL tiene un sistema basado en certificados que puede usar para rechazar ataques de fuerza bruta desde cualquier nodo que no tenga un certificado de confianza válido. Es trivial garantizar que estos tengan suficientes bits de entropía (si los genera con herramientas SSL estándar, estarán más que suficientemente seguros).