Enviar contraseñas a alguien de forma remota

57

Como alguien que generalmente trabaja con personas en otros países, siempre ha sido un problema enviar información de inicio de sesión entre sí.

Para los detalles de inicio de sesión de desarrollo, como las bases de datos de depuración, etc., estoy seguro de que puedo enviarlos en un correo electrónico de texto claro o algo así, pero cuando se trata de información de producción real, como las claves SSH, ¿cómo se los envía de forma segura a alguien cuando el contacto cara a cara no es? t posible.

    
pregunta user36976 22.05.2014 - 14:06
fuente

12 respuestas

41

Usualmente uso SMS. Si bien no es perfectamente seguro, esto es más seguro que el correo electrónico y en general es adecuado. Tiene la gran ventaja de no requerir ninguna configuración, como el intercambio de claves PGP.

Podría hacer esto más seguro enviando la mitad de la contraseña por correo electrónico y la otra mitad por SMS. De forma alternativa (como lo sugiere Michael Kropat), envíe un archivo con la contraseña cifrada simétricamente por correo electrónico y la contraseña de descifrado por SMS.

Para las claves SSH, solo debe transferir la clave pública. Si le está otorgando a un usuario acceso a un servidor, deben enviarle su clave pública, en lugar de enviarles una clave privada. Aún debe confirmar que la clave recibida es auténtica, pero no necesita mantenerla confidencial.

    
respondido por el paj28 22.05.2014 - 15:50
fuente
23

Como ya se ha dicho en el comentario, este es un caso de uso clásico para GPG / PGP. Todos crean una clave, las intercambias de forma arbitraria y luego verificas las huellas dactilares a través del teléfono, un chat de video o cualquier otro canal con una protección razonable contra la manipulación de datos.

También puede firmar las claves de los demás para crear una pequeña red de confianza. Por ejemplo, si ya verificó y firmó las claves del desarrollador A y del desarrollador B, entonces A y B pueden confiar entre sí sin tener que verificar las claves nuevamente.

    
respondido por el Fleche 22.05.2014 - 14:38
fuente
21

Cuando necesito enviar algo una sola vez, he usado One Time Secret . Es una aplicación web de código abierto que le permite ingresar información que solo se puede ver una vez. Una vez que el destinatario ha abierto la página, la información se elimina y lo único que queda en sus registros de chat o correo electrónico es un enlace incorrecto.

No es tan robusto como todo su equipo usando PGP, pero es mucho más fácil de configurar o explicar. He podido usarlo para enviar información de inicio de sesión a personas bastante no técnicas, y les resulta fácil de usar.

    
respondido por el user47079 22.05.2014 - 16:11
fuente
9

Para las claves SSH, las hago generar la clave y enviarme la clave pública, luego podemos comparar las huellas digitales por teléfono.

    
respondido por el Simon Richter 22.05.2014 - 17:20
fuente
8

Puede utilizar el método lento para enviarles por correo (postal) las claves de una llave USB, pero eso en la era actual no es práctico. Lo que hago en situaciones como esta es que tengo un servidor web de operaciones NOC dedicado que utilizo para almacenar las claves en un directorio que crearé para quien necesito enviar las claves. Bloqueo el servidor web con las reglas mod_security y .htaccess para SOLO permitir que la persona que quiera ver ese directorio (a través de IP).

Mi estructura es algo similar a lo siguiente. Supongamos que necesito crear una clave para, por ejemplo, un grupo de desarrolladores en China, crearé un directorio basado en la suma de comprobación de su nombre / grupo, etc.:

[myoto@mymachine ~]# mkdir 'md5 -s devchina | awk '{print $4}'' 
[myoto@mymachine ~]# cd 'md5 -s devchina | awk '{print $4}''
[myoto@mymachine ~/4b4dda9422c2de29f9a0364f1bd8494d]# cp /path/to/ssh_keys/what_I_want_2_copy .

Esto garantiza que nadie pueda tropezar con un directorio usando algo como Nikto / Wikto, etc. Las reglas .htaccess y mod_security me permiten controlar quién llega a ese directorio, y puedo limpiarlo después de verlo a través de los registros, el Se han copiado las claves.

    
respondido por el munkeyoto 22.05.2014 - 14:17
fuente
7

Probablemente no es necesario que envíes claves secretas ssh.

El individuo remoto debe generar un par de claves en su extremo, mantener la clave secreta y enviarle la clave pública.

La clave pública no es un secreto, por lo que no es un problema enviarla sin cifrar. Solo la clave privada es secreta y no es necesario transmitirla porque ya la tienen.

Luego simplemente agrega su clave pública a la lista de claves autorizadas.

El único problema que puede tener es determinar que la clave pública que recibió realmente proviene de la persona a la que desea dar acceso.

Si tienes otra información secreta que necesitas compartir, bueno, ahora ambos tienen acceso seguro al servidor compartido para que puedas usar esa información.

    
respondido por el Samuel Edwin Ward 22.05.2014 - 19:53
fuente
5

Si ambos configuran una cuenta con LastPass , este servicio le permite compartir sus contraseñas (y otra información segura) con otras partes.

    
respondido por el Josh 22.05.2014 - 19:13
fuente
3

