![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Hola,
Bueno. En principio sí que pasaría. El servidor, una vez considerado autenticado al usuario, le serviría la página correspondiente al panel de administración. Pero, en realidad no se prevee que desde Snoopy se hiciera algo, sino que, un "script" podría usar Snoopy para averiguar la respuesta del servidor, podría intentar un "ataque por fuerza bruta". Se trata de conseguir los datos del usuario Román. Cuando el "script" recibiera "algo" que no fuera "Autenticación fallida", este guardaría el nombre de usuario y contraseña utilizados, puesto que habría conseguido autenticarse. Luego, quien programase el "script" ya haría uso por su cuenta de esos datos... no sé si me explico. El caso es que, echando un vistazo, no encuentro mucha información en Internet, y, los sistemas que veo que implementan algo así, utilizan la base de datos para guardar el número de intentos de autenticación. Ahora bien, la cuestión es si no hay otra solución a esta (puesto que usar sesiones no da resultado) o si acaso existe otra opción... |
|
#2
|
||||
|
||||
|
Pérmíteme insistir. Ya sé que usas cookies para mantener la autentificación del usuario, pero, al menos en mis caso, que uso sesiones, es imposible que el usuario haga nada en el sistema si no se preserva la sesión, por el simple hecho de que toda página lleva una sentencia así (ejemplo):
Código PHP:
// Saludos |
|
#3
|
||||
|
||||
|
Hola,
Creo que llevas parte de razón al menos, Román, pero, recuerda que no estamos tratando de impedir que se haga algo en el sistema, sino que se pueda acceder al mismo, ¡con los datos del usuario! Se trata de robar las contraseñas, los datos de acceso. Como he dicho arriba, el "script" de Snoopy no trataría de hacer sino eso. El "script" envía el formulario de autenticación, probando con ciertos "login y password". El "script" sabe que, por ejemplo, cuando en la respuesta del servidor se incluya un "Autenticación fallida", no puede dar por buenos el "login y password" conque ha intentado ese acceso. Pero, como puede hacer infinitos más... sigue probando. Entonces, en el momento en que el "script" consigue una respuesta del servidor que no sea "Autenticación fallida", el "script" sabe que el login y la contraseña que acaba de probar garantizan el acceso al sistema. No al "script", el "script" habría terminado su trabajo. Simplemente guardaría esos datos. Ahora, quien programase el "script" diría, Vamos a ver qué hemos pescado hoy. Y, en un archivo, por ejemplo, se encontraría con un mensaje del tipo, "He intentado entrar a esta URL, y, he podido hacerlo con estos datos". Ahora el programador se dirige a la URL (ya no con el "script", sino con un navegador) y usa esos datos para entrar al sistema... Ahora bien. ¿Qué se hace ante esto? Pues, foros como este, utilizan un "contador de intentos de autenticación". Para evitar el "robo de contraseñas" por la "fuerza bruta". Porque el "script", a la que intentara autenticarse un número determinado de veces, se encontraría con un "Alto ahí, amigo, ya no puedes intentarlo más". Y eso evitaría (en buena medida) que nadie se planteara robar las contraseñas de un sitio, pues ya no podría hacer, qué sé yo, miles de intentos en una hora, sino que podría hacer no más de unos cuantos al cabo del día... y así podría tardar años en conseguir una contraseña y usuario válidos. Más o menos ese es el asunto Román. ![]() PD. Usando una base de datos... la cosa es bastante sencilla, como se echará de ver. Yo quisiera evitarlo, porque, no existe una tabla apropiada para tal cosa en Gesbit, de modo que, o bien incluyo una, o bien "encajo" este asunto en una tabla existente... podría preparar un plugin para Gesbit, que se encargara de este asunto, creando la tabla por su cuenta. Pero, considero el asunto lo suficientemente importante como para fuera Gesbit mismo quien diese una solución y no que lo hiciera un plugin. Última edición por dec fecha: 10-03-2009 a las 20:42:25. |
|
#4
|
||||
|
||||
|
Ya, ya. Veo que estaba malentendiendo. Es que estaba comentando en cierta bitácora y no estab poniendo cien por ciento de atención
![]() ¿Has probado ese Snoopy vs tu cuenta del Club? Digo, por curiosidad para saber si el vBulletin resiste. // Saludos |
|
#5
|
||||
|
||||
|
Hola,
Ya lo he visto, ya. ![]() No he probado contra vBulletin, pero, estoy seguro de que resiste, porque, a buen seguro usa la base de datos para este asunto. Ya te digo, Román, en realidad es algo bastante sencillo. El escollo está, básicamente, en "persistir" el contador de intentos de autenticación. Como sé que vBulletin usa la base de datos, estoy seguro de que resistirá también a Snoopy, porque Snoopy no tiene nada que hacer ahí, puede cambiar la sesión de PHP, pero, no puede hacer nada en lo que toca a la base de datos. Igual es que no hay otra forma... usar la base de datos. Dita sea... ![]() |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Como hacer que se vea "Si" en vez de "TRUE" en un DBGrid | lu9eui | C++ Builder | 2 | 07-08-2007 04:03:13 |
| Acceso a Outlook 2003 Reminders y error "Invalid Variant Operation" | saldanaluis | Providers | 2 | 24-05-2007 21:17:58 |
| Implementar una nueva opción para la propiedad "FormStyle" | JM75 | OOP | 3 | 15-02-2007 15:53:44 |
| Implementar "FloodFill" en CLX | salvica | Gráficos | 1 | 07-09-2004 19:52:45 |
|