¿Cómo pueden los clientes enviarme contraseñas de forma fácil y segura? [cerrado]

39

A menudo necesito obtener contraseñas de clientes para FTP, SSH, MySQL, Authorize.net, etc.

¿Cuál es una manera fácil para que me envíen contraseñas de forma segura? ¿Quizás incluso sin que necesiten un nombre de usuario / contraseña?

Las sesiones de mensajería instantánea cifradas son una molestia para configurar con personas no tecnológicas. Las llamadas telefónicas rompen mi concentración y requieren arreglos. (¿Las llamadas VOIP son seguras, de todos modos?)

Ideal: una forma fácil para que las personas sin conocimientos técnicos envíen correos electrónicos encriptados. PGP / GPG no lo corta , a menos que Outlook tenga un asistente incorporado súper fácil. (Nunca sabes...?)

Bien: un sistema de mensajes seguro basado en la web (con suerte en PHP) que podría alojar y ejecutar sobre SSL. No he podido encontrar nada como esto.

Tal vez estoy preguntando lo incorrecto o lo incorrecto. Cualquier sugerencia es apreciada!

Adam DiCarlo
fuente
2
Que ellos puedan saber su contraseña en el primer lugar es un problema bastante grande de seguridad
Ciaran
1
Nota: esta pregunta es un duplicado de stackoverflow.com/questions/1262424/… (Adam aparentemente no sabía sobre la función de migración de preguntas), si la pregunta se migra aquí al superusuario, una u otra debe cerrarse como un duplicado .
bdonlan
44
Nunca conocen mis contraseñas, pero tengo que saber toneladas de las suyas, siendo su desarrollador web.
Adam DiCarlo
1
Pregunta relacionada en ServerFault: serverfault.com/questions/61402/…
Tim Lytle
1
También hay onetimesecret.com , es de código abierto y elimina la contraseña después de que se vio. Entonces, si puedes verlo, nadie más lo hizo.
PiTheNumber

Respuestas:

13

Su idea de un sistema de mensajería basado en la web podría implementarse en unas pocas docenas de líneas de HTML y PHP (principalmente html) en cualquier sistema que tuviera instalado un servidor web SSL y GPG. Realmente es un programa de tipo formmail muy simple pero especializado. Incluso podría hackear un script CGI de formmail existente para insertar una llamada a GPG (suponiendo que ya no exista, intente buscar en Google para formmail + GPG)

  • Si aún no lo ha hecho, instale gpg en su estación de trabajo y cree sus claves públicas y privadas
  • Cree una página php que muestre un formulario para aceptar un mensaje (campo de texto), lo encripte con gpg usando su clave pública y se lo envíe por correo electrónico. Codifique su dirección de correo electrónico en la secuencia de comandos (es decir, no permite que el remitente especifique a quién enviar)
  • Instale la página php en un servidor ssl existente o cree uno solo para la tarea. Un certificado autofirmado es lo suficientemente bueno para este trabajo.
  • Dígale a su cliente la URL cuando necesite que le envíen un nombre de usuario y contraseña.

Por cierto, Thunderbird tiene el complemento Enigmail que hace que el uso del cifrado GPG sea muy fácil. Pero todavía es probablemente demasiados problemas para los usuarios ocasionales.

cas
fuente
Estaba pensando que probablemente tendría que hacer algo así. Si lo hago, lo convertiré en un proyecto de código abierto si puedo pensar en un buen nombre para él.
Adam DiCarlo
77
¡Piense en todos los proyectos de código abierto que nunca fueron de código abierto porque alguien no podía pensar en un buen nombre!
Robert
1
ahora hay crypto.cat, una suite / sitio web de cifrado de chat de código abierto.
Ampersand
23

PGP es popular.

También puede probar el método probado y verdadero de una reunión en un estanque, preferiblemente con los dos usando gabardinas.

Paxxi
fuente
66
+1 tanto para el PGP como para la "conexión francesa" ;-)
Rook
1
Para aquellos de ustedes que era una versión FOSS, GPG hace lo mismo.
Dentrasi
77
Estaba tratando de evitar PGP / GPG, esto es para personas no expertas en tecnología que no necesariamente tienen mucho tiempo (o paciencia) para algo involucrado.
Adam DiCarlo
@AdamDiCarlo, así que supongo que vas al estanque
ironicaldiction
7

