Seguridad: ¿está bien enviar un nombre de usuario y contraseña a través de HTTP GET?

Question

Somos una organización que ha comprado un sistema que es utilizado por los médicos para ver los resultados de los exámenes de los pacientes (información bastante sensible). Siendo un programador, he pinchado y pinchado con el sistema y encontré que envía el nombre de usuario y la contraseña a través de una solicitud HTTP GET. En el dominio en el que se ejecuta, todas las computadoras están configuradas para eludir el proxy, por lo que la URL con la solicitud no se guardará en algún registro proxy en alguna parte. Pero yo diría que esta es una forma insegura de manejar nombres de usuario y contraseñas de todos modos.

El vendedor argumentará que, como nunca lo solicitamos, será una 'mejora' que requerirá $$$ adicional. (En primer lugar, nunca escribimos las especificaciones para el sistema).

¿Qué tipo de caso podría hacerle a la administración para hacerles sentir que esto no es estándar y que probablemente la única forma en que este sistema sería seguro es a través de HTTPS?

EDIT: Gracias por todas sus respuestas! He planteado el problema con el líder del proyecto, su respuesta fue en la línea de "¿qué es HTTP?". Así que planeo explicárselo todo con más detalle, investigar las implicaciones legales y tratar de plantear el problema con los programadores preguntándoles directamente por qué hicieron ese camino. También intentaré explicar la situación a otros colegas que no tienen ninguna participación directa, pero que pueden influir en el asunto.

Answer 1

Si se trata de datos médicos y usted vive en los Estados Unidos, existe una gran posibilidad de que el acceso esté sujeto a las reglamentaciones de HIPAA, incluidos los requisitos de seguridad. Deberías revisar http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidanceforRemoteUseFinal122806.pdf. Si no vives en los Estados Unidos, sugeriría que aún puedas señalar que HIPAA es relevante para el dominio.

Si su proveedor intenta retrasar con una tarifa adicional, diga "¿Está diciendo que no cumple con las normas gubernamentales pertinentes? Golly, tal vez debería proporcionarnos documentación completa sobre sus estándares de seguridad y privacidad, medidas de seguridad y procedimientos. Porque obviamente si nos golpearan con una multa, vendríamos detrás de usted. "(IANAL y todo eso)

Desde un nivel técnico, sin duda la sugerencia de un rastro etéreo que muestra lo fácil es para buscar nombres de usuarios y las contraseñas deberían ser reveladoras para su administración. Dado lo trivialmente fácil que es olfatear el tráfico de red normal y lo fácil que es usar SSL para el transporte, la idea de un proveedor que presiona como como una "mejora de seguridad" es escandalosa.

Answer 2

Esto no es menos seguro que la autenticación HTTP básica. Solo asegúrese de que el nombre de usuario/contraseña no esté almacenado en caché por los navegadores web del cliente (¿Está en el historial de su navegador?)

Creo que la manera más fácil y económica sería requerir HTTPS para proteger su aplicación web. Si el usuario va a una URL que es HTTP, puede simplemente redirigirlos a la URL equivalente de HTTPS.

Si debe permitir el acceso HTTP sin embargo (y no estoy seguro de por qué ese sería el caso), entonces no es seguro. En su lugar, debe implementar algo como HTTP digest access authentication.

No creo que la mejora de la seguridad sea algo que debería obtener gratis de la persona que hace la codificación. Eso es a menos que el u/p aparezca en el historial del navegador.

Dado que se trata de información de médicos y pacientes, también me parece que el contenido en sí mismo debe estar encriptado, y no solo la autenticación. Entonces, realmente deberías estar usando HTTPS de todos modos.

Answer 3

Esto no es menos seguro que el construido en autenticación HTTP básica.

esto es cierto, a excepción de un punto sutil, que el nombre de usuario contraseña &, dependiendo de cómo está diseñado el sistema, puede aparecer en la barra de direcciones de la ventana del navegador.

Por lo menos, creo que deberían PUBLICAR esa información al servidor.

Answer 4

Una buena manera de hacer su caso es contratar a un gerente relativamente técnico (o brillante) que entenderá si les muestra un rastro etéreo vivo de un inicio de sesión (¡mire! Aquí está la contraseña para el usuario: MrGreen. no me creas, ¡pruébalo tú mismo!).

Solo haga esto sin preguntar primero si confía y conoce al gerente, sino simplemente hable con él sobre esto y si no le cree, pida permiso para mostrarlo. Si no lo otorga, puede señalar esta pregunta u otro recurso en línea. Pero si no les importa, no tienes suerte, diría yo.

