¿Qué haría si se diera cuenta de que su proveedor de alojamiento de correo electrónico podría ver sus contraseñas?

Recibimos un correo electrónico el año pasado de nuestro proveedor de hosting con respecto a una de nuestras cuentas, que se había visto comprometida y utilizada para brindar una ayuda bastante generosa de spam.

Aparentemente, el usuario había restablecido su contraseña a una variación de su nombre (el apellido es algo que probablemente podría adivinar la primera vez). Fue rápidamente pirateada en una semana, su cuenta envió un diluvio de 270,000 correos electrónicos no deseados y fue muy rápido obstruido.

Hasta ahora, nada particularmente inusual. Eso pasa. Cambia sus contraseñas a algo más seguro, educa al usuario y sigue adelante.

Sin embargo, algo me preocupaba aún más que el hecho de que una de nuestras cuentas había sido comprometida.

Nuestro proveedor de alojamiento, en un esfuerzo por ser útil, nos citó la contraseña en el siguiente correo electrónico:

Estoy asombrado. Tenemos previsto renovar nuestro contrato pronto, y esto se siente como un factor decisivo.

¿Qué tan común es que un proveedor de hosting pueda averiguar la contraseña real utilizada en una cuenta?

¿La mayoría de los proveedores de hosting tienen un departamento de abuso de cuentas que tiene más acceso que los representantes de primera línea (y pueden buscar contraseñas si es necesario), o estos tipos simplemente no siguen las mejores prácticas para que cualquiera de su personal pueda acceder al usuario contraseñas ¿Pensé que las contraseñas debían ser hash y no recuperables? ¿Significa esto que almacenan las contraseñas de todos en texto plano?

¿Es legal que un proveedor de hosting pueda descubrir contraseñas de cuentas de esta manera? Simplemente me parece increíble.

Antes de analizar el cambio de proveedor, me gustaría asegurarme de que esto no es una práctica común, y que nuestro próximo proveedor de alojamiento probablemente tampoco tenga las cosas configuradas de la misma manera.

Esperamos escuchar sus opiniones sobre esto.

Sí, es común que los ISP y los proveedores de servicios de correo electrónico almacenen su contraseña en texto sin formato, o en un formato que sea fácilmente recuperable en texto sin formato.

La razón de esto tiene que ver con los protocolos de autenticación utilizados con PPP (acceso telefónico y DSL), RADIUS (acceso telefónico, 802.1x, etc.) y POP (correo electrónico), entre otros.

La desventaja aquí es que si las contraseñas se codifican en un sentido en la base de datos del ISP, entonces los únicos protocolos de autenticación que se pueden usar son aquellos que transmiten la contraseña por cable en texto sin formato. Pero si el ISP almacena la contraseña real, entonces se pueden usar protocolos de autenticación más seguros.

Por ejemplo, la autenticación PPP o RADIUS podría usar CHAP, que asegura los datos de autenticación en tránsito, pero requiere que el ISP almacene una contraseña de texto sin formato. De manera similar con la extensión APOP a POP3.

Además, todos los diversos servicios que ofrece un ISP utilizan diferentes protocolos, y la única forma limpia de hacer que todos se autentiquen en la misma base de datos es mantener la contraseña en texto sin formato.

Sin embargo, esto no aborda los problemas de quién entre el personal del ISP tiene acceso a la base de datos y qué tan bien está protegida . Todavía debe hacer preguntas difíciles sobre eso.

Sin embargo, como probablemente ya haya aprendido, es casi imposible que la base de datos de un ISP se vea comprometida, mientras que es muy común que los usuarios individuales se vean comprometidos. Tienes riesgo de cualquier manera.

Vea también ¿Me equivoco al creer que las contraseñas nunca deberían ser recuperables (hash unidireccional)? en nuestro sitio asociado Seguridad de TI

Esto, desafortunadamente, es bastante común con los hosts de presupuesto y no es inaudito incluso con hosts más grandes. Cosas como cpanel con frecuencia necesitan su contraseña de texto sin formato para poder iniciar sesión en varios servicios como usted, etc.

Lo único que puede hacer es preguntar por adelantado si las contraseñas están en hash.

Es probable que estén almacenando contraseñas en texto plano o usando algún tipo de cifrado reversible.

Como has supuesto, esto es muy malo.

Ya sea por malicia o negligencia de los empleados, o por un compromiso de sus sistemas por parte de un tercero, el uso indebido de las contraseñas de texto sin formato crea un riesgo grave, no solo para sus sistemas, sino también para otros sistemas en los que las personas podrían haber usado la misma contraseña.

El almacenamiento responsable de las contraseñas significa el uso de funciones de hashing unidireccionales en lugar de cifrado reversible, con una sal (datos aleatorios) agregada a la entrada del usuario para evitar el uso de tablas arcoíris .

Si estuviera en su lugar, le haría al proveedor algunas preguntas difíciles sobre cómo, exactamente, almacenan las contraseñas y cómo, exactamente, su representante de soporte pudo recuperar la contraseña. Esto puede no significar que almacenan las contraseñas en texto plano, pero tal vez las estén registrando en algún lugar cuando se cambian, lo que también es un gran riesgo.

Todas las otras respuestas son geniales y tienen muy buenos puntos históricos.

Sin embargo, vivimos en la época en que el almacenamiento de contraseñas en texto sin formato causa enormes problemas financieros y puede destruir por completo las empresas. Enviar contraseñas en texto plano a través de correo electrónico inseguro también suena ridículo en la era de la NSA que absorbe todos los datos que pasan.

