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

[rolandoj]

Hola,

Tengo el siguiente problema:

Normalmente, uso un cliente en Delphi para conectarme a un DLL ISAPI en Delphi pero, ahora se requiere que parte del cliente esté en HTML. Es un área en que conozco poco; pero son pocas páginas y sencillas así que en principio no es mayor problema excepto por lo siguiente que escapa a mi conocimento:

Como la conexión debe ser "segura", debo encriptar datos en el cliente. Bien entendido, hablo de una seguridad media, que para romperse exija una persona con conocimentos avanzados en software. Ahora bien, eso significa que debo descargar al cliente una pequeña rutina que haga la encriptación. Esa rutina debería llegarle al cliente compilada y ser llamada desde la página html antes de enviar el form.

Por lo que he averiguado, en el OnSubmit de la forma debo llamar la rutina; pero tengo varias dudas. Me disculpan porque las reglas dicen que debo hacer una sola; pero la verdad todo es el mismo tema y creo más lógico condensarlo en un solo hilo :

1. Que lenguajes puedo usar para escribir la rutina?

2. Como se escribiría exactamente la llamada a la rutina ?

3. Como se descargaría la rutina en el cliente ? Para mayor seguridad, debería llegarle compilada; peo, la filosofía en los navegadores Web es de que llegue texto abierto para que pueda ser portable entre sistemas operativos. En mi caso no me interesa esa portabilidad. Los clientes serán siempre Windows. Puedo en realidad descargarla compilada ?

4. Como puedo proteger la rutina en el cliente para minimizar el riesgo de que personal no autorizado pueda ver el código compilado?

[dec]

Hola,

Hasta donde yo llego, este tipo de tareas de autenticación, no deben dejarse nunca en el lado del cliente, sino en el del servidor. El cliente debería poder proporcionarte ciertos datos, como suelen ser un "login" de usuario y una contraseña, y el servidor verá qué respuesta ofrece a eso: o bien considera autenticado al usuario o no. Otra cosa es que puedas transmitir los datos, si hablamos de HTTP, mediante HTTPS, o sea usando una conexión "cifrada" (no sé si es correcto, porque no tengo experiencia), pero, me temo que esto ya es otro tema. Igual es que no he sabido entender lo que planteas. Tú dirás.

[rolandoj]

Empezado por dec

Hola,

Hasta donde yo llego, este tipo de tareas de autenticación, no deben dejarse nunca en el lado del cliente, sino en el del servidor. El cliente debería poder proporcionarte ciertos datos, como suelen ser un "login" de usuario y una contraseña, y el servidor verá qué respuesta ofrece a eso: o bien considera autenticado al usuario o no. Otra cosa es que puedas transmitir los datos, si hablamos de HTTP, mediante HTTPS, o sea usando una conexión "cifrada" (no sé si es correcto, porque no tengo experiencia), pero, me temo que esto ya es otro tema. Igual es que no he sabido entender lo que planteas. Tú dirás.

Hola,

Gracias por contestar.

Sí, quizás no me he explicado bien. Empecemos por aclarar algo en lo que estas malinterpretando mi problema, y lo hago en detalle por mayor claridad de otros que lean el hilo:

Una cosa es la autenticación del usuario; es decir, validar que el usuario exista, que su clave sea la correcta, lo permisos a tener y como vá acceder de ahí en adelante. Eso, como bien dices, queda en el lado del servidor, y por supuesto siempre lo he hecho así. Otra cosa muy diferente es el manejo de como enviar al servidor los datos de autenticación del usuario.

El caso es que esos datos, al menos el password, deben ser enviados encriptados desde el cliente; es decir, en el cliente debe ejecutarse una rutina que reciba los caracteres digitados por el usuario y los encripte, en el cliente, para enviarselos al servidor ya encriptados.

Encriptar es algo en lo que no tengo problemas, ya que con frecuencia escribo algoritmos de encriptación. Mi problema es que con html el paradigma de manejo de esas rutinas es bien diferente a Delphi.

En Delphi tengo un ejecutable propio corriendo en el cliente. Descifrar una rutina de encriptación ubicada dentro de un ejecutable grande, compilado sin ninguna información de depuración y sin siquiera nombres de variables o de la rutina, que den una pista de su ubicación, aunque no imposible, es sumamente dificil ya que requiere conocimientos muy avanzados y tiempo.