Si cada uno puede configurar una cuenta con un sitio seguro para compartir archivos, puede compartir archivos con cada uno de ellos. Si desea hacerlo usted mismo, puede configurar algo como OwnCloud con el cifrado habilitado y usarlo como un medio de intercambio seguro de archivos con varias personas siempre que use SSL para la instancia de OwnCloud y pueda hacer una distribución segura de credenciales fuera de banda. .

    
respondido por el AJ Henderson 22.05.2014 - 15:37
fuente
3

El principal problema de esto es que estamos enviando contraseñas normalmente a usuarios simples, que tienen problemas para abrir un correo firmado con gpg.

Lo que realmente empeoró el problema es que nuestro trabajo / salario / proyecto depende de su criterio, de lo felices que están de colaborar con nosotros. También nuestra primera prioridad es hacer que esta contraseña sea lo más simple posible para ellos. Lamento decir eso, pero en la realidad es más importante para reducir la posibilidad de una ruptura de 0.1% a 0.01% en el próximo mes.

Normalmente hago lo siguiente:

  • Lo envío todo (nombre de usuario, información de inicio de sesión adicional) en un correo simple, sin cifrar, excepto la contraseña real,
  • Remito la contraseña actual como "Te envié esto por SMS"
  • Y envío un SMS simultáneamente con el correo, solo con la contraseña simple, sin ningún comentario.
respondido por el peterh 23.05.2014 - 11:52
fuente
2

Con PGP / GPG (y la mayoría de las otras respuestas sugeridas) tienes que resolver el problema de autenticación para evitar ataques de hombres en el medio. Los SMS no deben considerarse guardados, ya que el cifrado GSM ha sido hackeado durante mucho tiempo.

Yo usaría OTR (no puedo publicar más enlaces, solo google).

Con algún cliente de chat, como pidgin . Incluso puede usar algún canal no seguro, como Facebook, chat de Google, ICQ, lo que sea, establecer una conexión cifrada, autenticar a través de genere SMP y luego intercambie información confidencial.

    
respondido por el Echsecutor 23.05.2014 - 11:14
fuente
1

Utilizaría algún tipo de portal en línea seguro desde el cual los usuarios remotos pueden acceder / descargar la información confidencial. Para darles acceso al portal, recomiendo la autenticación de dos factores con una contraseña temporal (segura) que se debe cambiar al usarlo una vez (pero la autenticación de dos factores garantiza que incluso si el correo electrónico con el pase temporal se ve comprometido, existe). sigue siendo un pin sms).

    
respondido por el Matthew Peters 22.05.2014 - 16:02
fuente
1

Primero, espero que haya configurado sus credenciales para que el usuario DEBE cambiarlas durante el primer inicio de sesión, de modo que quienes las configuren ya no puedan conocerlas.

Si una oficina remota tiene un administrador de confianza, envíe a ese administrador un conjunto encriptado de una sola vez, use las claves / contraseñas para compartir con otros usuarios, de modo que solo puede pedirles que usen la Contraseña # 12 para su inicio de sesión inicial.

Dependiendo de su modelo de amenaza (¿está preocupado por los actores a nivel nacional-estatal, es decir, está trabajando con una oficina en el extranjero en el País 4, que puede participar en el espionaje comercial en nombre de sus competidores locales?), esto es realmente Un caso clásico en el que llamar a alguien en un teléfono fijo es una gran solución.

Simplemente llamar a alguien en un teléfono fijo y decirles que las credenciales de inicio de sesión por teléfono funciona muy bien.

Más allá de eso, GPG es siempre una forma clásica de hacer esto, como respondieron muchas personas. Tengo ejemplos tanto de uso de clave pública como de uso simétrico más seguro que el predeterminado en esta respuesta en Superuser.com .

Dependiendo de sus requisitos reglamentarios, OTR es un método para cifrar las comunicaciones, en particular los mensajes instantáneos (consulte Pidgin como ejemplo) que también permite la autenticación "secreta compartida"; podría compartir una contraseña fácil de escribir en el teléfono mientras que en la mensajería instantánea para validar la sesión de mensajería instantánea no tiene un Man in the Middle, o usar algún aspecto del trabajo que estén haciendo que sería difícil para alguien más tenerlo. de.

Si ya tiene una forma de enviar correos electrónicos en los que solo confía su destinatario y sus propios administradores de red / correo electrónico, y puede confiar en otros productos / compañías, entonces podría usar un servicio de "correo electrónico seguro" como < a href="https://res.cisco.com/websafe/about"> Cisco Registered Envelope Service o una alternativa.

Particularmente para las claves SSH o las contraseñas extremadamente largas y difíciles, puede hacer una combinación de éstas; puede cifrar, tal vez utilizando el modo simétrico de GPG (vea el enlace más arriba), utilizando una contraseña segura y luego entregar esa contraseña a través del teléfono u otro método, para que puedan descifrar el token de autenticación / clave SSH / certificado / etc. p>     

respondido por el Anti-weakpasswords 21.02.2016 - 04:04
fuente

Lea otras preguntas en las etiquetas