En 1996, Hotmail fut l'un des premiers services web à offrir gratuitement l'accès à un compte de messagerie électronique à partir d'Internet. Son nom original s'écrivait HoTMaiL, en référence aux pages HTML (HyperText Markup Language) et aux courriels (mail).

L'entreprise fut acquise par Microsoft en 1997 et le service fut renommé MSN Hotmail.

En tant que lecteur assidu de Cyberpresse, j'ai remarqué il y a environ 1 mois (probablement depuis la refonte) que certains de leurs fichiers .htaccess étaient accessibles en lecture dans quelques répertoires de leur site :

• Actualité
• Arts
• Dossiers
• Sports
  
• Etc... (toutes les sous-sections dans le domaine www.cyberpresse.ca)
  

C'est quand même une belle opportunité d'étudier les règles particulières et son fonctionnement. Mais est-ce que ça peut représenter un faille de sécurité ? Parfois oui.

Voyons voir combien de temps ça prendra pour être fixé... Si ce n'est pas fait d'ici une semaine, je leur enverrai un courriel. Il faut probablement juste ajouter quelque chose comme ceci dans httpd.conf :


<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>

Dans l'entreprise où je travaille, nous offrons des forfaits d'hébergement dont le prix varie en fonction de l'espace disque utilisé et de la taille de la base de données. La définition du forfait de chaque client est entré dans un outil de gestion qui est lui-même relié à la facturation. Au niveau de la base de données, l'idée était de pouvoir faire le pont entre l'espace disque actuellement occupé et la taille maximale autorisée en utilisant des fonctions système incluses dans PostgreSQL. Lorsque le quota est sur le point d'être atteint, le département de service à la clientèle peut en être informé automatiquement et effectuer un suivi avec le client pour une réévaluation de ses besoins.

Pour obtenir l'espace occupé par une base de données, on peut exécuter la commande SQL suivante :

-- Taille d'une base de données en bytes (bigint : 4472412)
SELECT pg_database_size('database_name') as database_size;

En combinaison avec la fonction pg_size_pretty, on pourra formatter la taille d'un objet de façon plus lisible :

-- Taille d'une base de données en format lisible (texte, avec unité de mesure : 4368 kB)
SELECT pg_size_pretty(pg_database_size('database_name')) as database_size;

Côté pratique, on peut aussi obtenir la taille de d'autres objets de la BD en utilisant pg_relation_size :

-- Espace occupé par une table
SELECT pg_size_pretty(pg_relation_size('public.my_table')) as table_size;

-- Espace occupé par une séquence
SELECT pg_size_pretty(pg_relation_size('public.my_table_pk_seq')) as sequence_size;

Pour tous ces appels, on peut passer comme argument le nom de l'objet ou l'oid (object identifier) puisqu'il y a une surcharge des méthodes à l'interne (overloading).

Lorsque j'étais à mes premières expériences de programmation, j'ai travaillé sur de nombreux projets comportant des sections sécurisées par un nom d'usager et un mot de passe. Les codes d'accès étaient stockés dans une base de données et à ma grande surprise, les mots de passes n'étaient jamais ou très rarement encryptés. Même si parfois le contenu à protéger ne nécessitait pas une confidentialité absolue, je persistais à croire qu'il s'agissait d'une vulnérabilité dans le processus qu'il fallait corriger. D'autre part, le code dynamique des pages web avait été créé à l'aide des wizards de Dreamweaver (horrible!), qui était propice au SQL injection (doublement horrible, même si un correctif est sorti entre temps...). Certaines techniques de SQL injection permettent de contourner les mécanismes de sécurité tandis que d'autres donnent la possibilité d'extraire le nom d'une table, des champs et les données, donc possiblement le nom d'usager et le mot de passe.

Une première approche serait d'encrypter le mot de passe en utilisant un algorithme d'encryption, par exemple MD5 ou SHA1. C'est déjà un premier pas dans la bonne direction. Cependant, si le mot de passe à encrypter était "code 18", le résultat d'hachage (hash value) serait toujours le même :

MD5 : 33165ee9ddbc4cccd441e7bdc08aa606
SHA1 : 965ecafc34288a0db4efe0d1c6cd1c9d2d0c5796

Donc en effectuant une attaque par dictionnaire ou par brute force, c'est possible de réussir à obtenir le hash correspondant au terme utilisé comme mot de passe. C'est d'ailleurs une des raisons pour laquelle on recommande d'y inclure des lettres, des chiffres et des symboles, car le terme ne fera pas parti des tentatives si on est face à un dictionary attack. Pour augmenter la sécurité d'un cran, on pourra y ajouter un "salt".