En html, el principio es el mismo: Debo encriptar con mis propios algoritmos ejecutandose en el cliente. Sin embargo, hay una gran diferencia: El código que lee el cliente para desplegar la página donde voy a leer los datos se envía como texto, por tanto, abierto a cualquiera con medianos conocimientos. Mi problema es como hago para ubicar mi rutina en el cliente de tal forma que pueda tener una seguridad razonablemente buena.

Para ello, mi idea es que la rutina llegue compilada al Navegador Web del cliente; pero, como lo hago?, y lo más básico, en que lenguaje lo escribo ?

[dec]

Hola,

Pero, yo sigo sin entender porqué es necesario que "cifres" ("encriptes") nada en el cliente. Supón que yo guardo en la base de datos el "hash MD5" de una determinada cadena, que esla contraseña de un usuario. Claro que yo podría enviar al servidor la cadena "cifrada", directamente, pero, ¿para qué voy a hacerlo? Es algo que puedo hacer perfectamente en el servidor. Más aún, todo lo que haga en el cliente quedará "a la vista", pero, en el servidor sólo yo sabré si la contraseña al cabo termina siendo "cifrada" con MD5, con SHA, o con cualquier otro algoritmo que quiera utilizar.

Tú dices:

(...) Otra cosa muy diferente es el manejo de como enviar al servidor los datos de autenticación del usuario.

El caso es que esos datos, al menos el password, deben ser enviados encriptados desde el cliente; es decir, en el cliente debe ejecutarse una rutina que reciba los caracteres digitados por el usuario y los encripte, en el cliente, para enviarselos al servidor ya encriptados.

Pero eso debe ser un requerimiento de tu aplicación (que podrías acaso replantearte). Las aplicaciones a las que yo estoy acostumbrados envían información al servidor "en claro". Podrías acaso querer utilizar algo como "HTTPS", de forma que se estableciera una conexión segura entre tu servidor y un determinado cliente, pero, la contraseña podría seguir enviándose "en claro". En el servidor ya podré hacer yo lo que necesite con esa contraseña que me llega desde el cliente, dicho de otro modo, no tengo necesidad de "cifrar" la contraseña en el cliente, cuando puedo hacerlo en el servidor, y además resulta más seguro, aunque sólo sea porque entonces se tratará de un proceso que no quedará a la vista de nadie.

Ahora bien, mirando un poco para otro lado, es decir, suponiendo que tenemos que trabajar en el cliente, en este caso me parece que no hay otra sino Javascript, tal vez algún "applet" de Java, un "ActiveX", un aplicación "Flash"... cualquiera de estas "tecnologías" te ofrecen la posibilidad de trabajar en el cliente, y en la mayoría de ellas (por no decir en todas) encontrarás disponibles implementaciones de ciertos algoritmos que podrás utilizar para cifrar y descifrar información. No sé si las cosas van por ahí o no...

[rolandoj]

Hola,

Disculpa; pero el método que estás usando es totalmente inseguro y cualquiera, más o menos entrenado puede volarse esa "seguridad". Las aplicaciones que a las que dices estar acostumbrado, están trabajando muy mal esa parte. Si tienes datos importantes, te sugiero reescriban él código de seguridad tan pronto como sea posible

Bajo ninguna circunstancia deberían viajar sin cifrar datos importantes por la red. De hecho, lo lógico es cifrar la totalidad del requerimiento, dificultando aún más la posibilidad de que descifren tú clave de usuario. Eso es precisamente lo que yo hago en Delphi; desde mi cliente, mando encriptado todo el bloque de datos vía "POST". No lo mencioné al principio para no complicar el tema

En el servidor, lo que se maneja, transparentemente para los usuarios finales son dos cosas:

1. El usuario y la clave de conexión a la Base de Datos, la cual, normalmente, es una sola para todos los requerimientos que se reciben. Esa se debe encriptar, como una seguridad adicional, con un programa residente en el servidor que deje esa encriptación en campos del registro de Windows, o en un archivo. Cuando tú aplicación servidor se ejecuta, debe leer esa información y desencriptarla para así poder conectarse a la Base de Datos