Haga el seguimiento en vivo, explique simplemente lo que hizo (cualquiera en nuestra red puede hacer esto, es tan fácil como instalar este programa). Luego explique que es casi gratuito obtener encriptación en el sistema, lo que evitaría eso y que la aplicación apenas tiene que modificarse en lo mínimo. Y que tendría el beneficio de transmitir todo encriptado para que los registros fueran mucho más seguros también.

A continuación, deje que el administrador se encargue de los permisos apropiados/aprobación del presupuesto/lo que sea.

Y la única manera sensata de solucionarlo en general es usar POST (para reparar la contraseña que se envía en las URL) y HTTPS.

Lo que más me preocupa es que las personas que envían contraseñas de texto plano a través de la red probablemente tengan muchos otros defectos de seguridad.

Answer 5

Creo que para su caso debe insistir en https, incluso si se trata de una red "segura".

Esto es similar a http basic (básico lo permite en el encabezado, que es preferible, pero también puede colocarlo en la URL en un formato determinado, consulte rfc2617 para obtener más información).

con SSL/https, el nombre de host estará limpio (obviamente, ya que tiene que encontrar el servidor) pero las otras partes de la URL se deben cifrar de forma segura.

Answer 6

Los nombres de usuario y las contraseñas nunca deben enviarse sin cifrar a través de la red, por lo tanto, insista en HTTPS para al menos la autenticación. Mi preferencia sería que el nombre de usuario/contraseña solo se acepte a través de POST (para que no aparezca en la URL), pero podría cifrar y codificar la contraseña para poder ponerla en una solicitud GET. No puedo imaginar ninguna razón por la que haría esto en lugar de un POST.

[EDITAR] Como han indicado otros, si tiene datos relacionados con el paciente, es posible que deba encriptar todas las comunicaciones con el servidor. Si se encuentra en los EE. UU., Le insto a que consulte las normas HIPAA para ver si aplica alguna aquí con respecto a la seguridad de los datos, especialmente la subsección 164.306 del Privacy Rule (PDF).

Answer 7

Tiene dos problemas aquí, uno técnico, uno contractual (y por lo tanto legal). No pediría consejo legal sobre Stack Overflow.

La respuesta técnica es obvia: estos tipos que hicieron su sistema son payasos, ya que dejaron un gran agujero de seguridad en él.

Legalmente, dependerá del país en el que te encuentres (me doy cuenta de que eres de Brisbane y hola del otro lado del país). Muchos tendrán una legislación médica o de privacidad que puede haber sido violada, así que eso es algo que debemos verificar. Las leyes de HIPAA que otros han sugerido investigar son solo en los Estados Unidos; podemos tener un equivalente en Australia, pero estoy bastante seguro de que las leyes de privacidad aquí en Oz podrían ser compradas.

Del mismo modo, debe revisar el contrato (ya sea que lo haya redactado o no, supongo que usted (o su predecesor) lo firmó, de lo contrario no hay obligación de pagarlo) para ver si la privacidad era un requisito Incluso si no, un abogado competente podría argumentar que se trata de un requisito implícito.

Puede que tenga que absorber y pagar el dinero extra. He trabajado para algunas grandes compañías y ellas tienden a dejar al cliente la responsabilidad por cualquier cosa que no esté incluida en las entregas (esto generalmente está escrito en el contrato). Si su proveedor es competente (en términos de negocio en lugar de satisfacción del cliente, por supuesto), habrán hecho exactamente esto.

Pero primero, póngase en contacto con un abogado para obtener asesoramiento. Son comedores inferiores chupadores de esperma :-), pero son las personas que sabrán qué hacer y están en mejores condiciones para examinar los contratos y aconsejarle sobre las mejores opciones disponibles para usted. Utilicé uno hace unos 10 años para salir de un contrato de automóvil que ya no podía pagar y, aunque costaba varios miles de dólares, era mucho mejor que la alternativa.

A menos que estén frecuentando SO, el consejo que van a obtener aquí está sesgado al lado técnico (mejor caso) o francamente peligroso en un sentido legal (especialmente porque se basará principalmente en la ley de los EE. UU.) Sin querer anunciar para tipos de abogado, sé que puede encontrar uno here.

Lo mejor de la suerte.

Answer 8

¿Este software personalizado o algo utilizado por otros? Si es lo último, considere unirse o iniciar un grupo de usuarios que represente a todos los que usan el software.

Answer 9

Incluso cuando se utiliza SSL, recuerde que cuando los nombres de usuario y las contraseñas se envían usando GET, se incluyen como parte de la URL.

Esto significa que cualquier registro del servidor contendrá los nombres de usuario y las contraseñas como parte del proceso de registro. Por lo tanto, deberá proteger estos registros o, al menos, evitar el registro de la cadena de consulta.