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

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

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