Esta es una combinación entre un archivo de texto y una llamada telefónica:

Haga que su cliente coloque la contraseña en un archivo de texto sin formato y luego suelte el archivo de texto en un archivo zip protegido con contraseña. (7zip es gratis y de código abierto). Pídales que le envíen por correo electrónico el archivo cifrado .zip / .rar / .7z y luego llame con su nombre de usuario y la contraseña del archivo zip.

Esto evita que alguien abra el archivo zip, e incluso si lo hicieran, es solo una contraseña, que no le brinda nada sin otra información, como nombre de usuario y dónde usarlo.

Además, esta es una forma de enviar por correo electrónico un tipo de archivo "prohibido", como un .exe, a un cliente de correo electrónico que escanea los archivos adjuntos y las cremalleras internas. En esos casos, generalmente incluyo la contraseña del archivo comprimido en el correo electrónico, y generalmente es "contraseña". Sin embargo, es suficiente para evitar que el software de correo electrónico verifique el contenido.

Jared Harley
fuente
1
Si bien esto aumenta la seguridad al agregar más capas, no simplifica el proceso. Todavía tienes que tener una llamada telefónica.
Spuder
Por otro lado, me gusta la idea de un segundo canal de comunicación para transmitir información mínima similar a un PIN. No asumiría que un no experto en tecnología sabe cómo hacer un archivo zip, por lo que no usaría esta respuesta tal como está. Pero podemos suponer que prácticamente todos los profesionales tienen un teléfono celular al que se puede enviar un número PIN, lo que puede ser una verificación de seguridad útil como parte de una autenticación inicial segura basada en la web.
ToolmakerSteve
4

No compliques demasiado el asunto y no sobreestimes la importancia de lo que tu cliente te está enviando.

Si cualquiera de las computadoras tiene un registrador de claves en ejecución, ninguna cantidad de cifrado protegerá esas valiosas contraseñas.

No enviaría REALMENTE contraseñas confidenciales a través de Internet (como la contraseña de un administrador) sino para las aplicaciones que mencionó. No vale la pena el esfuerzo para asegurarlos en caso de que alguien pueda estar interceptando sus correos electrónicos.

Si su cliente está preocupado, tiene varias opciones:

  1. Aprenda a enviar correos electrónicos encriptados.
  2. Enviar un fax, si es posible.
  3. ¿Correo postal? (lol)
  4. Hable claramente por teléfono usando un alfabeto fonético
EvilChookie
fuente
3
Las aplicaciones que mencioné incluyen Authorize.net. Considero que REALMENTE sensible como (olvidé mencionar) estoy hablando de la clave de transacción . Esta clave permite no solo aceptar pagos, sino básicamente hacer pagos (el propósito es acreditar a los clientes para reembolsos). También el acceso SSH / FTP y MySQL permite al usuario volar su sitio web ... Creo que es importante protegerlo también. Dices si mi cliente está preocupado; ¿No es mi responsabilidad como profesional no decir, "adelante y envíeme sus contraseñas confidenciales por correo electrónico?"
Adam DiCarlo
Claves de transacción: no hay duda. Envíelos por fax, use el teléfono, lo que sea más fácil. Pero para un sitio web de cliente? Claro, es algo importante, pero no vale la pena hacer todo el esfuerzo para asegurar el correo electrónico. Si alguien quiere deshacerse de uno de los sitios web de su cliente, hay formas mucho mejores de deshacerse de él que la posibilidad de interceptar un correo electrónico: ataques DDoS, inyección de SQL, hay innumerables millones de formas de derribar un servidor web, y robar las credenciales de alguien olisqueando un correo electrónico no es una de las mejores. Como dije, no sobreestimes la importancia de la información.
EvilChookie
1
Y dado que trabaja con sitios web, debe saber mejor que la mayoría que simplemente no almacena cosas importantes en el sitio web.
EvilChookie
# 4 es discutible si Tío, o cualquier persona que supervise el trabajo de Tío, quiere la contraseña. La NSA garantiza que cualquier teléfono móvil será grabado, al igual que cualquier llamada de línea fija a línea fija que cruza un límite LATA. Una llamada telefónica dentro del intercambio de Milwaukie telcodata.us/view-switch-detail-by-clli?clli=MLWKOR17DS0 no se supervisará sin una orden judicial, pero sí una llamada de Milwaukie a Portland.
K7AAY
3

