Como encriptar el pasword y datos desde una página html ?

[roman]

Permítanme meter mi cuchara para hacer una pregunta.

Supongamos que ciframos la información en el cliente. Si usamos HTTP, la petición seguirá viéndose como:

http://www.midominio.com/miacceso/miservidor.dll?USUARIO=Sd#pL@&CLAVE=[!)%ghT

por decir algo.

Bueno, pero quien esté interceptando la comunicación, ¿qué le impide mandar esa misma petición (así, con los datos encriptados) y usurpar la identidad?

// Saludos

[dec]

Hola,

Creo, Román, que has tocado un punto crucial. Por otro lado, y como siempre puedo estar equivocado, pero, tengo que decir que un "hash" no es lo mismo que el resultado de un "cifrado". Lo primero es irreversible, mientras que lo segundo puede "descifrarse". No es lo mismo, ni mucho menos. Me refiero otra vez a lo que dije arriba: si tú guardas las contraseñas "cifradas" en la base de datos, tú mismo, al menos, podrás descifrarlas, llegado el caso. Pues bien, un "hash" es imposible de descifrar, ¡ni siquiera tú sabrás ni podrás saber la contraseña de tus usuarios! Sólo en este punto ya se ve claramente la diferencia entre un "cifrado" y un "hash". Efectivamente, ambas cosas son "similares" en cierto punto (se obtiene una cadena Y de una cadena X), pero, también distintas (no es posible obtener la cadena "en claro" de un "hash").

[rolandoj]

Hola Roman,

Gracias por intervenir. Tocastes un punto crucial, que yo por simplicidad no mencioné antes; pero, indirectamente si lo hice en algunos comentarios, cuando hablaba de que un algoritmo no debe producir dos veces la misma cadena y de que lo ideal es cifrar todo. Ya que lo planteas, profundicemos:

El caso es que al encriptar, cada vez que yo me conecto debe ir, como parte del encriptado una serie de informaciones complementarias, tales como derivadas del reloj del equipo, de tal forma que no te puedas volver a conectar usando exactamente la misma cadena encriptada, especialmente desde un equipo diferente.

Igualmente, el comando post de http debería tener una sola cadena encriptada; sin ningún nombre de campo de datos involucrado, para dificultar más cualquier descifrado. Igualmente esto aplica para todas las llamadas y los datos que se devuelven; de hecho, es así como yo lo hago cuando trabajo mis propias aplicaciones donde tengo tanto el cliente como el servidor elaborados en Delphi.

Dec:

La interpretación de la palabra "cifrado" no es el problema. Queda claro que ambos la entendemos de manera diferente, y también es clara la interpretación que cada uno hace de la misma; pero, eso es simple forma de decir las cosas, y para ambos es válida. Ese no es el punto; lo importante que hemos terminado discutiendo es sí la información debe o no encriptarse en el cliente antes de enviarse al servidor.

Yo insisto en que debe ser así; de lo contrario, es como un viejo chiste que ví esta semana en el superagente 86. Blindó la puerta de su apartamento para resistir hasta una bomba; pero, dejó la llave debajo del tapete que estaba afuera.

No sirve de nada toda la protección que quieras colocar en el servidor si cualquiera, con más o menos conocimientos, puede averiguar tú clave de usuario simplemente viendo lo que envías al servidor por la red.

Es más, siendo más realistas, toda la seguridad informática no sirve de nada si un usuario acostumbra a digitar su clave delante de otras personas, o si la escribe en algún lado. Por eso he hablado de niveles de seguridad, y por eso dije que quería una seguridad media, esto tampoco es el Pentágono.

Quiero reiterar las gracias por el interés; pero, en últimas, me preocupa que mi verdadero problema, como hacer la encriptación en el cliente?, sigue sin resolverse.

[roman]

Hacer la encriptación en el cliente no creo que tenga problema; bastará buscar algún algoritmo de javascript que lo haga. El problema estaría con las informaciones complementarias. No creo que javascript pueda acceder a ese tipo de información.

Como ya ta ha comentado dec, si se quiere tener algo verdaderamente confiable, entonces la solución ya está hecha y se llama https.

// Saludos

[dec]

Hola,

De todas formas, este asunto me parece muy interesante por lo siguiente. Cuando se dice que "cualquiera puede 'escuchar' lo que uno envía al servidor desde el cliente", ¿qué tan cierto es esto? Quiero decir, ¿cómo podría yo hacer, por ejemplo, para tratar de "escuchar" las peticiones HTTP hacia el ClubDelphi que haga Román, por ejemplo? ¿Es factible? ¿Cualquiera puede hacerlo sin más? No me queda claro nada de esto y por eso me llama la atención, sobre todo, el hecho de que la mayoría de páginas web (no sé porqué será, porqué no usar directamente el protocolo HTTPS) se conforme con el protocolo HTTP... ¿acaso habrá gente "por ahí" escuchando lo que transmitimos y dejamos de transmitir? ¿O depende de si tengo algún "troyano" en mi ordenador o algo similar? En fin, supongo que son demasiadas preguntas.

[roman]

No creo que puedas interceptar la información que yo mando, pero ése no es el problema. El problema es que alguien puede interceptar mi información. Creo que eso lo hacen con los llamados sniffers y no desde cualquier punto podrás colocar uno. Rolando seguramente sabe más de este tema.

Ahora, ¿por qué no se usa normalmente https? Porque, según entiendo, tiene un costo. Para que realmente sea un sitio confiable, necesitas un certificado, y para que ese certificado sea válido, debes registrarlo con algún organismo reconocido como VeriSign, y eso cuesta.

Entonces, si la información que manejas no lo amerita, quizá no vale la pena echarse el gasto. Estos foros, por ejemplo, ¿cuántas personas realmente estarán interesadas en interceptar paquetes? ¿Cuál sería el daño real causado por una intromisión? ¿Valdría la pena el gasto?

// Saludos

[dec]

Hola,

Efectivamente, suponía que por ahí iban los tiros: por el costo de implementar el protocolo "HTTPS". Pero estoy contigo, Román, en que hay que ver hasta qué punto merece la pena el desembolso. Bueno. Ya me queda más claro. Gracias.

[roman]

Empezado por dec

un "hash" no es lo mismo que el resultado de un "cifrado". Lo primero es irreversible, mientras que lo segundo puede "descifrarse".

Totalmente de acuerdo. Pero lo que yo señalaba es que si se manda tal cual el hash, encriptación o como se llame, de los datos, ciertamente el interceptor no sabrá la contraseña plana, pero no la necesitaría pues el servidor no tendría manera de detectar quién le manda el hash.

// Saludos