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

31

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:

ingrese la descripción de la imagen aquí

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.

Austin '' Peligro '' Poderes
fuente
44
Aunque obviamente es de gran preocupación, por lo que sabes, este es un golpe doble de un representante del teléfono que registra la nueva contraseña en un ticket (que nunca deberían hacer) y otro representante que lo ve en las notas del ticket. Tiene derecho a exigir respuestas, pero tal como está, no sabe cómo se recuperó la contraseña.
Andrew B
1
Sé con certeza que el usuario estableció la contraseña a través de la interfaz web. Lo sacaron de los registros en el servidor: nadie en la oficina les habló por teléfono (además, creo que este proveedor solo tiene soporte por correo electrónico)
Austin '' Peligro '' Powers
3
¿Que debería hacer? Encogimiento de hombros. Todo lo que haces en sistemas controlados por otra persona es visible para ellos. Si no desea que otra persona tenga esta visibilidad en sus sistemas de correo electrónico, ejecútelos y guárdelos. Es posible que no apruebe lo que hacen con la información que tienen por definición, pero si no hay obligaciones contractuales sobre ellos de no hacerlo, bueno, usted firmó los contratos.
MadHatter apoya a Monica el
19
El almacenamiento de una contraseña de texto sin formato es malo (¡como Time to find a new providermalo!); Mucha gente lo hace pero aún así: MALO. ¿Enviarle la contraseña en un correo electrónico sin cifrar ? TODO MI NOPE . Eso muestra un desprecio casual por la seguridad. Corre, no camines, a un nuevo proveedor con algo de sentido común ...
voretaq7
2
Me gustaría ampliar lo que dijo @MadHatter: Mucha gente aquí se está centrando en la idea de "almacenar contraseñas de texto sin formato". El hecho simple es que si estoy ejecutando un servidor POP / IMAP, un servidor SSH o cualquier otra cosa en la que pueda escribir su contraseña, se puede configurar para registrar esa contraseña cuando la ingrese , independientemente de si Estoy almacenando cosas en hash o en texto sin formato. Google puede ver su contraseña y Dropbox puede ver su contraseña y Facebook puede ver su contraseña, etc. Usted confía en su proveedor o lo aloja usted mismo.
Larsks 01 de

Respuestas:

33

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

Michael Hampton
fuente
2
APOP es prácticamente un protocolo muerto, y MSCHAPv2 no necesita que el servidor conozca la contraseña de forma clara: realmente no creo que haya muchas razones para que un proveedor de servicios mantenga contraseñas claras en estos días.
Shane Madden
1
@ShaneMadden Tienes razón; es CHAP, en lugar de MSCHAP. Y sí, estos protocolos están casi muertos, pero los proveedores de servicios que han existido desde siempre pueden seguir usándolos para servicios heredados.
Michael Hampton
Sí, aunque me gustaría pensar que más de los proveedores de servicios heredados tienen un LDAP viejo y lleno de {crypt}contraseñas en lugar de texto claro (el enfoque adoptado por las que he visto en el pasado). ) Aunque eso podría ser solo una ilusión.
Shane Madden
1
Nota obligatoria de criptografía: "La compensación aquí es que si las contraseñas están codificadas en un sentido en la base de datos del ISP, entonces los únicos protocolos de autenticación que pueden usarse son aquellos que transmiten la contraseña por cable en texto plano. Pero si el ISP almacena la contraseña real, entonces se pueden usar protocolos de autenticación más seguros ". No es generalmente cierto. Solo es cierto porque no hay protocolos existentes que permitan un esquema de autenticación seguro con contraseñas hash.
orlp
1
@nightcracker en comparación con la cantidad de datos que va a transferir (también cifrado, espero) la pequeña cantidad de datos de autenticación realmente no debería molestarle tanto
Tobias Kienzler
12

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.

cuello largo
fuente
28
Es un anfitrión de muy bajo presupuesto ... Sabía que era demasiado bueno para ser verdad. Esto me está jirafando locamente. De todos modos, gracias por sobresalir con una respuesta. Al principio pensé que era una tarea difícil, pero usted estuvo a la altura de las circunstancias. Respuestas como esta ayudan a este sitio a alcanzar nuevas alturas. Estaba pensando en marcar esto como la mejor respuesta, pero es cuello y cuello.
Austin '' Peligro '' Powers
7

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.