configure un archivo de Password Safe en un fragmento de Dropbox , para que los clientes puedan agregar contraseñas según sea necesario.

Joel describe la técnica aquí

Ryan
fuente
3
Idea interesante, pero implica que cada cliente aprenda / use no solo Password Safe, sino también Dropbox, y presumiblemente dropboxes separados para cada cliente. No quiero que vean los archivos seguros de contraseña de otras personas allí, eso se vería mal (a pesar de que no tendrían la contraseña para abrir las cajas fuertes de otros).
Adam DiCarlo
3

¿Qué hay de Cryptocat ? Seguro, fácil de usar y un navegador es todo lo que necesita. Para más detalles, consulte la página Acerca de .

Como Ian Dunn ha señalado, el sistema tiene la falla de que un atacante podría pretender ser su cliente. La única seguridad en este caso sería el nombre de la sala de chat que luego se convertiría en la contraseña . Problema cambiado, pero no resuelto.

Sin embargo, a menudo necesito enviar a los clientes más de 30 ensaladas de char (las llamamos contraseñas) y principalmente uso crypto.cat para intercambiar las credenciales mientras hablo con ellos por teléfono. Esto parece ser muy seguro para mí y el cliente puede usarlo CTRL+C.

TeX HeX
fuente
2
Una de las desventajas de usar crypto.cat para este propósito es que aún tiene que compartir el nombre de la sala de chat, que esencialmente se convierte en una contraseña en sí misma. Si un atacante intercepta el nombre de la sala, podría suplantar al cliente y obtener la contraseña del sistema. Entonces, ahora necesita una forma de compartir de forma segura la contraseña de crypto.cat, y está de vuelta en el punto de partida. No es básicamente más seguro, solo agrega una capa extra débil. Sin embargo, 2 capas débiles siguen siendo mejores que 1, y si desea mantener el proceso simple, entonces quizás sea un riesgo aceptable.
Ian Dunn
Creo que una llamada telefónica es una forma menos mala de transmitir la información. El identificador de llamadas puede ser falsificado, pero es mucho más difícil imitar la voz, los gestos, etc. de alguien
Ian Dunn
@ Ian Dunn: Bien, entiendo tu punto. Editaré mi respuesta.
Tex Hex
Sí, si ya estás hablando por teléfono con ellos, entonces es mucho mejor que si les envías un correo electrónico / mensaje de texto con el nombre de la habitación. Personalmente, prefiero el proceso que expuse en mi respuesta, pero creo que su enfoque también es bueno.
Ian Dunn
3

Es posible que desee probar NoteShred. Es una herramienta hecha para su necesidad exacta. Puede crear una nota segura, enviar a alguien el enlace y la contraseña y hacer que se "triture" después de leerlo. La nota desapareció y le enviamos una notificación por correo electrónico para informarle que su información ha sido destruida.

Es gratis y no requiere ningún registro.

https://www.noteshred.com

Cheyne
fuente
Me gusta la idea, pero si envía el enlace por correo electrónico con la contraseña, ¿no es inseguro nuevamente? Si un atacante puede ver una contraseña en un correo electrónico, ¿también puede ver el enlace + contraseña en un correo electrónico?
Wim Deblauwe
Obviamente no vas a enviar la contraseña en un correo electrónico con el enlace. Tiene la opción de transferir la contraseña siempre que lo desee. Además, incluso si el atacante obtuvo la contraseña, solo la primera persona que vea la nota verá el contenido, luego se triturará. Entonces la contraseña es inútil.
Cheyne
2

La mensajería instantánea de Skype está encriptada .

Ahora, aquí vienen las advertencias necesarias: Skype no es de código abierto, por lo que no sabe si hicieron un trabajo terrible o si instalaron una puerta trasera del gobierno o copiaron todos los mensajes a Bob en TI, pero la mejor evidencia disponible sugiere que es seguro.

