Enlaces
Esta en:

documentos
Arriba
Bind-9
Bind-8
Ad+bind
Dhcp
Kdephp
Shell
Trucos
Php
Documentos
Cuestiones php
Fedora
Legal
W2000 xp
COMOS
Errores dns

Re: [PHP-ES] Cómo proteger la contraseña cuando no se dispone de SS L

Write haof XML files: Manuel Oterino <manuel.oterino_at_sorase.biz>
Fecha: Tue, 28 Mar 2006 17:33:59 +0200 (CEST)

Hola Satyam/Pablo.

>
> ----- Original Message -----
> From: "Pablo Siciliano" <psiciliano_at_puentenet.com>
> To: "Satyam" <Satyam_at_satyam. com.ar>
> Cc: <php-es_at_lists. php.net>
> Sent: Tuesday, March 28, 2006 3:10 PM
> Subject: Re: [PHP-ES] Cómo proteger la contraseña cuando no se dispone de
> SSL
>
>
>> Hola Satyam,
>>
>> Esta vez pasarlo offlist fue de vago nomas ;)
>>
>> Te soy sincero, veía un problema de fuerza bruta, pero después al tener
>> que escribirlo me di cuenta de que lo estas evitando al hacer el doble
>> MD5: Por mas que alguien consiga una colición de que le permita obtener
>> algo igual a md5(md5(trim($password))+$session_id()), todavía tiene que el
>> segundo md5(). Y no va a poder obtener el password teniendo una colición.
>
> El caso es que para el segundo MD5, el interno, estoy obligado pues eso es
> lo que tengo almacenado en la base de datos. Siguiendo tu notación, lo que
> tengo en la base es: md5(trim($password)) por lo que del lado del servidor
> no puedo sino concatenar el session_id con esa expresion.
>
>

Correcto.

>> Lo que se me ocurrió después es que de lo que te salva SSL y que tu
>> mecanismo no contempla, es la reactuación.
>> Si alguien captura post de un login válido puede reenviar un post igual,
>> session id incluído, y se loguea siempre y cuado la sesión sea válida.
>> Para eso le basta con un buen sniffer y el Paros Proxy ;)
>>
>
> Alguien me hizo notar eso en la lista en ingles y estaba por comentarlo en
> esta lista, pero tu me has ganado.
>
> En realidad, originalmente yo pensé enviar como 'desafío' un aleatorio
> cualquiera. Luego vi que el session_id era bastante aleatorio y largo, cosa
> también importante. El caso es que aunque el servidor le enviara al cliente
> un session_id, nada impide que el cliente responda con un session_id
> inventado en sus headers y el PHP lo acepte y calcule con él. Si el PHP lo
> acepta y genera una session con ese valor o lo rechaza, eso no lo sé y bien
> pudiera depender de la versión de PHP con lo cual el esquema podría
> funcionar o no, pero no habría certeza y sería un potencial agujero de
> seguridad.
>
> El esquema que se me ocurrió entonces es el siguiente.
>
> En el servidor, al enviar al cliente la pagina de login, se genera un
> unique_id con la funcion uniqid(). Este lo almaceno en una variable de
> sesion. El cliente calcula el hash con este valor, no con el de sesion.
> Cuando el servidor recibe la respuesta del login busca el unique_id
> almacenado en la sesion y hace su cálculo con este valor. Si le hubieran
> enviado otro id de sesion, no encontraría el mismo unique_id o, si la sesion
> no existiera, no encontraría ninguno en absoluto. Si el login falla y hay
> que reintentar, se deberá enviar y guardar en la sesión un nuevo unique_id
> aunque se mantuviera el mismo session_id. Si el login tiene exito, se borra
> el unique_id de las variables de sesion.
>

Correcto. Esto ya proporciona un buen nivel de seguridad, pero sigo reiterandome en el
uso de session_regenerate_id( ).

Es similar al planteamiento anterior con un añadido, pero lo hace internamente PHP,
generando un id de sessión distinto entre llamadas. Esto te asegura que si alguien capto
tu id de sessión e intenta llamarte con este, no podrá si se regenero y es distinto a la
primera petición.

