contraseña enviada por correo seguro?

Duplicar posibles:
How secure is a HTTP POST?contraseña enviada por correo seguro?

Supongamos que tengo una página de inicio de sesión en php donde se requiere que el usuario introduzca su nombre y contraseña. form method se publica en este caso.

Ahora alguien (mi amigo) me dijo que la información (nombre de usuario y contraseña) que se ingresa y se envía al servidor puede ser pirateada simplemente buscando el encabezado de la página resultante generada. Entonces debe encriptar el encabezado y es por eso que se usa HTTPS.

Esto no tenía sentido para mí porque pensé que la información (nombre de usuario y contraseña) enviada a través del método post es completamente segura y solo por el pirateo de encabezados no se puede acceder al nombre de usuario y la contraseña.

¿Es correcto mi amigo? Si no, ¿hay alguna forma de hacer esas cosas para alguien que no tiene acceso al código? ¿Cómo puedo enviar mi información privada a través de HTTPS (página a codificar en php)?

EDIT:

de datos a través get método se envía a través de cabecera. ¿Derecha? ¿Los datos a través de post también se envían a través del encabezado?

Fuente

2010-07-28 Prasoon Saurav

Tu amigo es correcto :) – Sarfraz

@sAc: Los datos a través de get mthod se envían a través del encabezado. ¿Derecha? ¿Los datos a través de la publicación también se envían a través del encabezado? –

@ user242265: Sí, eso es cierto :) – Sarfraz

Sin SSL, los datos enviados a través de POST son equivalentes a los datos enviados a través de GET, o en otras palabras, no cifrados en absoluto.

Fuente

2010-07-28 14:37:08

No es exactamente equivalente. Si se envía a través de un GET, aún está en texto plano, incluso en una conexión SSL. – JohnFx

Lo siento, quise decir esas dos declaraciones como dos pensamientos separados, voy a editar. –

@JohnFx: Sí, enviar datos a través de GET es una locura: se almacenará en los registros de acceso y en otros lugares. – Piskvor

Su contraseña es no segura si solo la envía con POST, aún visible y sin encriptar, aunque un poco menos obvia.

Enviar una contraseña no cifrada a través de POST es la forma más insegura, pero aún relativamente sana de hacerlo. (Sí, hay formas menos seguras, pero esas son completamente locas: enviar un formulario de contraseña a través de GET es tan seguro como transmitirlo por televisión o imprimirlo en el periódico).

Esto es lo que parece una petición GET típica como:

GET http://somedomain.example.com/path/file?here=are&the=GET&parameters=. 
X-Some-Header: header content 
X-Another-Header: 1

Aquí es una solicitud POST similares (tenga en cuenta que puede enviar ambos parámetros GET y POST en una petición POST):

POST http://somedomain.example.com/path/file?here=are&the=GET&parameters=. 
X-Some-Header: header content 
X-Another-Header: 1 
Content-Length: 40 

with_POST&=the&content=is&here_in=the&request=body

Como puede ver, HTTP es un protocolo de texto completo: no se realiza encriptación en los datos, de modo que cualquier persona puede verlo y/o modificarlo en tránsito. El acceso al código no es necesario en absoluto; simplemente observe el tráfico y sus datos estarán allí, para que todos puedan verlos (puede verificar esto con herramientas como Wireshark, que le permite ver el tráfico de la red).

Para eliminar esta necesidad de confiar en todo el mundo, se creó HTTPS (S para seguro), que proporciona cifrado ("solo el remitente y el receptor pueden leerlo") y autenticación ("el servidor es de verdad yourserver.example .com, y no evilserver.example.net ").

HTTPS es un envoltorio alrededor de HTTP: donde con HTTP, el cliente se conecta al servidor web y comienza la conversación, HTTPS primero establece un túnel SSL seguro, y la comunicación HTTP pasa por eso. Configurar un servidor HTTPS es un poco más complejo que HTTP, ver p. this article.

Fuente

2010-07-28 14:36:38 Piskvor

Los datos a través de 'get' mthod se envían a través de' header'. ¿Derecha? ¿Los datos a través de 'post' también se envían a través de' header'? –