Ryan
fuente
66
Ahora sabemos con certeza, gracias a Snowden, que definitivamente hay puertas traseras del gobierno para Skype
Robert J Berger
1
Esto debería ser rechazado votado en el suelo.
PiTheNumber
1
Esta es una vieja respuesta, pero sigue siendo interesante. Skype ya no debe considerarse una forma "segura" de enviar información confidencial ( support.skype.com/en/faq/fa31/does-skype-use-encryption ) ... Básicamente, los mensajes instantáneos están encriptados de extremo a extremo para mensajes directos, pero solo su extremo a la nube para mensajes instantáneos basados ​​en la nube. Los mensajes directos van a desaparecer. Por lo que cualquier mensajes instantáneos enviados a través de Skype son (o serán) no cifrado de extremo a extremo.
rocketmonkeys
2

Este proceso no funciona en todas las situaciones, pero creo que es bueno para sistemas multiusuario (como un CMS o un panel de control de hosting):

  1. El cliente te llama por teléfono.
  2. Mientras está hablando por teléfono, el cliente inicia sesión en el sistema y crea una nueva cuenta de administrador específicamente para usted, en lugar de darle acceso a la existente.
  3. Escogen una frase de contraseña relativamente simple, aleatoria (pero de más de 15 caracteres) para la contraseña inicial (por ejemplo, conducir a Portland este fin de semana o dónde están mis auriculares )
  4. Te dicen la frase de contraseña por teléfono.
  5. Inmediatamente inicia sesión en el sistema y restablece la contraseña a algo realmente seguro , por ejemplo seguro #] t'x:} = o ^ _% Zs3T4 [& # FdzL @ y> a26pR "B / cmjV .
  6. Usted almacena la contraseña final en su administrador de contraseñas.

Las ventajas de este enfoque son que:

  1. Es relativamente simple para el cliente. Solo tienen que saber cómo crear una cuenta en el sistema. Puedes guiarlos mientras estás hablando por teléfono si tienen problemas.
  2. Es relativamente simple para ti también. No tiene que ocuparse de configurar y compartir archivos cifrados, alojar una aplicación de formulario personalizado, etc.
  3. Utiliza una frase de contraseña (en lugar de una contraseña) para que la contraseña temporal sea fácil de comunicar por teléfono, pero también sea relativamente segura.
  4. La contraseña final nunca se transmite (excepto el formulario de restablecimiento de contraseña, por supuesto, pero el sistema debe encriptarlo).
  5. El cliente nunca conoce la contraseña final, por lo que no pueden exponerla accidentalmente a los atacantes. Por supuesto, aún pueden exponer la contraseña de su propia cuenta, pero una investigación post mortem de un incidente rastrearía la penetración en su cuenta, no en la suya;)

La frase de contraseña inicial es el eslabón más débil de la cadena debido a su entropía relativamente baja y su transmisión insegura por teléfono. Sin embargo, todavía tiene ~ 100 bits de entropía, y solo vive de 15 a 90 segundos. En mi opinión, eso es lo suficientemente bueno a menos que esté trabajando en algo altamente sensible, o sepa que actualmente está siendo atacado personalmente por un buen hacker.

Ian Dunn
fuente
Si va a votar en contra, explique por qué ...
Ian Dunn
Yo no, pero probablemente porque la pregunta tiene 3 años.
Ampersand
3
Eso no tiene sentido para mí. Este no es un hilo del foro; El objetivo de los sitios de Stack Exchanges es construir un repositorio de conocimiento. Creo que la edad de la pregunta es irrelevante. Incluso hay insignias para trabajar en viejas preguntas, como Nigromante y Arqueólogo. Pero, si alguien ve algún defecto en mi respuesta, indíquelo para que pueda mejorarlo.
Ian Dunn
Ese es un buen punto. Debe enviar una respuesta crypto.cat.
Ampersand
2

Algunas personas en este hilo sugirieron crear una aplicación web para hacer precisamente eso. De hecho, algunos incluso crearon los suyos. Hablando francamente, no creo que sea una buena idea confiar en extraños para un servicio como ese. Implementé una aplicación web básica que permite a los usuarios intercambiar contraseñas a través de una interfaz web simple y la hice disponible libremente bajo la licencia MIT.

Compruébalo aquí: https://github.com/MichaelThessel/pwx

