05 noviembre 2006

Programando

El estado natural de un Informático...

Ahora mismo estoy creando una aplicación para el trabajo. Nadie me la ha pedido pero sé que es necesaria. Se trata de una aplición Web para almacenar/consultar los resultados de rendimiento de los componentes hardware que probamos. La combinación es la típica: PHP+MySQL.

En todo programa en donde intervienen permisos y claves hay que solucionar la forma de afrontarlos. Yo lo he hecho de una manera correcta (a mi parecer) pero estaría bien saber cómo lo harían los demás. ¿Cómo haríais...?
  1. Control de sesiones y autenticación de usuarios a lo largo de la sesión
  2. Almacenamiento de la clave de usuario en la base de datos

9 comentarios:

Manu dijo...

La primera es fácil, el control de sesiones la da el propio PHP. El cómo guardar las contraseñas, por ejemplo con MD5, que es un algoritmo relativamente seguro ;)

DraXus dijo...

¿No se usan las 2 a la vez? :-/

Jot dijo...

manu:

1-PHP da soporte para control de sesiones, pero hay muchas otras formas de controlar sesiones. ¿Te suenan las cookies? :-)

2-MD5 no es un algoritmo para cifrar sino para crear compendios. MD5, como SHA-1, es una función hash que sirve, por ejemplo, para firmar. A partir de un texto se crea otro de una longitud determinada que solo se obtiene a partir del inicial. Pero sí, la idea es cifrar la clave en la base de datos. Sabes que para cifrar hace falta una clave. ¿Con qué clave cifrarías la clave? Parece un trabalenguas! :-)

draxus, las dos cosas no van unidas. Puedo tener las claves en la base de datos sin cifrar y llevar un control de la sesión de usuario y viceversa.

Manu dijo...

A ver :P

1) Lo que dices es independiente. De hecho PHP puede manejar las sessiones cómo tu quieras, y generalmente con una cookie. Mírate esto:

http://es2.php.net/manual/es/ref.session.php

2) MD5, efectivamente, asigna a una cadena de texto otra de un tamaño concrecto, pero no la cifra.

Que yo sepa, en pocas aplicaciones se cifra realmente la clave en la base de datos, sino que se hace un hash de la misma. MD5 es, sin duda, el más popular.

Jot dijo...

manu:

1- Correcto, conocía la página. La cosa es decidir si nos fiamos del cliente (cookies) o si lo llevamos todo a través del navegador (URL) y si usamos un identificador de sesión o pasamos del tema. Obviamente depende del ámbito de aplicación y el nivel de seguridad requerido, por lo que yo me decidí por el uso simple y llano de cookies.

2- Nada de acuerdo contigo. Las claves nunca deberían estar en texto plano en la base de datos. Imagina que yo soy el administrador de la base de datos, podría ver todas las claves de todos los usuarios y suplantarlos.

Blaxter dijo...

1- php da la solución, en mi opinión es mejor por cookies por estética mayormente, y porque la seguridad es la misma sea por cookies o por url. El usuario puede modificar sus cookies tan facilmente como modifica su url...

2 - almacenar las pass en claro no es una solución lógicamente. Una solución que uso yo es desde el cliente se codifica (que no encriptar :P) en md5 el md5 de la pass del usuario más una cadena (por ejemplo el nombre de la aplicación, o el nombre de tu perro, o el nombre de tu grupo favorito xD lo que sea!). De ese modo las pass de la BD, no tendría unos md5 normales, sino tendría "algo diferente". Que ¿por qué hacer esto? pues porque existen unas majas bd's con hashes md5 que hacen que el algoritmo de "decodificación" md5 se convierta a un algoritmo de O(1), lo cual no mola nada nada. Otras soluciones? criptografía con clave publica.

Blaxter dijo...

Bueno mejorando lo anterior se podría hacer que la cadena variase en cada sesión y el cliente tuviese que enviar el md5 del md5 de su password más la cadena aleatoria, y en el servidor se codificaría la cadena de la base de datos (que sería el md5 de la pass) más la palabra aleatoria (guardada en la sesión del usuario) y si el md5 de todo ello es el recibido del cliente, autentificación correcta! :)

En este caso estaríamos guardando simplemente el md5 de la pass en la BD, si lo juntamos con lo que he dicho anteriormente (guardar en la bd el md5(md5(pass+cadena_fija)) )tendríamos un sistema que dificulta seriamente obtener la pass en claro dado el contenido de la BD y además imposibilita a un atacante sniffer a obtener una sesión de un usuario (antes si que lo podía conseguir!).

Jot dijo...

blaxter, tu solución al cifrado de claves es interesante y válida (eso al primer golpe, tal vez un experto en criptografía te sacase las cosquillas :-P). Supongo que te preocupa no transmitir desde el cliente al servidor la clave en texto plano, por lo que envías el compendio resultado de aplicar MD5 a la clave más una serie de combinaciones y la almacenarías como clave.

Respecto al control de sesiones estamos de acuerdo, tanto las cookies y como las URL podrían ser suplantadas a menos que usemos un identificador de sesión en el servidor para cada cliente.

Jot dijo...

¿Cómo lo he hecho yo?

1-Con cookies, ya que el ámbito de uso será la empresa y no hay unas necesidades de seguridad críticas en este sentido. Las cookies son fáciles de usar y evita usar variables globales por cada sesión ya que sobrecargaría el servidor.

2-Yo encripto la clave usando como clave la clave con el algortimo AES (cifrado simétrico). Así para cifrar jot usaría como clave de cifrado jot:

AES(texto_a_cifrar,clave) - > AES ("jot","jot")

Para que la clave llegue cifrada o en texto no llano desde el cliente al servidor usaría HTTPS, aunque no lo uso de momento por lo dicho anteriormente, no me preocupa que haya sniffers en mi propia empresa.

Gracias a todos por esta discusión! :-)