Fondamentalement, toutes les solutions qui te sont proposées ne sont absolument pas sécurisées. À partir du moment où tu as un code exécutable par l’utilisateur, même si l’interface bloque l’exécution il est possible d’exécuter ce code. Point. L’utilisateur peut totalement passer outre ton mot de passe, ta fonction de hachage, etc. Il a accès au code en lecture et c’est tout ce dont il a besoin pour l’exécuter. C’est même absolument trivial pour peu que tu aies laissé les symboles de debug dans ton binaire. Sinon avec un simple debuggeur/desassembleur ça se fera quand même (faut repérer l’instruction qui teste si le hash du pass saisi est conforme et modifier le flag/mémoire/registre à la volée ou désassembler le binaire pour enlever la condition).
De deux choses l’une : dans un cadre pro. Si c’est possible de se contenter de la dissuasion : distribuer deux binaires. L’un pour les utilisateurs finaux, l’autre pour les privilégiés. Les binaires peuvent éventuellement être compilés à partir du même code (via des #ifdef en C par exemple). Si ce n’est pas possible, dans le pire des cas, la "sécurité" passera par des consignes claires de la hiérarchie et une interface parfaitement lisible, qui différentie bien l’utilisation néophyte de l’utilisation avancée. Ce n’est pas une sécurité hard. C’est contournable. Mais dans le cadre d’un contrôle hiérarchique ça peut être suffisant (tout dépend des responsabilités de l’employeur vis-à-vis des employés).
Si tu veux aller plus loin et avoir une vraie politique de sécurité. Il faudra être plus sérieux. Il faut alors interdire la capacité de piloter le matériel par les utilisateurs. Complètement. Et donner le privilège à ton programme et seulement à ton programme.
Dans le monde Unix, par exemple, ce sera du ressort des administrateurs de créer un groupe propre — pas root évidemment ! — qui aura, seul, les droits sur le "fichier" par lequel la couche user (et donc ton programme) communique avec le matos (typiquement ce qui est dans /dev). Ton programme tournera avec le bit setgid correctement positionné pour avoir les droits sur le matos. Il te suffira alors d’un simple fichier stockant le hash, en lecture seule pour le dit groupe, et modifiable par un utilisateur admin (qui peut si distinguer du précédent). Les utilisateurs n’ayant aucun droit en modification sur le programme privilégié, ils ne pourront exécuter que ce qui a été prévu pour eux (à la faille de sécurité près... ton programme exerçant en mode privilégié sur ton matos, il devient plus ou moins sensible et y’a tout un tas de technique de programmation à connaître).
Je te dis en très gros, moi-même n’étant pas expert sécu, mais s’il y a de vrais enjeux derrière il faut impérativement traiter ça de manière beaucoup plus sérieuse et s’aider éventuellement d’un expert. Sinon, deux binaires, voir simple avertissement du logiciel (en gros en gras en rouge) et basta...
[^] # Re: cas d'usage
Posté par greendev . En réponse au message Comment stocker un mot de passe admin d'une application. Évalué à -2.
Fondamentalement, toutes les solutions qui te sont proposées ne sont absolument pas sécurisées. À partir du moment où tu as un code exécutable par l’utilisateur, même si l’interface bloque l’exécution il est possible d’exécuter ce code. Point. L’utilisateur peut totalement passer outre ton mot de passe, ta fonction de hachage, etc. Il a accès au code en lecture et c’est tout ce dont il a besoin pour l’exécuter. C’est même absolument trivial pour peu que tu aies laissé les symboles de debug dans ton binaire. Sinon avec un simple debuggeur/desassembleur ça se fera quand même (faut repérer l’instruction qui teste si le hash du pass saisi est conforme et modifier le flag/mémoire/registre à la volée ou désassembler le binaire pour enlever la condition).
De deux choses l’une : dans un cadre pro. Si c’est possible de se contenter de la dissuasion : distribuer deux binaires. L’un pour les utilisateurs finaux, l’autre pour les privilégiés. Les binaires peuvent éventuellement être compilés à partir du même code (via des #ifdef en C par exemple). Si ce n’est pas possible, dans le pire des cas, la "sécurité" passera par des consignes claires de la hiérarchie et une interface parfaitement lisible, qui différentie bien l’utilisation néophyte de l’utilisation avancée. Ce n’est pas une sécurité hard. C’est contournable. Mais dans le cadre d’un contrôle hiérarchique ça peut être suffisant (tout dépend des responsabilités de l’employeur vis-à-vis des employés).
Si tu veux aller plus loin et avoir une vraie politique de sécurité. Il faudra être plus sérieux. Il faut alors interdire la capacité de piloter le matériel par les utilisateurs. Complètement. Et donner le privilège à ton programme et seulement à ton programme.
Dans le monde Unix, par exemple, ce sera du ressort des administrateurs de créer un groupe propre — pas root évidemment ! — qui aura, seul, les droits sur le "fichier" par lequel la couche user (et donc ton programme) communique avec le matos (typiquement ce qui est dans
/dev). Ton programme tournera avec le bit setgid correctement positionné pour avoir les droits sur le matos. Il te suffira alors d’un simple fichier stockant le hash, en lecture seule pour le dit groupe, et modifiable par un utilisateur admin (qui peut si distinguer du précédent). Les utilisateurs n’ayant aucun droit en modification sur le programme privilégié, ils ne pourront exécuter que ce qui a été prévu pour eux (à la faille de sécurité près... ton programme exerçant en mode privilégié sur ton matos, il devient plus ou moins sensible et y’a tout un tas de technique de programmation à connaître).Je te dis en très gros, moi-même n’étant pas expert sécu, mais s’il y a de vrais enjeux derrière il faut impérativement traiter ça de manière beaucoup plus sérieuse et s’aider éventuellement d’un expert. Sinon, deux binaires, voir simple avertissement du logiciel (en gros en gras en rouge) et basta...