En cryptographie, un salt est une série de bits qui sont ajoutés au mot de passe pour l'altérer avant qu'il soit encrypté. Ce salt devrait être idéalement aléatoire et différent pour chaque mot de passe. Ceci aura comme avantage que deux mots de passes identiques au départ auront un hash différents à la fin. Voici un exemple qui illustre l'idée du mécanisme d'encryption :

1. Lors de la création d'un compte utilisateur, saisir le nom d'usager (unique) et le mot de passe souhaité (exemple : "code 18").
2. Générer une chaîne de caractères aléatoire d'une longueur d'au moins 8 caractères (par exemple : gxGPx$Bw). Cette chaîne servira de salt.
   
3. Prendre le mot de passe et y concaténer le salt à la fin (mais pourrait être n'importe où). Ici, si le mot de passe est "code 18", la chaîne deviendra "code 18gxGPx$Bw".
   
4. Encrypter la chaîne résultante pour obtenir le hash en utilisant MD5 ou SHA1 (ou tout autre algorithme). En utilisant SHA1, le résultat deviendra : 762c845c682521188c34af97fd06b53de3ea16e9
   
5. Enregistrer dans la base de données le nom d'usager, le salt et le hash (mais pas le mot de passe).

Au moment de l'authentification :

1. L'utilisateur entrera son nom d'usager et son mot de passe original (le salt faisant parti du mécanisme interne, il est transparent à l'usager). Attention, le mot de passe est devenu sensible à la case en raison de l'encryption!
   
2. Prendre le nom d'usager entré et vérifier si un compte existe dans la base de données.
   
3. S'il existe, récupérer le salt et le hash qui correspond à ce compte.
   
4. Concaténer le salt au mot de passe fourni lors de l'authentification.
   
5. Encrypter la chaîne résultante en utilisant le même algorithme d'encryption pour obtenir le hash.
   
6. On autorisera l'accès que si le hash résultant est égal au hash récupéré de la base de données.
   

Un fait intéressant à remarquer est que le mot de passe original n'a jamais été stocké ni été envoyé vers la base de données, ni comparé directement avec ce que l'utilisateur a saisi. De plus, comme on compare les résultats de l'encryption, le mot de passe n'est jamais manipulé directement. Même si on réussissait à intercepter le nom d'usager, le salt et le hash, il sera impossible de faire l'opération inverse pour obtenir le mot de passe. D'ailleurs, si vous utilisez cette technique, je vous conseille de vous souvenir de votre mot de passe, car vous-même ne pourrez le récupérer (un autre mécanisme devra être implémenté pour palier à ce problème, je vous en reparle une autre fois).

Pour créer une base de données PostgreSQL, on peut simplement exécuter la commande SQL suivante :

CREATE DATABASE dbname;

Si le gabarit (template) n'est pas spécifié, PostgreSQL créera la nouvelle base de données en utilisant un clone de la base de données "template1" (base de données système qui n'est pas destinée à faire du développement). Tous les objets se trouvant à l'intérieur de template1 seront copiés dans la nouvelle BD. Autrement dit, il s'agit du modèle par défaut dans lequel on pourra y ajouter les langages, tables, fonctions et types qui sont généralement utilisés dans la modélisation d'un projet (c'est l'équivalent de la BD "model" sous SQL Server).

CREATE DATABASE dbname;
équivaut à :
CREATE DATABASE dbname TEMPLATE template1;

Si on préfère plutôt en créer une à partir d'un modèle vierge (sans objets), on préférera utiliser template0 (autre gabarit système existant lors de l'installation) :

CREATE DATABASE dbname TEMPLATE template0;

On pourra aussi dupliquer une base de données existante, mais attention, aucun utilisateur ne doit être connecté à la source! La copie d'une base de données de travail permettra de dupliquer la structure ainsi que les données.

CREATE DATABASE db_copie TEMPLATE db_source;

Note : L'utilisation des guillemets sera nécessaire si le nom de la base de données contient des caractères spéciaux ou des majuscules.

Ça y est... Au bureau ce matin, les employés ne parlaient que de la sortie de l'expansion de World of Warcraft. Comme je n'ai jamais vraiment été gamer, je ne comprenais pas trop le sens de la discussion, à part que certains magasins ouvraient à minuit pour accomoder les joueurs pressés à acquérir le jeu. Certaines personnes ont même pris congé pour passer leur journée à jouer. Suis-je le seul à avoir un son de cloche ici ? Tout ça pour un jeu ? On n'avait pas vu autant d'engouement depuis Monsieur Patate Optimus Prime...

Tant qu'à parodier, je vous invite à jeter un oeil à un jeu dont je suis accro : First Life, la réplique à Second Life. Faites gaffe, on y prend goût!