2010-08-24 29 views
5

Tengo una consulta que puede ser simple/tonta o no :). En otras palabras, no tengo idea si es lo suficientemente justo o una idea completamente tonta. Solo algunos pensamientos libres.Sitio web protegido con contraseña con JavaScript

¿Qué sucede si realizo mi inicio de sesión mediante JavaScript con un pase en él (sí, lo sé), pero el pase será procesado por Secure Hash Algorithm. Por ejemplo:

genero un pase con SHA que se parece a

var = 0xc1059ed8... //etc 

y pegar en el código. También habrá dos funciones. Uno comparará dos valores (dado por mí con el del usuario) y el segundo generará una entrada de usuario sha.

¿Esto podría ser seguro teóricamente o es un patrón horrible y una idea estúpida? ¿JS puede manejarlo?

EDITAR: No quise decir autenticación seria como banca uno. Justo cuando tengo mis fotos y quiero solo unas pocas personas para verlas y el 99,9% de personas en la tierra no pueden verlas :) thx para las respuestas

+3

Podría falsificar el inicio de sesión con ['nc'] (http://linux.die.net/man/1/nc) y algunos gummy bears. Use la autenticación del lado del servidor. –

+0

+1 para los ositos de goma, Josh. @lukas: sí, cualquiera que tenga un conjunto medio aceptable de herramientas para desarrolladores de navegador podría piratear eso. –

+0

En realidad, es una muy buena idea para los sitios donde la autenticación del usuario es solo para el factor frescura, pero no es realmente necesaria, como cuentas bancarias o registros de impuestos. Simplemente almacene la contraseña (simple o hash) localmente y autentíquese contra eso. Para efectos especiales y para que parezca real, introduzca un mensaje superpuesto de tiempo variable que diga "Iniciar sesión" o algo así. – Anurag

Respuesta

9

Disculpe, no hay dados :) La autenticación segura no es posible solo con el Javascript del lado del cliente, porque se podría fingir un resultado de autenticación positivo. Va a siempre necesita una instancia del servidor para autenticarse en contra.

+1

Meh. Supongo que la "autenticación" es imposible, dependiendo de exactamente a qué te refieres. Sin embargo, no es técnicamente imposible lograr lo que describe el afiche. Sin embargo, sería inusual y más difícil que la autenticación normal. Vea la respuesta de amdfan para algunas ideas. – PeterAllenWebb

2

No puedes asegurar tu sitio con Javascript solo. Necesitará alguna forma de autenticar las solicitudes en el servidor.

Porque todo el código de su javascript es claramente visible para todos los consumidores de su sitio. Todo lo que un atacante potencial debería hacer es ver la fuente de su sitio web y pueden omitir el bit de verificación de contraseñas de su javascript y ver el contenido detrás de él.

Debe tener implementada la seguridad en el lado del servidor, punto al final. ASP.NET tiene una forma integrada de hacer esto llamada "Autenticación de formularios". O podría usar variables de Sesión en un script php.

+0

¿Qué tiene que ver ASP.NET? con esto, otro entonces ofrece * un * método de autenticación del lado del servidor? –

+1

ASP.NET tiene muchas formas, pero Formas es la más simple. Se puede hacer con variables de sesión en php también. Estoy muy familiarizado con ASP.NET, así que lo mencioné. – Nate

0

Dado que el hash residirá en la computadora del usuario (en el navegador), diría que es una idea terrible. Será fácil manipularlo.

1

Su fuente JS estará visible de todos modos y cualquiera puede simularla fácilmente. Tiene que hacer una validación del lado del servidor

0

Puede utilizar dicho patrón para ocultar la contraseña sobre un enlace de texto sin formato y evitar https para iniciar sesión, pero no como está.

El problema es que un atacante puede robar la contraseña hash y usarla para iniciar sesión en el servidor, y ella no necesita la contraseña real.

Esto se puede ver frustrado por una respuesta desafiante donde el servidor envía con la página un "sal": un gran número aleatorio mezclado con la contraseña y luego hash, por lo que la respuesta es siempre diferente.

Desafortunadamente, esto tiene el efecto de que el servidor ahora necesita tener contraseñas de texto plano, lo cual es una mala idea (bien, hay algunos trucos al respecto). Por lo tanto, es posible que tengas que enviar un mensaje de sal, escribir la contraseña, mezclar el hash con la sal volviéndola a mezclar y enviarla al servidor. El servidor mezcla el hash almacenado de la contraseña del usuario db con la sal y compara ambos.

Con la seguridad, las cosas se complican muy rápido y en las cosas complicadas las oportunidades acechan a los malos. Una razón más para usar patrones bien probados, algoritmos con un historial probado y bibliotecas que los han implementado cuidadosamente.

Y en cualquier caso, será el servidor que tenga la última palabra quién puede acceder.

0

Sería mejor sin ningún intento de autenticación, al menos así no le daría a nadie la peligrosa ilusión de que algo relacionado con podría ser seguro.

Suponiendo que se trata de una situación de secreto compartido, la autenticación es realmente fácil. Usas un algoritmo de desafío-respuesta bastante simple. Básicamente, el cliente envía un mensaje al servidor diciendo que quiere iniciar sesión. El servidor responde enviando un número al azar. El cliente encripta ese número aleatorio con la contraseña correcta y lo envía de vuelta. El servidor encripta el número aleatorio y compara el resultado con lo que el cliente envió. Si coinciden, la autenticación ha tenido éxito: ha confirmado que el cliente tiene la contraseña correcta.

Las ventajas de esto: en primer lugar, la contraseña en sí nunca se envía por cable de ninguna forma, por lo que un atacante no tiene prácticamente ningún material para intentar descubrir la contraseña. Segundo, dado que el servidor genera un nuevo número aleatorio para cada inicio de sesión, un atacante no puede autenticarse exitosamente reenviando los paquetes que capturó de un inicio de sesión anterior.

Casi cualquier servidor con algún tipo de aspiración a la seguridad ya tendrá algo así como esto integrado. Se trata simplemente de configurar su cliente para que interactúe correctamente con el formulario admitido por el servidor o servidores que le interesan.

2

La respuesta común es que 'no, no se puede hacer cliente de autenticación lado' y para los escenarios convencionales que es correcta, pero puedo pensar en por lo menos dos maneras de hacer que funcione:

  1. Use el hash de contraseña SHA para redirigir a una página HTML estática (0xc1059ed8 ... html). Siempre que el directorio virtual no permita la inclusión de archivos, nadie podrá adivinar el nombre del archivo que desea proteger. Sin embargo, esto se torna realmente rápido.

  2. Utilice una implementación de un algoritmo de cifrado (AES, etc.) en Javascript para descifrar un bloque de texto que compone el contenido real de su página. Realmente solo es práctico para una página de gran valor.

La autenticación del lado del servidor es realmente la mejor, pero es incorrecto decir que el lado del cliente no se puede hacer.

+0

Estoy de acuerdo. Esto no es "imposible". – PeterAllenWebb

Cuestiones relacionadas