2. La autenticación de usuario, es decir, las claves de usuario de la aplicación como tal, no las de conexión a la Base de Datos. Esa información, que es a la que te refieres, se guarda encriptada en una tabla de la Base de datos. Cuando el cliente envía un requerimiento, los datos se cifran primero en el cliente, de forma que viajen ocultos a terceros; el servidor los recibe y los desencripta; luego lee de la tabla de usuario, desencripta la clave guardada en la base de datos y la compara con la que ha recibido.

Vale anotar que de ninguna manera, debería compararse directamente la cadena encriptada en la Base de Datos con la enviada desde el cliente; porque la única forma de que sean iguales es de que el algoritmo genere una encriptación idéntica para una cadena caracteres cada vez que sea invocado. Los algoritmos de ese tipo son los más fáciles de vulnerar y no deberían ser usados.

De no proceder así. cualquiera puede interceptar el comando http que envías y ver cual es tú clave de usuario; para lo cual haya varias técnicas que no creo del caso detallar. De ahí en adelante pueden entrar a cualquier funcionalidad de tú aplicación a la que tengas acceso

Mi problema es de conocimiento como implementar las cosas con página Web; pero, en todo lo demás relativo al tema, si tengo mucha experiencia. De lo que te acabo de explicar estoy totalmente seguro. Es más, casualmente hoy pude romper facilmente la seguridad de una aplicación que estaba usando una persona a la que consulté respecto al problema; y precisamente cometía el mismo error que tú

[dec]

Hola,

Vamos a ver si podemos entendernos. Si de lo que se trata es de que nadie pueda interceptar los datos que un cliente envía a un servidor, efectivamente, se ha de utilizar un protocolo como HTTPS, en lugar de HTTP. Ahora bien, eso que dices de que la aplicación ha de guardar en el servidor una clave cifrada, y recibir una clave cifrada del cliente, que en el servidor se descifran y se comparan ambas claves... eso no es lo normal, lo que yo conozco, lo que puede verse en decenas de aplicaciones.

Lo normal es que una aplicación (en el servidor) no guarde la contraseña cifrada, ni por supuesto "en claro", sino que lo que guarda es un "hash", una "firma" de la contraseña del usuario, que será única para la misma contraseña. De este modo, en el servidor no se conoce, en realidad, la contraseña del usuario: nadie puede conocerla, de hecho, porque no se usa ningún algoritmo de cifrado y descifrado, sino que se usa un algoritmo de "hashing", que retornará una cadena única partiendo de una cadena que sólo el usuario conoce.

¿Nunca te ha pasado que has perdido la contraseña de usuario de un sitio web y el sitio web te ha tenido que mandar una nueva contraseña? Te mandan una nueva contraseña, porque tu contraseña no la conoces sino tú: nadie más la conoce, ni el servidor, ni el cliente, ni nadie. Así que son cosas distintas. Efectivamente, es posible (pero tal vez no probable) que alguien "espíe" una comunicación entre un cliente y un servidor, pero, para evitar esto se puede usar un protocolo como "HTTPS", donde se cifra toda la conexión, no sólo unos determinados datos que viajen en ella.

Pero el mecanismo de autenticación es el mismo. Insisto, no se trata de cifrar y descifrar una contraseña. Se trata de que nadie más que el usuario conoce la contraseña. Tú "juegas" en el servidor con un "hash" de esa contraseña, que ha de coincidir con el "hash" que previamente guardaste. No puedes descifrar nada. No conoces la contraseña, y, si alguien "entrara" en el servidor y accediera a la base de datos, lo único que encontraría serían un puñado de "hash", a partir de los cuales no es posible, al menos en teoría, descubrir la contraseña que hay detrás.

Ahora piensa esto: si existe un mecanismo de cifrado y descifrado, alguien podrá siempre descifrar cierta información, si averigua qué mecanismo de cifrado se utilizó, empero, nadie puede descifrar un "hash": por tanto se evita el cifrado y descifrado, y es el usuario quien únicamente conoce su contraseña. Si se le "pierde", tal como he dicho ya, hay que crear una nueva, por decirlo así, puesto que ni siquiera tú conocerás las contraseñas de tus usuarios. Ahora bien, ¿no te parece esto una mejor solución? Yo creo que sí, pero, es que además es el "sistema" que se utiliza en estos casos.

PD. Ya digo, siempre que estemos hablando de lo mismo, que todavía no me queda muy claro.

