¿Qué tan seguro es el envío de datos confidenciales a través de https?

Question

¿SSL es lo suficientemente seguro para usar datos confidenciales (como la contraseña) en la cadena de consulta? ¿Hay alguna opción adicional para implementar?

Answer 1

SSL proporciona seguridad segura a nivel de transporte . Nadie entre el cliente y el servidor debería poder leer la información.

Pero debe cambiar de opinión acerca de escribir datos confidenciales en la cadena de consulta . Aparecerá en el historial del navegador y es visible en la barra de direcciones del navegador y en los registros del servidor. Consulte este artículo: Qué tan segura es la consulta Cadenas sobre HTTPS?

Si usar cadenas de consulta es su única opción (lo dudo), aquí hay un artículo interesante sobre cómo asegurar cadenas de consulta .

Answer 2

SSL es seguro, pero recuerde que cualquier cifrado puede romperse si se le da suficiente tiempo y recursos. Dado que no sabe qué paquetes contienen una contraseña y cuáles no, tendría que descifrar todo el tráfico cifrado para encontrar el correcto. Esto es intratable en el caso general.

Sin embargo, un formulario de inicio de sesión necesitará una entrada [type = text] para ingresarlo. Se necesitaría trabajo para desempaquetar esto y convertir la solicitud en una solicitud HTTP GET utilizando cadenas de consulta en lugar de una POST con los datos en los parámetros del formulario. No puedo imaginar por qué alguien haría esto. Una vez que la contraseña ha sido proporcionada por el usuario (y el usuario autenticado), use el hecho de autenticación en lugar de mantener la contraseña. Si necesita mantener la contraseña, para suplantación, por ejemplo, manténgala en el lado del servidor y preferiblemente en una cadena segura. Si está intentando hacer un inicio de sesión único (ingrese mi identificación / contraseña una vez para muchos sitios), luego use algún tipo de servicio de autenticación central (CAS) - OpenID, WindowsLive - o implemente el suyo.

Cuantas menos veces una contraseña cruce el cable, mejor.

Y, siempre hay que considerar la barra de ubicación del navegador que argumentaría que necesita cifrar y codificar cualquier información confidencial que ponga en cadenas de consulta como se mencionó anteriormente.

Answer 3

Los datos confidenciales en la cadena de consulta son una mala idea, los transeúntes casuales pueden ver la cadena de consulta y existe la tentación de marcar que realmente no es seguro.

SSL es bastante seguro, si haces banca por Internet y confías en él, entonces SSL también será lo suficientemente bueno para ti.

Answer 4

de acuerdo con el SSL es seguro * ish y el problema de la cadena de consulta

recuerde que hay limitaciones en SSL -

asegúrese de que el certificado tenga certificación raíz.

algunas máquinas con Windows 2000 necesitan que se aplique un sp para que el ssl de 128 bits funcione, si no está allí, entonces va a 40 bits o carga doenst (si no recuerdo mal)

Algunos firewalls de software como ISA, donde publica el sitio seguro y certifica en su interior, actúan como un hombre en el medio.

Secure to ISA luego Secure to LAN. pero el gran factor aquí es el "entonces" como ISA registrará, el registro es un problema, ya que se puede ver la contraseña en la cadena de consulta y la publicación, lo que significa que cualquiera (administrador) puede ver ...

Por lo tanto, busque algoritmos de hash seguros en su idioma para simplemente cambiar la contraseña.

Answer 5

No hay "suficientemente seguro", la seguridad no es una cosa estática con una propiedad bool que sea falsa o verdadera.

SSL es bueno, pero depende de qué tan segura sea la clave privada en el lado del servidor, cuántos bits tiene la clave, el algoritmo utilizado, qué tan confiables son los certificados utilizados, etc. ...

Pero si usa SSL, al menos todos sus datos transmitidos están encriptados (excepto la IP de destino porque se usa para enrutar su paquete).

Otro punto que debe considerar es: si ingresa su cadena de consulta de contraseña a mano en su navegador, podría terminar en la memoria caché de su navegador local (en un archivo local completamente sin cifrar). Así que mejor usa POST y no GET la mecánica de transferencia.

Si está realmente interesado en la seguridad, le recomiendo que investigue más sobre ese tema, porque la mayoría de las veces el algoritmo no es el punto más débil en seguridad.

Answer 6

Sí, es lo suficientemente seguro. Si bien estoy de acuerdo, generalmente no es una buena idea tener cosas como esa en una cadena de consulta, está bien si no es una cadena de consulta que se mostrará en la barra de direcciones. Si aparece en la barra de direcciones, por razones obvias, pierde un nivel de seguridad (personas que pasan, etc.)

Answer 7

el inspector SSL puede abrir tráficos SSL http: // www.ssl-inspector.com/files/file/SSL%20Inspector%20Appliance%20Product%20Brief%20(2-11).pdf

Answer 8

¡nunca debes enviar nada críticamente sensible usando cadenas de consulta!

Answer 9

¿No debería uno enviar contraseñas hash? - no importa si me equivoco.

SSL es casi la mayor seguridad que puede obtener.

Answer 10

Los certificados autofirmados son certificados SSL creados y firmados por usted mismo. Esto significa que no necesita una autoridad de certificación (CA) de terceros para firmar su certificado, pero significa que los navegadores, de forma predeterminada, emitirán una advertencia al respecto, ya que un certificado autofirmado no puede de manera confiable (su navegador tiene una lista de CA de confianza) verifique que el firmante del certificado sea exactamente lo que dice el certificado.

Considere la situación en la que crea un certificado SSL " en nombre de " cierta compañía de software con sede en Redmond. Ahora, si su servidor HTTP presenta ese certificado, que ha autofirmado, a un cliente, el agente de usuario le advertirá que este certificado puede no ser de quién dice que es. Una autoridad certificadora verificará, mediante documentación, el tipo de árbol muerto real y real, la identidad de la parte que solicita la firma, por lo tanto, es confiable.

Espero que esto ayude.