No tiene que aceptar el hecho de que algunos protocolos antiguos requieren contraseñas en texto sin formato. Si todos dejamos de aceptar tales servicios, probablemente los proveedores de servicios harían algo al respecto y finalmente desaprobarían la tecnología antigua.

Algunas personas pueden recordar que una vez, cuando desea abordar un avión para volar a otro país, literalmente simplemente entra al avión desde el estacionamiento de la calle. Sin seguridad alguna. Hoy en día, las personas se dieron cuenta de que se requieren medidas de seguridad apropiadas y que todos los aeropuertos las han implementado.

Me cambiaría a otro proveedor de correo electrónico. La búsqueda en "proveedor de correo electrónico seguro" arroja muchos resultados.

Hubo algunos buenos puntos en los comentarios. Probablemente la búsqueda de "proveedor de correo electrónico seguro" tendría mucho sentido ya que todos los proveedores de correo electrónico se jactarían de que son seguros. Sin embargo, no puedo recomendar una empresa en particular y probablemente tampoco sea una buena idea hacerlo. Si identifica a una empresa en particular haciendo preguntas difíciles sobre seguridad primero, será algo bueno.

¡Mi recomendación es irse y preguntar a los siguientes tipos cuáles son sus políticas primero!
Si se siente bien, puede decirle a los proveedores anteriores por qué se va.

También para abordar la declaración de otra respuesta, los días de las tablas del arco iris han pasado. Han sido reemplazados por GPU de alta potencia y ocupan demasiado espacio de almacenamiento (los hash binarios obviamente no se comprimen bien; y de todos modos no los almacenaría en ASCII). Es más rápido (re) calcular el hash en una GPU que leerlo en el disco.

Dependiendo del algoritmo hash utilizado y la GPU, se puede esperar que una computadora moderna para descifrar contraseñas produzca entre 100 y mil millones de hash por segundo. De acuerdo con esto , (que está un poco anticuado sobre lo que cree que puede hacer una computadora / supercomputadora), eso significa que cualquier contraseña de 6 caracteres puede descifrarse en segundos. Las tablas para los hash de caracteres 7 y 8 en todos los diversos algoritmos (MD5, SHA-1, SHA-256, SHA-512, Blowfish, etc.) consumirían cantidades excesivas de espacio en disco (tenga en cuenta que debe almacenarlos en un SSD , no una bandeja magnética, para la velocidad de acceso) y puede ver por qué los ataques basados ​​en el diccionario que usan la GPU producirán contraseñas más rápidamente.

Un buen artículo para los que entran en escena es Cómo me convertí en un descifrador de contraseñas en Ars Technica.

Esto me pasó a mí!

Hace algunos años, mi identidad se vio comprometida cuando mi proveedor de alojamiento (que también era mi proveedor de correo electrónico en ese momento) sufrió una violación de seguridad. Me desperté al no poder revisar mi correo electrónico porque mi contraseña había sido restablecida. Con el control de mi correo electrónico, intentaron restablecer mi contraseña en Amazon y PayPal. Puedes adivinar lo que vino después, ¿verdad? Cargos fraudulentos de tarjeta de crédito!

Afortunadamente, pude averiguar lo que sucedía relativamente rápido, llamar a mi proveedor de alojamiento por teléfono y validar minuciosamente mi identidad a pesar de que la información de la cuenta y las preguntas de seguridad se modificaron (todo en unas pocas horas). Durante esta conversación, el representante de servicio al cliente pudo decirme el historial de mi contraseña, cuándo se modificó y a qué. Eso fue todo lo que necesitaba escuchar para saber que necesitaba cambiar de proveedor.

¡No hay razón para que le suceda a usted, nuestra empresa!

Tenía mis sospechas sobre la minuciosidad de esta empresa en lo que respecta a la seguridad, cosas que había notado aquí y allá durante mis años de tratar con ellos. Pero siempre me convencí de que no era un gran problema o tal vez me equivoqué. ¡No me equivoqué, y tú tampoco!

Si hubiera actuado cuando sospeché por primera vez que no se estaban tomando en serio la seguridad, esa mini-pesadilla nunca hubiera sucedido. ¿Pensar qué podría ocurrir en caso de que se comprometiera una valiosa cuenta corporativa? Te irías fácil si solo enviaran SPAM. La compañía para la que trabajaba en ese momento también estaba usando este proveedor y nuestra prioridad era hacer la transición lo más rápido posible.

¡Confía en tus instintos! No pase el dinero en migrar por pereza o porque su configuración existente "funciona bien". La parte más condenatoria de descuidos de seguridad bajos como el almacenamiento de contraseñas en texto claro, la configuración incorrecta de servidores, etc. es que hablan de una incompetencia general y / o pereza en su cultura técnica, y esa es una cultura que no quisiera que la misión de mi empresa sea crítica Contrato de servicio en cualquier lugar cercano.

Puedo ver una explicación alternativa, donde su contraseña en realidad está cifrada en los servidores de su proveedor.

Cuando el proveedor lo contactó solo un día después, probablemente (y esto es una suposición) lo retiró de los registros del servidor ya que su script de cambio de contraseña está enviando datos a través del método GET.

Parece más simple que su proveedor tenga una base de datos llena de registros de cuándo, quién y cómo cambió su contraseña. Conoces la navaja de Occam ...;)