PD. Parece claro que el protocolo HTTPS debería usarse cuando se intercambia información "sensible", empero, o me equivoco, o no resulta trivial apoderarse de datos a través de HTTP, así sin más. ¿Por qué digo esto? Bueno, porque el protocolo HTTPS lo utilizan determinados sitios web, pero, estarás conmigo en que otros muchísimos sitios no lo usan. Sin ir más lejos, estos foros no usan el protocolo HTTPS, sino que usan HTTP (y precisamente un sistema similar al que he descrito) para autenticar usuarios. Ahora bien, ¿hay alguien ahí interceptando lo que estoy enviando al ClubDelphi cuando me autentifico? ¿Es posible? Tal vez, pero, según parece, no es tan probable ni tan sencillo.

[rolandoj]

Hola,

Muchas gracias por el interés.

Al igual que tú, tengo la enorme duda de que de pronto no nos estamos entendiendo porque nos estamos refiriendo a ciertas cosas con diferente terminología.

Para empezar, cuando yo hablo de cifrado o encriptación, me refiero a cualquier método con el cual, dado un dato, lo transformo en una cadena de información diferente. En ese sentido, para mi el hash es un cifrado.

Ahora bien, para aclarar lo de la clave de usuario, mejor hagamos un ejemplo:

Supongamos que tengo una página Web donde para conectarme me piden digitar en el formulario un usuario y un password. Digamos que mi usuario es Delphi y mi clave Pedro. Cuando yo uso el botón de Login, el sistema envía un comando POST de http a mi servidor. Si desde el cliente yo no encripto mi clave, asumiendo que mi servidor es un dll, el comando POST que se genera puede ser algo como esto:

Código Delphi [-]
http://www.midominio.com/miacceso/miservidor.dll?USUARIO=Delphi&CLAVE=Pedro

Ese es el texto que vá por http. Cualquiera que lo intercepte puede ver que mi clave es Pedro y mi usuario es Delphi. Sabiendo eso, solo tienen que entrar a la página y digitar exactamente lo mismo. No importa el método que hayas usado en el servidor; por eso te digo que hay encriptar en el cliente; de lo contrario no hay forma de evitar que conozcan tú clave.


Ahora, que se use un protocolo https, que solo se encripte parte de la información, etc, son detalles de estilo, la forma de cifrar lo que se envía. Lo relevante es la necesidad de ocultar de alguna forma, al menos los datos más sensibles que se están enviando, y eso necesariamente debe hacerse en el cliente.

De hecho, la visibilidad de los datos directamente en la Base de Datos es la que a mi menos me preocupa. Por qué ?. Porque para acceder a las tablas de la Base de Datos primero tienen que conseguir un usuario Windows o Unix del servidor que tenga permisos para ejecutar los programas del motor de Base de Datos y acceso al archivo de la misma; luego tiene que conseguir un usuario del motor con acceso a la Base de Datos, lo cual es complicado porque nada de eso llega nunca a los usuarios finales; es exclusivo del servidor. El guardar datos encriptados en las tablas es una medida de elemental prudencia; pero, en la práctica, es muy improbable que alguien extreno pueda llegar directamente a esas tablas vía SQL

