Il n'y a pas vraiment de fonctionnalités MySQL intégrées pour gérer des configurations de clés cryptées sophistiquées. Vous devrez implémenter la majeure partie de la logique de cryptage dans votre propre code PHP et/ou côté navigateur (javascript ?).
Mais les préoccupations que vous avez exprimées sont un peu particulières : il semble que votre seule véritable préoccupation soit une injection SQL ou une attaque par force brute (devinette de mot de passe, je suppose) à partir d'un poste de travail client/portable à distance. Cela me fait penser que vous avez déjà prévu d'autres mesures de sécurité, non mentionnées, et que vous avez analysé les voies possibles de compromission.
-
Tout d'abord, je suppose que vous avez des règles de pare-feu qui protègent l'hôte MySQL/PHP contre tout type d'accès à partir d'IP de clients distants non approuvés. Si j'ai raison, il est logique que vous ne vous préoccupiez que des attaques provenant de postes de travail d'utilisateurs compromis.
-
De plus, je suppose que vous comprenez que si un attaquant sur l'hôte du client distant peut accéder aux privilèges root/Admin, ou compromettre directement le compte de l'utilisateur réel, alors les données de ce client ne bénéficient d'aucune protection, indépendamment du cryptage ou de toute autre mesure de protection. (L'attaquant peut lire les clés à partir de l'endroit où elles sont sauvegardées sur le disque, ou les espionner lorsque l'utilisateur réel les saisit lors de l'ouverture de session, et les clés mènent aux données).
En partant de ces deux hypothèses, il est logique de conclure que les deux seules menaces pertinentes sont A) les tentatives de deviner un mot de passe par force brute et B) les tentatives d'injection SQL :
- Si l'attaquant ne parvient pas à obtenir la clé de l'utilisateur réel, ou s'il souhaite accéder à d'autres données que celles de l'utilisateur réel, il peut essayer de forcer brutalement les identifiants de connexion de l'utilisateur réel ou d'un autre compte. (En théorie, vous pourriez verrouiller chaque compte à une IP de client distant spécifique, ce qui contribuerait également à compartimenter les risques).
- Si l'attaquant obtient une clé valide pour l'utilisateur réel, il dispose d'un moyen de passer l'écran de connexion (qui est vraisemblablement assez simple pour être sécurisé), pour atteindre le ventre mou du code de l'application, potentiellement bogué. Une injection SQL réussie à partir du contexte de l'utilisateur réel pourrait également lui permettre d'accéder aux données d'autres clients.
Voyons maintenant comment le chiffrement côté serveur s'applique à ces situations :
- Le chiffrement côté serveur contribue sans aucun doute à la lutte contre la menace de l'injection SQL. Si les valeurs des lignes sont cryptées dans les tables de la base de données, l'attaquant ne peut voir que le texte chiffré des données appartenant à d'autres comptes. La menace est contenue, compartimentée.
- Cependant, la recherche de mots de passe par force brute ne devient pas plus difficile pour un attaquant confronté au chiffrement côté serveur. Que les clés des utilisateurs soient stockées sur le serveur ou générées sur place à partir du mot de passe, la seule chose qui compte est de savoir si vous avez le bon mot de passe. Soit le serveur décide de vous laisser utiliser la clé stockée valide parce qu'il vérifie que votre mot de passe est correct, soit il calcule la clé valide pour vous parce que votre mot de passe est l'entrée correcte pour générer cette clé.
Le cryptage côté client, quant à lui, rend les attaques de mot de passe par force brute inutiles. Il est impossible de forcer une clé correctement construite. Le chiffrement côté client offre également le même niveau de protection contre les injections SQL que le chiffrement côté serveur. Le client peut transmettre la clé au serveur lors de la connexion, en conservant une copie en mémoire jusqu'à la fin de la session, ce qui fait peser la charge du processeur cryptographique sur le serveur. Le client peut également se charger lui-même du cryptage/décryptage, dans le navigateur. Ces deux techniques présentent des avantages et des inconvénients :
- Transmettre sa clé au serveur est beaucoup plus facile à coder et à gérer, et généralement beaucoup plus rapide grâce à un code cryptographique plus optimisé (C compilé, probablement).
- Une approche purement axée sur le client offre une sécurité supplémentaire, car même si un pirate accède à la racine du serveur, il ne peut toujours pas lire les données chiffrées, et il ne pourra jamais le faire. Le seul vecteur d'attaque possible consiste à compromettre le poste de travail du client distant.
Enfin, je tiens à souligner que le cryptage des données dans la base de données présente d'énormes inconvénients sur le plan opérationnel. Comme les représentations des données cryptées sont essentiellement des modèles aléatoires, les fonctions de base des bases de données telles que l'indexation, les jointures, etc. ne fonctionneront pas. Le client assume une charge logique énorme et peut perdre une grande partie des avantages que les fonctions de base de données apportent normalement.
