Protéger les données utilisateurs

Protéger les données utilisateurs | Med Learning

Leçon 1

L'obfuscation du code source

Pourquoi le code est difficile à protéger

Les données précieuses sont en général protégées en limitant leur accès (mot de passe, chiffrement). Mais le code d'un programme est livré à l'utilisateur pour qu'il puisse l'exécuter : le JavaScript d'un site est téléchargé par chaque navigateur, une application mobile peut être décompilée. Les méthodes de contrôle d'accès ne s'appliquent pas : on peut seulement déguiser le code.

Le même calcul, avant et après obfuscation

// code d'origine : lisible
function prixTTC(prixHT) {
    const tauxTVA = 0.20;
    return prixHT * (1 + tauxTVA);
}

// code obfusqué : même résultat, mais noms vides de sens, constantes en hexadécimal,
// chaîne codée et branche de code mort
var _0x4e=['\x6c\x6f\x67'];function _0x2a(_0x1f){var _0x9c=0x64,_0x3b=0x14;if(_0x1f===-0x2a){return _0x4e[0x0];}return _0x1f*(_0x9c+_0x3b)/_0x9c;}

console.log(prixTTC(100), _0x2a(100));   // 120 120

Tableau: Les techniques d'obfuscation

Technique	Exemple
renommage	`prixTTC` devient `_0x2a`, `tauxTVA` devient `_0x3b`
formes alternatives du code	écrire `0x64` au lieu de `100`, remplacer une fonction par une table de toutes ses valeurs possibles
changer le stockage des données	alterner variables locales et globales, déplacer des valeurs dans des tableaux
randomiser l'agrégation	découper un tableau en un grand nombre de sous-tableaux de tailles aléatoires
chiffrer les chaînes	les textes du programme (messages, URL) sont codés et décodés à l'exécution
interrompre le flux	ajouter du code mort (jamais exécuté) et des branches inutiles qui brouillent le chemin réel
supprimer les données de débogage	enlever les noms de fichiers, numéros de ligne et cartes de source (source maps)
obfusquer l'assembleur	techniques comme le « saut au milieu » (jump-in-the-middle) qui trompent les désassembleurs
renouveler régulièrement	changer de tactique à chaque version pour que l'analyse d'une version ne serve pas pour la suivante

Leçon 2

Les règles de protection des données utilisateurs

Principe	En une phrase	Ce que fait le développeur
licéité, loyauté et transparence	une raison légale de traiter les données, rien de caché, une information claire	une mention d'information sous chaque formulaire, une politique de confidentialité lisible
limitation des finalités	des buts déterminés, explicites et légitimes, pas de réutilisation incompatible sans nouveau consentement	ne pas réutiliser les e-mails de la scolarité pour du marketing
minimisation des données	collecter le minimum nécessaire	une newsletter ne demande qu'un e-mail, pas le téléphone ni l'adresse

Leçon 3

Les droits d'accès des utilisateurs d'une application

Modèle	Qui décide des droits ?	Exemple	Forces et limites
DAC (contrôle d'accès discrétionnaire)	le propriétaire de la ressource	tu partages un document Google Drive avec qui tu veux ; les permissions des fichiers Linux (`chmod`)	souple, mais moins sûr : un programme malveillant lancé par l'utilisateur hérite de tous ses droits

Leçon 4

L'accès sécurisé aux données de l'application

Type	Principe
chiffrement	un algorithme et une clé rendent les données illisibles pour qui n'a pas la clé ; la tokenisation remplace une donnée sensible par un jeton sans valeur (le numéro de carte stocké chez le prestataire de paiement, pas chez toi)
effacement	un logiciel écrase complètement les données sur le support et vérifie qu'elles sont irrécupérables (plus sûr qu'une simple suppression)
masquage	remplacer les informations personnelles par des valeurs masquées ou fictives, pour développer, tester ou former sans exposer les vraies données

Leçon 5

Le chiffrement des données

	Chiffrement symétrique	Chiffrement asymétrique
clés	une seule clé, secrète et partagée, pour chiffrer et déchiffrer	une paire de clés : une clé publique (diffusée) et une clé privée (gardée secrète)

Travaux pratiques

TP fil rouge · Protéger le numéro de CIN

Exercices

Exercice 6.1

Choisis la bonne réponse