@ user242265: No, y no. Los datos GET se envían en la URL y los datos POST se envían en el cuerpo de la solicitud (no en los encabezados). Edité mi respuesta con un ejemplo. – Piskvor

En el caso de un formulario de inicio de sesión, uso javascript para hash la contraseña antes de enviar el formulario. Hará que sea más difícil llegar a él.

Fuente

2010-07-28 14:38:43 pritaeas

Sin algo de encriptación, esto es mínimamente más seguro que no hacer nada en absoluto. – JohnFx

Estoy de acuerdo con JohnFx. En este caso, el * hash * de la contraseña ahora es la "contraseña". Alguien puede capturar el hash y volver a enviarlo más tarde, lo que le permite el acceso. –

@ Adam Paynter: No si usa un nonce; pero como todo esto está en texto sin formato, el atacante puede simular fácilmente la respuesta inicial del servidor y enviar su propia página falsificada que se envía a otra parte. – Piskvor

De Wikipedia

HTTP no es segura y está sujeta a man-in-the-middle y espionaje ataques que pueden dejar los atacantes ganan acceso a cuentas de redes y información sensible. HTTPS es diseñado para soportar tales ataques y se considera seguro contra tales ataques .

Si le preocupa que alguien intercepte sus datos, use HTTPS.

Fuente

2010-07-28 14:40:30

Aún puede lanzar ataques man-in-the-middle en conexiones SSL. Por ejemplo, si obtengo acceso a la red del host o del cliente, se convierte en una cuestión trivial realizar un ataque de envenenamiento ARP redirigiendo así el tráfico a través de mi computadora y crear un proxy. Por lo tanto, si accede a "https://gmail.com", por ejemplo, mi computadora solicitará ese sitio y lo reenviará a la computadora de destino. Si un usuario es inteligente y vigila el pequeño bloqueo que muestran la mayoría de los navegadores, se daría cuenta de que está firmado por él mismo y no está firmado por Google. No mucha gente nota la mitad de la sesión. –

Cómo funcionaría eso, su proxy no puede pretender ser gmail.com ya que no tiene su clave privada. Este es prácticamente el caso que se supone que SSL debe evitar. – jcoder

@Peter Hanneman: autofirmado -> no en la lista de CA del navegador -> advertencia de "certificado no válido", no "solo un ícono de candado"; OTOH @JB: 1. proxy sirve una página de inicio de sesión de HTTPS gmail falsa 2. navegador arroja una gran advertencia aterradora sobre "certificado inválido" 3. el usuario hace clic en "ok ok sí sí permite ok" sin siquiera leer el diálogo, solo para hacer la advertencia de miedo se va. 4. ¡Ganar! – Piskvor

Creo que el script php que envía el formulario, y el formulario en sí mismo debe estar en un directorio en el servidor web que está configurado con SSL. También debe tener un certificado SSL habilitado para ese sitio web.

Fuente

2010-07-28 14:40:40

pensé que la información (nombre de usuario y contraseña ) enviado a través del método POST se completamente segura

incorrecto. Los datos enviados a través de POST son prácticamente tan inseguros como los enviados a través de GET. La única diferencia (marginal) es que los datos GET son un poco más "accesibles", a través de historiales de URL y tal vez registros. Pero si alguien puede oler el enlace, puede espiar fácilmente a los usuarios y las contraseñas enviadas a través de una solicitud http (POST o GET) a menos que se use SSL (https: //).

Fuente

2010-07-28 14:42:35 leonbloy

Los datos a través de get mthod se envían a través del encabezado. ¿Derecha? ¿Los datos a través de la publicación también se envían a través del encabezado? –

Los datos POST no se envían en el encabezado http. Eso hace cero diferencia en lo que respecta a la seguridad. – leonbloy

puede leer los datos enviados con Wireshark - http://de.wikipedia.org/wiki/Wireshark si envió los datos del formulario sin https.

Fuente

2010-07-28 14:45:09 User123

contraseña enviada por correo seguro?

Respuesta

Cuestiones relacionadas