>
>> Por tirar algo, se me ocurre que para evitar eso podrías mandar un nro
>> siempre creciente que guardases en tu sesión, y que se incluya en el md5,
>> como se hace en el protocolo tcp/ip. Y el login debería controlar que el
>> nro sea uno que el haya enviado, y no este en la lista de los que ya
>> tuvieron un login exitoso.
>
> el unique_id lograría básicamente lo mismo pues estadísticamente sería único
> para cada intento de login.
>
>> O incluso mas facil, bastaría ( No se si no lo estas haciendo ya), con que
>> tu login validase que esa sesión no este logueada.
>
> Habría tres estados posibles en una sesion:
>
> $_SESSION['desafío'] $_SESSION['user_id'] Estado
> vacío vacío
> Visitante no logueado
> unique_id vacío Usuario
> en proceso de login
> vacío Id de usuario Usuario
> logueado
> unique_id Id de usuario no debería
> ocurrir pues en el mismo script en que se acepta
>
> el login se borra el desafio y se almacena el ID de usuario
>
>
>> Pero eso te puede traer otros dolores de cabeza a la larga, como problemas
>> con los browsers que mantengan los id de sesión aún cuando se cierren (
>> Raro pero a veces pasa), y no hagan log off.
>>
>
> Dado que el estado de 'logueado' se por el proceso que fuera, lo mantengo en
> la sesion, esto no tiene remedio.
>
>
> Gracias
>
> Satyam
>
>>
>> Saludos.
>> Pablo.
>> ----- Original Message -----
>> From: "Satyam" <Satyam_at_satyam.com.ar>
>> To: "Pablo Siciliano" <psiciliano_at_puentenet.com>
>> Sent: Tuesday, March 28, 2006 3:57 AM
>> Subject: Re: [PHP-ES] Cómo proteger la contraseña cuando no se dispone de
>> SSL
>>
>>
>>> Me has escrito offlist, asi que te respondo por la misma via.
>>>
>>> ----- Original Message -----
>>> From: "Pablo Siciliano" <psiciliano_at_puentenet.com>
>>>
>>>
>>>> Hola.
>>>> Hola.
>>>>
>>>> Si, me parece que funcionaría con las salvedades obvias ( Que el
>>>> navegador tenga activado javascript, y que en el servidor tambien se
>>>> haga un trim de los espacios en algún momento) .
>>>
>>> Si el cliente no tiene activado JavaScript puedo optar por no dejarlo
>>> ingresar. Esto será evidente pues el campo contraseña será demasiado
>>> corto, unos pocos caracteres. No puedo dejarlo entrar si la contraseña
>>> no esta encriptada pues eso querría decir que mi servidor debería aceptar
>>> tanto encriptada como no encriptada y eso daría pie a ataques con
>>> contraseñas de diccionario.
>>>
>>>> Yo lo que no se si ganás demasiado encadenando el session_id().
>>>
>>> La idea de concatenarlo con un aleatorio cualquiera, y el session_id es
>>> un aleatorio bastante largo, es dar una variabilidad al valor transmitido
>>> de tal manera que lo que leas al monitorear una transmision una vez no te
>>> sirva para otra.
>>>
>>>> Se me hace que buscar por fuerza bruta una colición de md5($clave) no es
>>>> demasiado distinto de buscar una de md5($clave.$constante) si uno conoce
>>>> $constante, y el orden en el que se encadena (Si no recuerdo mal, ya
>>>> charlamos el tema :)).
>>>
>>> Es que el session_id no es una constante, cambia de sesion a sesion. Eso
>>> hace que si estas monitoreando la transmision, en cada login veas una
>>> transmision distinta. Si no le agregas una parte variable, con
>>> monitorear una transmision, aunque no supieras que es lo que contiene,
>>> sabrias que con enviar la misma informacion, entras. La variabilidad es
>>> importante, hace que el monitoreo de linea sea inutil.
>>>
>>>> Aunque lo mas probable sea que tengas razón, por algo la mayoría de los
>>>> retos de los login de las DB son un modelo parecido.
>>>> Tal vez, si agregases al algoritmo algo aleatorio ( Ej: si se hace en un
>>>> segundo par, se manda md5($clave.$constante), si no
>>>> md5($constante.$clave)), y el server chequea que sea alguno de los dos,
>>>> por lo menos dificultás mas la fuerza bruta. Pero eso es mera
>>>> especulación ...
>>>
>>> Justamente, el session_id (que yo di como un ejemplo de aleatorio, pero
>>> que bien puede ser otro) es basicamente aleatorio. Podría también
>>> generar un unique_id para cada login. Cambiar el orden no sirve de
>>> mucho. El Javascript con el proceso de ocultación se transmite en claro,
>>> con solo leer la pagina se puede leer el Javascript y el include. El
>>> proceso es trasparente, lo unico desconocido es la contraseña en si.
>>>
>>> Saludos
>>>
>>> Satyam
>>>
>>>>
>>>> Saludos.
>>>> Pablo.
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Satyam" <Satyam_at_satyam.com.ar>
>>>> To: "php-es" <php-es_at_lists.php.net>
>>>> Sent: Monday, March 27, 2006 10:41 AM
>>>> Subject: [PHP-ES] Cómo proteger la contraseña cuando no se dispone de
>>>> SSL
>>>>
>>>>
>>>>> Sé que la forma de asegurar un sitio es usar SSL, pero si estás en un
>>>>> host compartido que no dispone de SSL y quieres alguito de seguridad,
>>>>> qué haces?
>>>>>
>>>>> Esto es lo que se me ocurrió. Si alguien le puede dar una mirada y ver
>>>>> si tiene algún agujero, nos vendría bien cuando nos ocurriera algo
>>>>> semejante. Sé que hay un agujero que no he cubierto y ese es la
>>>>> pantalla de cambio de contraseña, no veo forma de protegerla
>>>>>
>>>>> En http://pajhome.org.uk/crypt/md5/md5src.html encontré una versión de
>>>>> JavaScript del algoritmo MD5. Lo contrasté contra la misma función de
>>>>> PHP:
>>>>>
>>>>> <html><head><title>MD5 test</title>
>>>>> <script language="JavaScript" src="includes/md5.js"></script>
>>>>> <script>
>>>>> function enOnLoad() {
>>>>> document.getElementById('prueba').innerHTML = md5_vm_test(); //test
>>>>> provided by the library
>>>>> <?php
>>>>> $valor = rand();
>>>>> ?>
>>>>> document.getElementById('p2').innerHTML = hex_md5('<?=$valor?>');
>>>>> }
>>>>> </script>
>>>>> </head><body onLoad="enOnLoad();">
>>>>> <div id=prueba></div>
>>>>> <div id=p2></div>
>>>>> <div><?=md5($valor)?></div>
>>>>> </body></html>
>>>>>
>>>>> Los resultados de ambas funciones son idénticos (había unos parametros
>>>>> conque jugar y tenía que probar con cuáles funcionaba, pero los valores
>>>>> predeterminados resultaron correctos)
>>>>>
>>>>> Mi idea es que en la pantalla de login, el servidor PHP le envíe,
>>>>> además del form, un valor aleatorio, como podría ser el session_id().
>>>>> Si usara algún otro valor, entonces habría que guardarlo en la sesión
>>>>> para poderlo recuperar después, pero no veo ninguna razón para no usar
>>>>> el session_id().
>>>>>
>>>>> Al hacer click en el botón de submit del form de login, se haría el
>>>>> siguiente proceso:
>>>>>
>>>>> a) calcular el MD5() de la contraseña ingresada, previo haber truncado
>>>>> los espacios en blanco en los extremos. Esto debería producir el mismo
>>>>> valor que el que está almacenado en la base de datos.
>>>>> b) concatenar el valor aleatorio provisto por el servidor con este
>>>>> valor
>>>>> c) calcular el MD5() de esto
>>>>> d) poner este valor en el campo de contraseña original y dejar que siga
>>>>> el submit.
>>>>>
>>>>> Del lado del servidor, cuando se recibe la información de login:
>>>>>
>>>>> a) busca el valor de la contraseña encriptada en al base de datos,
>>>>> basado en el ID de usuario. Este valor es la contraseña ya encriptada
>>>>> con MD5()
>>>>> b) concatenar este valor con el session_id() o el valor aleatorio
>>>>> generado anteriormente
>>>>> c) calcular el MD5() de esto
>>>>> d) comparar con el valor recibido. Si son iguales, se originaron a
>>>>> partir de la misma contraseña.
>>>>>
>>>>>
>>>>> Funcionaría?
>>>>>
>>>>> Satyam
>>>>>
>>>>> --
>>>>> PHP Spanish Localization Talk Mailing List (http://www.php.net/)
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG Free Edition.
>>>>> Version: 7.1.385 / Virus Database: 268.2.6/288 - Release Date:
>>>>> 2006/03/22
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.1.385 / Virus Database: 268.3.2/294 - Release Date: 2006/03/27
>>>
>>>
>>
>> --
>> PHP Spanish Localization Talk Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> --
> PHP Spanish Localization Talk Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Salu2.

Manuel Oterino
Sorase Consultoría, S.L.

-- 
PHP Spanish Localization Talk Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Nearby mar mar 28 2006 - 18:23:19 CEST

Este archivo fue generado por hypermail 2.2.0 : mié nov 07 2007 - 20:55:35 CET


Página Principal
Google

Web
dns.bdat.net

Visita nuestro proveedor:
www.bdat.net

Publicidad:

Impresenteibols:Humor Jazz, música en vivo