1L'obfuscation rend le code…
2Le principe qui impose de collecter le minimum de données est…
3Dans le modèle MAC, les droits sont fixés par…
4Les permissions chmod 640 relèvent du modèle…
5Une fonction de hachage est…
6La taille des blocs d'AES est…
7Pour stocker un mot de passe en PHP, on utilise…
8Un chiffrement dont le résultat garde le format de l'entrée (16 chiffres) est…

0/8 répondues

Exercice 6.2

DAC, MAC ou RBAC ?

Exercice 6.3

Hacher, chiffrer ou masquer ?

L'essentiel du chapitre

À retenir

Obfuscation : code illisible pour l'humain, exécutable par la machine (renommage, code mort, chaînes codées…) ; elle ralentit sans arrêter : aucun secret côté client.
Sept principes : licéité-loyauté-transparence, finalité, minimisation, exactitude, conservation limitée, intégrité-confidentialité, responsabilité.
Authentification (qui es-tu ?) ≠ autorisation (as-tu le droit ?) ; modèles DAC (propriétaire), MAC (autorité et niveaux), RBAC (rôles), ABAC (attributs).
Accès sécurisé : moindre privilège, confiance zéro, MFA, comptes privilégiés temporaires, masquage, tokenisation, effacement, connexion sans mot de passe.
Chiffrement symétrique (une clé secrète, rapide : AES blocs 128 bits, clés 128/192/256) et asymétrique (clé publique + clé privée : RSA) ; hachage à sens unique, taille fixe (SHA-256) ; mots de passe : password_hash.
En PHP : openssl_encrypt en AES-256-GCM, IV aléatoire à chaque fois, clé hors du dossier public.

Pratique	Explication
confiance zéro (zero trust)	ne faire confiance à personne par défaut, même à l'intérieur du réseau : vérifier l'identité et les droits à chaque accès, surveiller les sessions et détecter les comportements anormaux
authentification multifacteur	ajouter au mot de passe un facteur possédé (téléphone, clé de sécurité) ou inhérent (biométrie) ; elle est recommandée en priorité contre le détournement de comptes
éviter les comptes privilégiés au quotidien	l'administrateur utilise un compte normal pour son travail courant et un compte d'administration seulement quand c'est nécessaire ; les droits élevés peuvent être accordés pour une durée limitée (par exemple 30 minutes) puis retirés automatiquement
politique de mots de passe forts	longueur suffisante, mots de passe compromis refusés (chapitre 7)
inscription en libre-service	l'utilisateur crée lui-même son compte (page d'inscription, vérification de l'e-mail, activation), ce qui évite que l'administrateur manipule des mots de passe
connexion sans mot de passe	code à usage unique envoyé par e-mail ou SMS, biométrie, connexion sociale (compte Google, Facebook), et désormais les passkeys ; plus pratique, et plus résistant à l'hameçonnage, au bourrage d'identifiants (credential stuffing) et à la force brute

	Chiffrement	Hachage
sens	réversible avec la clé	irréversible
clé	oui	non
taille du résultat	proportionnelle à la donnée	fixe
usage	protéger la confidentialité d'une donnée qu'on devra relire (numéro de CIN, fichier)	vérifier l'intégrité (un fichier téléchargé n'a pas été modifié), stocker des mots de passe, signatures numériques