Se tarda minutos en configurar dentro de su propia infraestructura y puede examinar el código fuente. He estado usando mi propia instalación con mis clientes durante meses e incluso las personas que no son de tecnología la recogieron en muy poco tiempo.

En caso de que desee probar la aplicación sin instalarla primero, puede echar un vistazo aquí:

https://pwx.michaelthessel.com

revs Michael Thessel
fuente
Dijiste " No creo que sea una buena idea confiar en extraños para un servicio como ese " y luego recomendarles que usen tu código para hacer esto. ¿Cómo es su código (usted también es un extraño) más seguro que el código de otros extraños al azar?
DavidPostill
Todas las otras soluciones en este hilo ofrecen soluciones alojadas de código cerrado en sus propios servidores. Esta solución es de código abierto. Puede revisar el código, asegurarse de que no hace nada malicioso e instalarlo en su propia infraestructura. Esta es la belleza del código abierto.
Michael Thessel
Muchas gracias por ofrecer una versión autohospedada de estas utilidades Michael. Veo sus argumentos perfectamente y probablemente seguiremos su ejemplo (además, la marca es mejor). Trabajo brillante!
Foliovision
1

¿Qué tal enviar las contraseñas a través de un buen SMS antiguo ? Es muy simple y, siempre y cuando no proporciones ninguna otra información en el texto, será muy difícil saber a dónde va.

Leif
fuente
Escribir contraseñas largas y complejas en un teléfono (y a veces leerlas) es propenso a errores.
Walf
0

Este es un poco más de esfuerzo, pero también ahorra tiempo al cliente:

Configúrelos con algo como Roboform pero almacene los datos en la web para que pueda acceder a ellos. Cuando inician sesión en algún lugar, RF guardará la contraseña y estará disponible para usted.

Desventajas:
* No estoy seguro de cuán seguro es el almacenamiento en línea de Roboform * Luego tiene acceso a todas las contraseñas del cliente y puede que no les guste esa idea.

Nichols de arcilla
fuente
0

Usar Outlook o Thunderbird con S / MIME es fácil, pero aún mejor es que lo llamen y le lean su contraseña. Otra parte de ella.

RAM
fuente
0

Si el uso es muy temporal, como la solución de problemas única o la transferencia de archivos, este nivel de seguridad puede ser innecesario. Haga que el cliente cambie temporalmente la contraseña a algo que usted conoce, haga su trabajo, luego haga que el cliente la cambie de nuevo. Incluso si se descubrió la contraseña temporal, será obsoleta antes de que pueda usarse con fines nefastos.

fijador1234
fuente
0

Un amigo mío creó este sitio web específicamente por este motivo: https://pwshare.com

Para mí y mis amigos en el mundo del hosting, una gran herramienta para enviar rápidamente contraseñas a los clientes.

Desde la página Acerca de: https://pwshare.com/about PWShare utiliza una especificación de cifrado de clave pública / privada conocida como RSA. Cuando el cliente desea enviar una contraseña, se solicita una clave pública del servidor.

El cliente encripta la contraseña antes de enviarla al servidor. Debido a esto, el servidor no conoce ni almacena la contraseña descifrada.

Solo utilizando el enlace, que contiene el identificador de clave privada y la contraseña, se puede descifrar la contraseña.

Mark Kraakman
fuente
-1

Recomendaría usar algo como axcrypt. Es muy intuitivo, por lo que incluso las personas con dificultades técnicas pueden hacerlo funcionar.

Descargue AxCrypt aquí

Cuando utiliza AxCrypt, usted o la persona con la que está tratando puede crear un archivo con todas las contraseñas / información confidencial y luego cifrarlo con una frase de contraseña. Siempre recomiendo, como mínimo, intercambiar la frase de contraseña por teléfono o en persona (esta es la mejor opción). AxCrypt utiliza un cifrado decente, por lo que puede estar seguro de que mantendrá a todos menos al adversario más decidido. La mejor parte de AxCrypt es que se integra en Windows como una extensión de explorador. En Windows Explorer, todo lo que necesita hacer es hacer clic derecho en el archivo para cifrarlo / descifrarlo /

¡Feliz cacería!

Axxmasterr
fuente