Distribución de claves es un tema en el que bastante se han escrito muchos documentos , y probablemente lo harán. Básicamente, uno necesita algún tipo de canal seguro para recibir la clave, pero ese canal seguro aún no está allí, por lo que la clave es necesaria en primer lugar.
El poderoso atacante
Para esta respuesta, comience con la imagen de un atacante muy poderoso, por ejemplo. un atacante Dolev-Yao que puede escuchar, interceptar y sintetizar cualquier mensaje en la red. Por supuesto, estos atacantes tienen mucho más poder de lo que comúnmente es razonable, pero también es el punto de partida en la investigación de seguridad común. Bajaremos el barier más adelante.
Dado nuestro poderoso atacante, en realidad necesitamos un poco de confianza bootstrapped. Por ejemplo, si tiene algún tipo de esquema de cifrado de correo electrónico en su lugar, podría utilizarse. Piense PGP o S / MIME. Esto aún deja un problema de confianza, pero en el primer caso puede delegarse a una decisión informada basada en su web de confianza o en el segundo caso la decisión de la autoridad de certificación (probablemente solo en base a la verificación por correo electrónico). En otras palabras, la confianza está contenida en una de las estructuras existentes, y podemos basar nuestra decisión en suposiciones sobre lo que normalmente se consideran terceros de confianza.
Si pretende utilizar la criptografía de clave pública, por ejemplo, Llaves SSH. Cambias el problema. Ahora, no necesita la confidencialidad de la clave, pero su usuario debe poder mantener la integridad cuando le envíe la clave pública. En el ejemplo de cifrado de correo electrónico, uno tendría que asegurarse de que el mensaje con la clave pública que se usará para el servidor esté firmado por su empleado (en lugar de que esté correctamente cifrado para él y para él solo para que lo lea).
Por lo tanto, cuando la confidencialidad es su problema, encripte con cierta confianza de arranque, como las proporcionadas por las herramientas de encriptación de correo electrónico (o similar), y cuando la integridad es su causa, deje que su empleado firme con la confianza de arranque.
El atacante que es poderoso en un solo canal
Más realista, el atacante tiene poder sobre solo uno o más canales inseguros. En otras palabras, asume la existencia de un canal seguro en el lado de su canal principal. Este canal se puede usar para enviar información adicional que se requiere para comprender el mensaje principal o para verificar el mensaje principal. Por ejemplo, puede cifrar la contraseña con otra contraseña y enviarla por correo electrónico. En el lateral, envías un SMS con la contraseña necesaria para descifrar la contraseña. De esta manera, hay que comprometer dos canales. Tenga en cuenta que esto podría ser cualquier combinación (correo postal, teléfono, SMS, correo electrónico, fax, etc.) siempre que estén lo suficientemente desconectados para que esté seguro. Por lo tanto, un teléfono inteligente que maneja tanto los SMS entrantes como el correo electrónico no es lo suficientemente bueno.
El enfoque de dos canales podría jugarse de manera similar en la situación de integridad, por ejemplo, Enviar la clave pública a través de dos canales separados. De esta manera, debe verificar estos resultados entre sí.
Notas concluyentes
Hay muchos otros métodos, pero espero que esto genere una carga demasiado alta contra no demasiada seguridad adicional, ya que todavía estás tratando con humanos.
Además, las cosas que requieren un cambio de contraseña directamente en el primer inicio de sesión serían adiciones inteligentes.
Finalmente, notará que todas estas son preguntas de confianza, que son fundamentales para muchos sistemas criptográficos y otros métodos de seguridad. Debería encontrar el equilibrio adecuado entre paranoia y ser ingenuo, por ejemplo. el sistema de certificados utilizado por SSL y S / MIME ciertamente no es fantástico, pero generalmente se encuentra lo suficientemente bueno para la banca en línea, por lo que cuando no se está comunicando acerca de misiles nucleares, es probable que funcione bien. Solo asegúrate de hacer una auditoría razonable.
Hable con ellos en una conversación bidireccional lo más cerca posible en tiempo real (conservación en persona / teléfono / mensaje instantáneo / correo electrónico) y deles una contraseña inicial que deba restablecerse en el primer inicio de sesión.
Esto normalmente se hace con el comando chage en linux / unix:
sudo chage -d 0 the_new_user
Luego, verifique que obtuvieron la nueva cuenta utilizando un método independiente (por ejemplo, si los llamó anteriormente; envíeles un correo electrónico), por lo que en caso de que tuvieran una ingeniería social (por ejemplo, su teléfono celular fue robado o el correo electrónico fue interceptado ) hubo un cheque independiente después. Además, no les dé permisos de root u otros permisos elevados hasta que los haya verificado.
EDITAR: La contraseña inicial debe ser algo aleatoria; p.ej. 12 caracteres aleatorios generados por una computadora.
EDIT2: Mitigar contra los espías es simple si se puede confiar en las personas en ambos extremos. Si puede identificar con confianza a la persona que se encuentra en el otro extremo de un teléfono / videoconferencia / etc, déle una contraseña inicial única (que luego tendrá que restablecer), verifique que estén dentro y luego aumente los privilegios. Si es una aplicación web, esta contraseña inicial podría ser un token en un enlace enviado por correo electrónico (que funciona una vez; caduca automáticamente después de un período corto). Si es una cuenta de trabajo, tal vez solo permita que la aplicación web envíe correos electrónicos de contraseña desde / a su dominio local (que ha configurado para usar SSL). Incluso si un interceptor de intercepción de un interceptor, tendrían que vencer a la persona para que lo usara inicialmente (y luego el usuario legítimo tendría problemas que harían que el espía se fuera).
El problema espinoso consiste en establecer la confianza de que un tercero remoto debería tener acceso a la cuenta. ¿Esto comienza con la verificación de la razón por la que le da a este usuario esta cuenta? ¿Son un conocido compañero de trabajo / conocido que necesita acceso a algo nuevo? ¿O su jefe le dijo que le enviara un correo electrónico para darle acceso a [email protected] al servidor X? ¿Podría ser de ingeniería social (alguien que simula ser jefe por teléfono / correo electrónico de jefes robados)? Esta no es una tarea sencilla; sin embargo, revisar las instrucciones en persona, por videoconferencia o por teléfono reduce los riesgos de que el comando se diseñe socialmente. Concedido, su jefe puede ser de ingeniería social, tal vez no se deba confiar en la nueva persona.
Esto puede o no ser útil, pero también podría considerar permitirles que se autentiquen solo a través de claves SSH:
Aún tiene que verificar que la clave pública que está aceptando proviene del usuario que cree que es (es decir, que no tiene una ingeniería social, como se señaló anteriormente), pero es más seguro Correo electrónico alrededor de una clave pública de lo que es una contraseña. (Digo esto porque las claves públicas están destinadas a ser distribuidas, mientras que las contraseñas no lo están. Hay menos daño al dejar una clave pública en un servidor de correo / cliente de correo "para siempre" que una contraseña.)
Para que sea práctico, haga los arreglos por correo regular o mensajero. Luego, envíe un mensaje de texto desde su teléfono móvil (SMS) con la contraseña. Pídale al receptor que confirme por correo o mensajero. Como indica el Dr. jimbob, y si es posible, caduque la contraseña por lo que debe cambiarse con el primer inicio de sesión.
Aquí hay algunas soluciones rápidas y fáciles que no he visto mencionadas aún:
Editar:
Usted está solicitando la "forma oficial correcta" de hacer esto y los métodos bien establecidos son usar criptografía de clave pública o un tercero de confianza (como Kerberos) para ambos fines para confiar el uno en el otro. Ambos tienen equivalentes en el mundo real, como algún tipo de depósito en garantía o un notario público, pero ya sea técnico o no técnico, la implementación a menudo no es práctica.
La única otra alternativa es establecer un secreto precompartido de antemano que ambos extremos puedan usar para autenticarse mutuamente. Es algo así como un espía presenta una frase y el otro espía debe completarla correctamente para que ambas partes sepan que la otra parte es auténtica. En el aspecto técnico, esto generalmente se logra mediante el uso de una función de derivación de claves con un vector de inicialización precompartido. Por supuesto, este método requiere la capacidad de compartir de forma segura un secreto.
Ciertamente hay métodos menos que ideales que aún funcionarían bastante bien en la mayoría de las situaciones. Por ejemplo, usar uno de los servicios como pwpush.com enumerados anteriormente puede permitirle cifrar y limitar la exposición del secreto. Enviar el enlace a una dirección de correo electrónico autentificará al usuario. Básicamente está haciendo lo mismo que en la primera situación, pero está utilizando el proveedor de correo electrónico como una autoridad de confianza para autenticar al usuario. Por supuesto, el correo electrónico no es un método muy seguro, pero es solo un ejemplo. Hay una serie de canales que proporcionan cierta medida de autenticación (como estar en posesión física de un teléfono móvil al que llamas).
Independientemente del método que utilice, siempre deberá involucrar a un tercero de confianza o a una información compartida previamente.
Hay una mejor solución. No distribuya contraseñas. En su lugar, distribuir claves públicas SSH. Pídale a la otra persona que le envíe su clave pública SSH. Luego, agregue su clave pública SSH a un archivo ~/.ssh/authorized_keys en el directorio de inicio de su nueva cuenta. Esto les permitirá iniciar sesión en la cuenta.
Puede hacer que le envíen un correo electrónico con la clave pública de SSH. La clave pública no es secreta, por lo que no tiene que preocuparse por las personas que la roban. (Debe asegurarse de obtener la clave pública SSH adecuada de la persona correcta, pero en la práctica habitual, a menudo es suficiente contactar a la persona y pedirle que le envíe su clave pública SSH por correo electrónico. Si es paranoico o tiene una En una instalación de alta seguridad, puede llamarlos y pedirles que lean el hash de su clave pública.)
Además de simplificar el problema de comunicación, esto también tiene el beneficio de evitar las contraseñas, que tienen problemas conocidos: tienden a ser susceptibles de escuchas ilegales, ingeniería social y ataques de diccionario.
Voy a ser ingenuo aquí.
Supongamos que no desea utilizar ningún protocolo basado en el intercambio de claves Diffie-Hellman, le sugiero esta técnica muy empírica:
cree la cuenta y establezca la contraseña en randomShortString
llamar al usuario:
ADMINISTRADOR: Hola, usuario A, esta es tu contraseña: randomShortString . Inicia sesión ahora mismo y luego escribe "passwd" y configura una nueva contraseña diferente.
USUARIO A: Hola, administrador, gracias. He iniciado sesión ... y sí, ahora he cambiado mi contraseña.
ADMINISTRADOR : su usuario A, contraseña ... error de inicio de sesión. "Ok, gracias usuario A"
Yo diría que si es solo para un usuario, esto funcionará ...
Si solo conoce a la persona como una voz en un teléfono en otro estado, ninguna verificación secundaria le proporcionará ninguna garantía adicional de esa identidad. Llamarlos por teléfono proporciona un circuito fuera de banda, autenticarse a través de voz y darles una contraseña temporal es una norma de la industria.
Si presionas esta pregunta lo suficiente, entras en un concepto muy abstracto de "Identidad". Que es un nombre ¿Por qué tiene significado? ¿Qué valor tiene que el gobierno tenga un registro que vincule ese nombre con esa cara? ¿Por qué es importante para tu interacción? ¿Confía en la identificación emitida por el gobierno o confía realmente en la persona que conoció en esa convención, independientemente de lo que le digan que es su nombre?
Si esta persona tiene conocimientos de tecnología decente, GPG (PGP) es una forma ideal y fácil de lograr esto:
Infraestructura PKI (corporativa o de terceros), certificados personales de S / MIME, intercambio por claves públicas (correo electrónico, correo postal), verificación del autor mediante huellas digitales (voz), cifrado S / MIME correo para la transferencia de datos final.
Forma inquebrantable (en tiempo mensurable, ahora)
Lea otras preguntas en las etiquetas passwords password-management