Algorithme	Type	Taille de bloc	Taille de clé	À retenir
DES	symétrique, par blocs	64 bits	56 bits	ancien standard (1977), cassable en quelques heures : abandonné
3DES (Triple DES)	symétrique, par blocs	64 bits	3 × 56 = 168 bits (sécurité réelle d'environ 112 bits)	applique DES trois fois : chiffrer, déchiffrer, rechiffrer (EDE) ; retiré par le NIST depuis 2023
AES (Advanced Encryption Standard)	symétrique, par blocs	128 bits (toujours)	128, 192 ou 256 bits	le standard mondial depuis 2001 ; 10, 12 ou 14 tours selon la taille de la clé ; utilisé par HTTPS, le Wi-Fi WPA2/WPA3, BitLocker
Blowfish	symétrique, par blocs	64 bits	32 à 448 bits	conçu en 1993 pour remplacer DES ; base de l'algorithme de hachage de mots de passe bcrypt
Twofish	symétrique, par blocs	128 bits	jusqu'à 256 bits	successeur de Blowfish, finaliste du concours AES ; 16 tours
FPE (chiffrement préservant le format)	symétrique	—	—	le texte chiffré a le même format que le texte clair : un numéro de carte de 16 chiffres donne 16 chiffres ; pratique pour les bases de données bancaires existantes
RSA	asymétrique	—	2048 à 4096 bits	chapitre 7

Les trois états d'une donnée chiffrée

txt

« Rendez-vous à 14 h »  ──chiffrer (clé)──►  « 8f3a91c4e0…b72d »  ──déchiffrer (clé)──►  « Rendez-vous à 14 h »
     texte en clair                              texte chiffré                         texte déchiffré (identique)

Les permissions Linux, un exemple de DAC

txt

-rw-r----- 1 sara formateurs  4096  notes_m108.csv
 │└┬┘└┬┘└┬┘
 │ │  │  └── autres : aucun droit
 │ │  └───── groupe « formateurs » : lecture
 │ └──────── propriétaire « sara » : lecture et écriture
 └────────── type : fichier ordinaire
commande équivalente :  chmod 640 notes_m108.csv   (6 = rw-, 4 = r--, 0 = ---)

masquage.php : afficher sans tout révéler

php

<?php
function masquer(string $valeur, int $visibles = 3): string
{
    $n = mb_strlen($valeur);
    if ($n <= $visibles) {
        return str_repeat('•', $n);
    }
    return str_repeat('•', $n - $visibles) . mb_substr($valeur, -$visibles);
}

function masquerEmail(string $email): string
{
    [$local, $domaine] = explode('@', $email, 2);
    return mb_substr($local, 0, 1) . str_repeat('•', max(mb_strlen($local) - 1, 1)) . '@' . $domaine;
}

echo masquer('AB123456'), "\n";                   // •••••456
echo masquer('0612345678', 2), "\n";              // ••••••••78
echo masquerEmail('sara.alaoui@gmail.com'), "\n"; // s••••••••••@gmail.com

Le moindre privilège appliqué au compte MySQL de l'application

sql

-- un compte dédié à l'application, limité à sa base et aux quatre opérations du CRUD
CREATE USER 'app_stagiaires'@'localhost' IDENTIFIED BY 'Un-Mot-De-Passe-Long-Et-Unique-2026';
GRANT SELECT, INSERT, UPDATE, DELETE ON gestion_stagiaires.* TO 'app_stagiaires'@'localhost';
-- pas de DROP, pas d'ALTER, pas d'accès aux autres bases : une injection SQL fait beaucoup moins de dégâts

Le hachage avec SHA-256

php

<?php
echo hash('sha256', 'Bonjour'), "\n";
// 9172e8eec99f144f72eca9a568759580edadb2cfd154857f07e657569493bc44
echo hash('sha256', 'bonjour'), "\n";
// 2cb4b1431b84ec15d35ed83bb927e27e8967d75f4bcd9cc4b25c8d879ae23e18  (une seule lettre change : tout change)
echo strlen(hash('sha256', str_repeat('x', 100000))), "\n";
// 64 : toujours 64 caractères hexadécimaux (256 bits), quelle que soit la taille de l'entrée

chiffrement.php

php

<?php
// la clé : 32 octets aléatoires (256 bits), générée UNE fois puis stockée hors du dossier public,
// par exemple dans le fichier .env, jamais dans la base de données ni dans Git
// $cle = random_bytes(32);  puis  bin2hex($cle) pour l'enregistrer

function chiffrer(string $clair, string $cle): string
{
    $iv = random_bytes(12);                         // vecteur d'initialisation : NOUVEAU à chaque chiffrement
    $chiffre = openssl_encrypt($clair, 'aes-256-gcm', $cle, OPENSSL_RAW_DATA, $iv, $tag);
    return base64_encode($iv . $tag . $chiffre);    // on stocke tout ensemble (12 + 16 octets + données)
}

function dechiffrer(string $paquet, string $cle): ?string
{
    $brut = base64_decode($paquet, true);
    if ($brut === false || strlen($brut) < 28) {
        return null;
    }
    $iv = substr($brut, 0, 12);
    $tag = substr($brut, 12, 16);
    $chiffre = substr($brut, 28);
    $clair = openssl_decrypt($chiffre, 'aes-256-gcm', $cle, OPENSSL_RAW_DATA, $iv, $tag);
    return $clair === false ? null : $clair;        // false : mauvaise clé ou données modifiées
}

$cle = random_bytes(32);
$p1 = chiffrer('AB123456', $cle);
$p2 = chiffrer('AB123456', $cle);
var_dump($p1 === $p2);                       // bool(false) : le même texte donne un chiffré différent
var_dump(dechiffrer($p1, $cle));             // string(8) "AB123456"
var_dump(dechiffrer($p1, random_bytes(32))); // NULL : mauvaise clé