2010-09-07 72 views
7
  • No quiero usar SSL para encriptar formularios de suscripción e inicio de sesión para un sitio web que estoy construyendo.
    • No tengo dinero para pagar un certificado.
    • Necesito usar enryption con jquery y descifrado con C# en mi sitio web asp.net.

¿Alguien tiene un ejemplo y cómo se seguro a adoptar este método?Encriptar contraseña de usuario con jquery y descifrarla con C#

+17

No seguro en absoluto. ¡Próximo! – leppie

+3

La SSL que es una ** Secure Socket Layer ** nunca debe compararse con la encriptación, es totalmente diferente, SSL protege datos que se transmiten de una entidad a otra, mientras que el cifrado protege la lectura de los datos. – RobertPitt

+1

md4, md5 no es una encriptación – Svisstack

Respuesta

15

Si no está utilizando SSL, entonces no está seguro, pero esa no es la única razón.

SSL protege la comunicación real, mientras que el cifrado protege los datos que se están comunicando. Ni siquiera deberías estar encriptando las contraseñas. Debería estar haciendo un hash endurecido de la información. A hash es una función unidireccional (no se puede revertir), mientras que encryption es una función bidireccional (puede invertirse). el endurecimiento de hash y el uso incluye:

  • iteración en un hash construido para la velocidad, como SHA512 un par de miles de veces o usar algo como BCrypt.
  • Utilice un salt - Algo así como una matriz de 64 bits de revoltijo por usuario, almacenada en la base de datos lo hará
  • cifrar las claves y las sales en la base de datos utilizando una llave en la capa de aplicación - Esto significa que si su base de datos se toma, todavía necesitarían la clave de la capa de aplicación para acceder a la información de hash sin procesar, así como a las sales.

Debe recordar que la seguridad está construida en capas. Al omitir SSL, se saltea una gran parte. Por lo menos, puede usar makecert a create a self-signed certificate. Todo lo que sucederá es que el usuario será advertido al respecto. Un buen certificado SSL puede costar tan poco como $ 12.99 en GoDaddy. Recomiendo obtener uno y también implementar lo anterior.

+3

* "Si se puede acceder a esa información clave, puede despedirse completamente de su seguridad". * Esto solo es válido para el cifrado sincrónico, no para el cifrado asincrónico. Pero el rendimiento del cifrado asincrónico en JavaScript es malo. Si usa un cifrado asíncrono como RSA o cualquier otro Sistema de clave pública, puede publicar su clave de cifrado. Debes mantener en secreto solo la clave de descifrado. – jigfox

+0

@jig - Se eliminó esa parte final. No es tan relevante para el resto de la respuesta en ningún caso. –

+1

bien, sobre el resto tienes toda la razón! – jigfox

0

Al no utilizar SSL que está abriendo su código a la red sniffing ataques. Encriptar en el lado del cliente tampoco servirá de nada.

Lamentablemente, no hay forma segura de evitarlo sin obtener un certificado válido. Este enfoque sería inseguro.

+1

Un certificado autohospedado será igual de seguro, siempre y cuando el DNS no sea pirateado. – tdammers

+0

@tdammers - cierto, pero suponía que OP deseaba esto para un sitio público en lugar de autofirmado. –

+0

Sí, están las molestas advertencias de seguridad del navegador ... si el sitio es lo suficientemente importante como para ser cifrado de esta manera, supongo que quien lo quiera debería pagar el certificado. – tdammers

3

Probablemente no sea seguro en absoluto. SSL realmente es el camino a seguir; Si no puede pagar un certificado, siempre puede hacer el suyo. Obviamente, estos no validarán hasta una de las autoridades raíz de confianza, pero son igual de seguros: la identidad de su sitio web no será confirmada por un tercero de confianza, pero la conexión en sí misma estará cifrada de forma segura.

0

Estoy de acuerdo con las preocupaciones de seguridad de las otras personas, si está empeñado en hacerlo de esta manera, puede intentar emplear una interfaz PKI personalizada.Usted tiene que investigar un poco más profundamente en el código necesario para lograr esto, pero aquí hay un enlace para describir la estructura de clave pública:

Public Key Cryptography

Así que si logra codificar un algoritmo RSA clave pública jquery, debe coincidir con su descifrado de clave privada en C# sin dificultad. Esto no es una recomendación porque esto realmente es solo "seguridad mediante ofuscación" (que no es seguridad en absoluto).

0

Puede cifrar los datos del formulario con Javascript. Esto se puede hacer, vea http://www.movable-type.co.uk/scripts/aes.html. Si los datos se cifran con una clave, entonces deberá almacenar esa clave en el código de JavaScript y también en el código del lado del servidor. Como el código javascript estará en el lado del cliente y la clave será pública, eso no es seguro :). Lo mismo también es válido para el cifrado asimétrico. Diferentes datos pueden ser encriptados con la misma clave y enviados al servidor.

SSL está diseñado para superar los problemas de seguridad en la web, utilizando claves públicas de cifrado y técnicas de encriptación simétrica. El ataque del hombre medio es prevenido. Al usar SSL, puede estar seguro de que sus datos están seguros, no alterados por el camino, y hay una autoridad certificadora de terceros que dice que usted es la persona que dice ser.

Si dice que puedo poner la clave o el código de cifrado en un applet o objeto active-x o flash swf y usar ofuscación para proteger el código, puede ser una forma. Pero, de nuevo, este enfoque está abierto a ataques y no seguro. La ofuscación no garantiza que su clave o algoritmo sea seguro, solo endurece el trabajo del cracker para obtener la clave.

Espero que ayude.

0

Puede usar HMAC para la autenticación. Esto no proporcionaría privacidad, pero un rastreador (alguien que investiga el tráfico de red) no podría obtener las contraseñas ni iniciar sesión haciéndose pasar por un usuario auténtico. Cuando no proporciona privacidad, me refiero a que el rastreador verá todo el contenido transferido, pero no la contraseña.

SSL es, por supuesto, muy seguro, pero una exageración para muchas aplicaciones.

Cuestiones relacionadas