Shane Madden
fuente
1
Les haré algunas preguntas y volveré a publicar aquí si dicen algo interesante. Mi mayor preocupación es que podrían potencialmente 1) leer cualquiera de nuestros correos electrónicos 2) al leer nuestros correos electrónicos, ver una referencia a una cuenta de correo electrónico personal 3) si un usuario usa la misma contraseña para el trabajo y el correo electrónico personal, entonces su correo electrónico personal podría estar comprometido también.
Austin '' Peligro '' Powers
@ Austin''Danger''Powers "podría potencialmente 1) leer cualquiera de nuestros correos electrónicos " Cualquier host puede hacer esto, sin excepciones (suponiendo que el remitente no haya cifrado el contenido del correo, pero esa es una historia diferente).
orlp
Pensé que generalmente solo es posible para el soporte de nivel superior. Si ver las contraseñas es algo que cualquiera de sus representantes de soporte puede hacer, entonces aumenta el riesgo de que un empleado deshonesto / aburrido hurgue en nuestros correos electrónicos.
Austin '' Peligro '' Powers
5

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.

oleksii
fuente
1
Una de las razones por las que nuestro último webmaster recomendó este proveedor fue porque se suponía que era "más seguro" que el anterior. Pronto descubrí que no permitirían que ciertos caracteres especiales en las contraseñas que utilizamos para poder utilizar, a continuación, después de que su personal tenía acceso a nuestras contraseñas. La única razón por la que son "más seguros" es porque nos obligan a cumplir con ciertos requisitos mínimos de longitud / complejidad de contraseña, gran cosa.
Austin '' Peligro '' Powers
Todos llaman a su servicio "seguro", pero resulta que no siempre puede significar lo que usted cree que significa. El sistema debería hacerlo imposible. Trabajé para un ISP hace años, y aunque podía restablecer la contraseña de correo electrónico de cualquier cliente, no tenía forma de ver cuál era la actual. En teoría, estos tipos podrían leer nuestros correos electrónicos sin nuestro conocimiento ... No debería tener que confiar en la confianza .
Austin '' Peligro '' Powers
1
¿Aplican un requisito de longitud máxima ? Casi siempre es un canario para el almacenamiento de contraseñas de texto sin formato.
Mels
1
"Buscar en" proveedor de correo electrónico seguro "arroja muchos resultados". - Sí, y cuántos de esos sitios que almacenan contraseñas en texto plano aparecerán bajo esos resultados porque creen que son seguros. No elija el alojamiento para un servicio que desea proteger según algunos resultados de búsqueda.
Rob Moir
1
@RobM: Exactamente. ¿De qué sirve preguntarle al proveedor si cree que su propio servicio es seguro? El 100% de ellos dirá "sí". Hacer una búsqueda en la web de un término genérico como ese es una pérdida total de tiempo. Parece una forma bastante ingenua de abordar el problema en realidad: " ¿Están seguros sus sistemas? Ok, fantástico. Gracias por aclarar eso. En ese caso, nos suscribiremos a sus servicios sin dudarlo "
Austin 'Danger' Powers
3

¡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.

Nicholas Shanks
fuente
Si su segundo párrafo es realmente cierto, eso significaría que la salazón se volvió inútil. ¿Es esta su opinión personal o se basa en hechos?
Tobias Kienzler
@TobiasKienzler De hecho, la salazón utilizando un valor que se almacena en la salida se vuelve bastante inútil, pero la salazón utilizando un valor privado sigue siendo una defensa viable contra los ataques del diccionario. Esta no es mi opinión personal, es una observación (hecha por otros) sobre el comportamiento actual de los descifradores de contraseñas. También actualicé un poco la respuesta.
Nicholas Shanks
2
¿Con valor privado quieres decir pimienta ? De todos modos, las propiedades requeridas de una buena función de hash son a) que son severamente consume mucho tiempo, o incluso mejor b) que pueden ser de cadena-aplicado una gran cantidad arbitraria de veces con el fin de aumentar el tiempo requerido. Entonces, si bien estoy de acuerdo en que un hash / sal obsoleto es crackable, uno con una complejidad suficientemente aumentada no lo es. Relacionado: El hash de contraseña agrega sal + pimienta o ¿es suficiente sal?
Tobias Kienzler
@TobiasKienzler Sí, no estaba seguro de cuán específico podría ser contigo :) Obviamente, los sitios deberían estar usando en bcrypt()estos días, pero se trata más de descifrar los hash de aquellos que no lo hacen.
Nicholas Shanks
1
Bueno, en ese caso estoy de acuerdo, pero un hash malo / obsoleto / débil (por ejemplo, MD5) es simplemente inexcusable en un contexto relevante de seguridad.
Tobias Kienzler
1

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.

Matt Surabian
fuente
0

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 ...;)

Peta Sittek
fuente