[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

[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

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

[rolandoj]

Hola,

Una vez más agradezco a ambos el interés.

Roman, como dije antes; para mi el encriptar no es problema; yo hago mis propios algoritmos de esa índole desde hace mucho tiempo.

Mi problema es de conocimento del manejo con páginas Web, no de lógica de programación. En parte, ya he avanzado en la solución. Según le explicaron a una persona que trabaja conmigo, en el evento onclick de un form se puede invocar una función javascript o una clase java, ubicada en archivo separado, no visible al cliente, que se encarguen de encriptar. En eso hemos estado trabajando en la mañana pero aún no logramos que la instrucción llame a la función; vamos a tratar de contactar de nuevo a quén le dió la información para revisar la sintaxis.

Por otra parte, en cuanto a los sniffers hay un montón de gente que puede tener conocimientos al respecto. Sin ir más lejos, en la clase univeristaria de la persona que trabaja conmigo, el profesor le hizo un ejemplo detallado a todo el curso rompiendo la seguridad de un sistema y mostrando la información que viajaba al servidor. Si eso lo muestran a nivel universitario, es claro que ha demasiada gente que podría hacerlo

Respecto a https, la solución alternativa que yo uso es encriptar todo con mis propios algoritmos en un cliente escrito en Delphi. El nivel de seguridad depende del algoritmo usado y como ustedes lo plantearon depende de que tan seguro requiero una aplicación. Cuando lo hago en Delphi es muy facil; pero, en páginas Web ?

Acerca de si hash te brinda o no más seguridad que otro tipo de algoritmos, vuelvo y repito que no es el punto de la discusión. Hay varias cosas que decir ahí; pero eso es otro tema. Lo que estabamos analizando, que ni siquiera era la razón de mi nota, es si se debe encriptar o no en el cliente.

A ese respecto, vuelvo al ejemplo que puse al principio: El usuario digita su clave Pedro en el cliente; si no se encripta cuando viaje al servidor, se puede interceptar en el camino y de ahí en adelante no importa que tan seguro es lo que se haya hecho en el servidor, la puerta está abierta.

[roman]

Empezado por rolandoj

Según le explicaron a una persona que trabaja conmigo, en el evento onclick de un form se puede invocar una función javascript o una clase java, ubicada en archivo separado, no visible al cliente, que se encarguen de encriptar. En eso hemos estado trabajando en la mañana pero aún no logramos que la instrucción llame a la función; vamos a tratar de contactar de nuevo a quén le dió la información para revisar la sintaxis.

Disculpa, la verdad es que nos hemos ido por las ramas, aunque tampoco quedaba clara cuál era la duda. Por lo que comentas aquí, pienso que lo que estás buscando es el evento OnSubmit del formulario:

<form method='post' action='...' onsubmit='return enviar()'>
  <input type='text' name='user' id='user'>
  <input type='password' name='password' id='password'>
  ...

</form>

La función enviar() sería una función javascript que debe devolver true o false dependiendo de si son o no correctos los datos (si por ejemplo falta uno, devuelves false). En dicha función pueds llamar a tus rutinas de cifrado y aplicarlas a tus campos:

function enviar()
{
  user = document.getElementById('user');
  password = document.getElementById('password');

  user.value = cifrar(user.value);
  password.value = cifrar(password.value);

  return true;
}

Ya sé que no sería exactamente así, pero ya te das la idea. Puedes tener tus rutinas en un archivo externo, digamos cifrado.js que incluyes en tu documento html así:

<script type='text/javascript' src='cifrado.js'></script>

// Saludos

[rolandoj]

Hola Roman,

Muchas gracias. Por ahí sí es lo que estoy buscando. Esencialmente, lo que tú muestras es el código en que estuvimos trabajando esta mañana. En la tarde estuvimos ocupados en otra cosa; pero, mañana en la mañana retomaremos el tema.

Sin embargo, a simple vista, creo que ya sé cual era el error que teníamos esta mañana. Resulta que la función que usabamos en el OnClick la habíamos tomado de un ejemplo errado, o quizás aplicaba para otra cosa, ya que ahí, el resultado que le dabamos a la función era el valor encriptado, viendo tú explicación, me doy cuenta que la función debe devolver es verdadero o falso. Mañana hago ese cambio para ver si ya funciona

Ahora bien, aunque esto es un buen avance para mí, aún hay cosas que me preocupan.

De entrada, ese enfoque basado en javascript, me genera desconfianza porque implica traer al cliente una función que llega en texto (bueno, no sé mucho de javascript; pero entiendo que es un lenguaje interpretado; por tanto lo que llega al cliente es código fuente).

Si estoy en lo cierto, caería en el paradigma general de portabilidad de internet que requiere que las cosas lleguen en texto. Puedo estar equivocado; pero eso me hace creer que sobre html no se puede desarrollar una aplicación segura que a la vez sea portable.

En mi caso, no es algo que me preocupe porque mis clientes son Windows.

La solución que me sugirió mi compañera es usar una clase compilada de Java en lugar de javascript. En principio, ya es una mejora porque según me dijo llega es un compilado al cliente. Podrían confirmarme si eso es cierto ?.

Asumiendo que lo sea, de todas formas me preocupa un poco que la clase llega aislada, en un ambiente en que el nombre de la misma es igualmente identificable en el texto, lo que facilita su aislamiento y análisis.

Para una seguridad mediana, que es lo que necesitó, pienso que sería suficiente; pero, se podría mejorar ?. Ahí si ya no se me ocurre más nada.

[[Delphius]]

Hola,
Sobre desarrollo web no se mucho.
Estuve leyendo este hilo y me resultó interesante el tema. Muy a pesar de que hay cosas que no entiendo.

Hasta el momento me parece que es mejor optar por HTTPS, muy a pesar de que se necesite de cierta inversión en algún certificado. Como bien se ha señalado la pregunta en éste aspecto sería ¿Vale o representa la inversión en que se use HTTPS el nivel de seguridad que mi cliente necesita?

Ahora, por el tema de emplear javascript creo que debes tener dos cosas presente:
1. Algunas personas tienen desactivado o bloqueado el uso de scripts en sus navegadores.
2. Tengo entendido de que si uno ve el código fuente de la página recibe el código script escrito en él. En caso de hacer uso de un archivo externo .js bastaría con que uno hiciera en "guardar página web" para que entre los archivos aparezca guardado el .js y luego lo pueda abrir con un bloc de notas y leerse el "código". (1)

(1) Desconozco si realmente aparece código limpio o es una "compilación" del código. Desconozco en igual medida si es que existen alguna especies de descompiladores de JavaScript. Esto lo digo porque en algunos sitios, cuando yo hacía mis prácticas sobre web notaba que el archivo .js en algunos figuraba código limpio y en otros carácteres sin sentido.

Tal vez se puede habilitar o deshabilitar el guardar página web, o si es posible al menos evitar que se guarde el archivo .js.

¿Necesariamente debe ser html (o php, si vamos al caso)? No se..., muchos dicen que Java es una opción para web... desconozco si es verdad (no se Java) y hasta que punto emplear Java solucione las cosas; o quizá hasta tal vez considerar algo más como .NET. El asunto es ¿No puede "darsele una vuelta" al tema?

Por otro lado, no quiero molestarte pero si dices que estás muy familiarizado con las técnicas de criptografía deberías saber que el término adecuado es cifrar y no encriptar. Y no te enfades pero Hash no puede ni debe catalogarse como un medio más de cifrado. Si bien no es el tema de discusión principal del hilo, en uno de tu post aceptas al hash como una técnica más de cifrado:

Para empezar, cuando yo hablo de cifrado o encriptación, me refiero a cualquier método con el cual, dado un dato, lo transformo en una cadena de información diferente. En ese sentido, para mi el hash es un cifrado.

Disculpame, pero me parece que es mejor llamar a las cosas por su nombre. Evita confusiones y problemas. Recuerda que este hilo puede ser de interés a otras personas y es mejor ser más puntuales y precisos con los términos a fin de que el interesado se informe debidamente y pueda continuar con su investigación de forma adecuada.

Saludos,

[rolandoj]

Hola Delphius,

Muchas gracias por colaborar. Da gusto que más personas se interesen

No me molesta la observación acerca de cifrado, y para tú tranquilidad te comento lo siguiente:

Lo que dices en cuanto a la interpretación de la palabra cifrado, me parece muy válido, si es así como ustedes están manejando el término aquí; pero, creo pertinente explicarte lo siguiente:

Yo soy de la vieja escuela, toda la vida he usado el termino cifrado y encriptación en la forma en que lo mencioné y que conocí en libros que ni siquiera eran de informática.

Si bien no soy profesor de Español, y puede haber algo que no sepa, ese uso está de acuerdo al significado que, según el diccionario, le conozco en español; lo cual incluye,entre otros el de "escritura secreta" e "ininteligible". En ese orden de ideas, el hash si es una técnica de cifrado; otra cosa, es que una comunidad le esté dando una interpretación particular.

Por lo anterior, cuando dices que es mejor llamar las cosas por su nombre, me parece que estás asumiendo como una verdad absoluta la terminología que ustedes están usando. Cuando dices que hash no puede ni debe catalogarse como un medio más de cifrado, estás pasando por alto el significado de la palabra "cifrado" en español; el cual no exige que sea posible "descifrar" lo escrito

Por lo demás, en los otros temas, estoy básicamente de acuerdo; pero hay algunos puntos que ameritan comentarios. Lo haré mañana en la tarde o en la noche