Je souhaiterais pouvoir rappeler automatiquement un mot de passe (accès
à un serveur FTP), comme le font les clients FTP et les navigateurs.
Je ne suis pas vraiment obsédé par la sécurité, néanmoins je ne
voudrais quand même pas que ce mot de passe soit en clair dans un
fichier .ini ou .cfg, ne serait-ce que pour ne pas faire rire ;-)
Disons que je me contenterai d'une sécurité de façade, la possibilité
de saisir le mot de passe à chaque utilisation étant toujours offerte.
Comment puis-je faire au moins mal, uniquement avec les modules
standards et de façon portable ?
Je souhaiterais pouvoir rappeler automatiquement un mot de passe (accès à un serveur FTP), comme le font les clients FTP et les navigateurs. Je ne suis pas vraiment obsédé par la sécurité, néanmoins je ne voudrais quand même pas que ce mot de passe soit en clair dans un fichier .ini ou .cfg, ne serait-ce que pour ne pas faire rire ;-) Disons que je me contenterai d'une sécurité de façade, la possibilité de saisir le mot de passe à chaque utilisation étant toujours offerte. Comment puis-je faire au moins mal, uniquement avec les modules standards et de façon portable ?
Merci d'avance, et bonne soirée ...
-- Pierre Maurette
Je ne sais pas s'il y a de module standard de crypto ... j'utilise pycrypto.
Une façon très simple est de faire du XOR sur tes mots de passe.
hg
Dans la mesure ou le code python est facilement accessible
(même à partir du pyc) je vois mal comment on peut faire des choses sécurisés en python. Même si tu crypte ton mot de passe, il est facile de retrouver dans le code l'endroit ou tu le fais et comment tu le fais.
D'ailleurs du coup je me demande comment les butineurs internet font? C'est sûrement un peu plus compliqué de les casser vu qu'ils sont compilés, mais il doivent avoir le même problème. La sécurité sur internet ne serait elle qu'une vaste fumisterie?
Pierre Maurette wrote:
Bonsoir,
Je souhaiterais pouvoir rappeler automatiquement un mot de passe (accès
à un serveur FTP), comme le font les clients FTP et les navigateurs.
Je ne suis pas vraiment obsédé par la sécurité, néanmoins je ne
voudrais quand même pas que ce mot de passe soit en clair dans un
fichier .ini ou .cfg, ne serait-ce que pour ne pas faire rire ;-)
Disons que je me contenterai d'une sécurité de façade, la possibilité
de saisir le mot de passe à chaque utilisation étant toujours offerte.
Comment puis-je faire au moins mal, uniquement avec les modules
standards et de façon portable ?
Merci d'avance, et bonne soirée ...
--
Pierre Maurette
Je ne sais pas s'il y a de module standard de crypto ... j'utilise pycrypto.
Une façon très simple est de faire du XOR sur tes mots de passe.
hg
Dans la mesure ou le code python est facilement accessible
(même à partir du pyc) je vois mal comment on peut faire des choses sécurisés en python.
Même si tu crypte ton mot de passe, il est facile de retrouver dans le code l'endroit ou tu le fais et comment tu le fais.
D'ailleurs du coup je me demande comment les butineurs internet font?
C'est sûrement un peu plus compliqué de les casser vu qu'ils sont compilés, mais il doivent avoir le même problème.
La sécurité sur internet ne serait elle qu'une vaste fumisterie?
Je souhaiterais pouvoir rappeler automatiquement un mot de passe (accès à un serveur FTP), comme le font les clients FTP et les navigateurs. Je ne suis pas vraiment obsédé par la sécurité, néanmoins je ne voudrais quand même pas que ce mot de passe soit en clair dans un fichier .ini ou .cfg, ne serait-ce que pour ne pas faire rire ;-) Disons que je me contenterai d'une sécurité de façade, la possibilité de saisir le mot de passe à chaque utilisation étant toujours offerte. Comment puis-je faire au moins mal, uniquement avec les modules standards et de façon portable ?
Merci d'avance, et bonne soirée ...
-- Pierre Maurette
Je ne sais pas s'il y a de module standard de crypto ... j'utilise pycrypto.
Une façon très simple est de faire du XOR sur tes mots de passe.
hg
Dans la mesure ou le code python est facilement accessible
(même à partir du pyc) je vois mal comment on peut faire des choses sécurisés en python. Même si tu crypte ton mot de passe, il est facile de retrouver dans le code l'endroit ou tu le fais et comment tu le fais.
D'ailleurs du coup je me demande comment les butineurs internet font? C'est sûrement un peu plus compliqué de les casser vu qu'ils sont compilés, mais il doivent avoir le même problème. La sécurité sur internet ne serait elle qu'une vaste fumisterie?
Laurent Pointal
D'ailleurs du coup je me demande comment les butineurs internet font? C'est sûrement un peu plus compliqué de les casser vu qu'ils sont compilés, mais il doivent avoir le même problème. La sécurité sur internet ne serait elle qu'une vaste fumisterie?
Quand c'est bien fait, le "portefeuille" de mots de passe est protégé par un mot de passe général (ie. on n'en a qu'un à saisir).
D'ailleurs du coup je me demande comment les butineurs internet font?
C'est sûrement un peu plus compliqué de les casser vu qu'ils sont
compilés, mais il doivent avoir le même problème.
La sécurité sur internet ne serait elle qu'une vaste fumisterie?
Quand c'est bien fait, le "portefeuille" de mots de passe est protégé
par un mot de passe général (ie. on n'en a qu'un à saisir).
D'ailleurs du coup je me demande comment les butineurs internet font? C'est sûrement un peu plus compliqué de les casser vu qu'ils sont compilés, mais il doivent avoir le même problème. La sécurité sur internet ne serait elle qu'une vaste fumisterie?
Quand c'est bien fait, le "portefeuille" de mots de passe est protégé par un mot de passe général (ie. on n'en a qu'un à saisir).
Maric Michaud
hg wrote:
Pas si tu utilise in lecteur à gestion de PIN: le PIN ne passe jamais sur la "ligne" entre le lecteur et le PC: aucun debuggeur ne peut choper ça.
Ils ne sont même pas chers: google "omnikey cardman 3621" pour un example.
Je croyais que l'OP avait dit qu'il n'était pas obsédé par la sécurité...
Je crois que le principe général est qu'il est inutile d'espérer qu'un code quelconque exécuté sur une machine sur laquelle l'utilisateur à la main peut lui cacher quoi que ce soit, les obfuscateurs de code et companie c'est du bruits commercial (vous avez vu un jeu qui n'ai pas été craqué, et je peux vous garantir que l'industrie du jeu vidéo aimerait bien avoir une solution).
Donc le truc simple, sans faire appel à du matos sophistiqué, c'est de mettre ce qui est sensible sur des systèmes protégés (et les OS offrent pas mal de solutions pour ça), et de crypter de façon asymétrique (SSL, ssh) tout ce qui passe par le réseau.
J'avais développé avec le binding SSL de python (m2crypto si ma mémoire est bonne) un chalenge-response entre une applet java et un serveur Zope basé sur des clés publique/privées, et la bonne nouvelle, c'est que côté python c'est un jeu d'enfant...
-- Maric Michaud - www.aristote.info
hg wrote:
Pas si tu utilise in lecteur à gestion de PIN: le PIN ne passe jamais sur
la "ligne" entre le lecteur et le PC: aucun debuggeur ne peut choper ça.
Ils ne sont même pas chers: google "omnikey cardman 3621" pour un example.
Je croyais que l'OP avait dit qu'il n'était pas obsédé par la sécurité...
Je crois que le principe général est qu'il est inutile d'espérer qu'un code
quelconque exécuté sur une machine sur laquelle l'utilisateur à la main
peut lui cacher quoi que ce soit, les obfuscateurs de code et companie
c'est du bruits commercial (vous avez vu un jeu qui n'ai pas été craqué, et
je peux vous garantir que l'industrie du jeu vidéo aimerait bien avoir une
solution).
Donc le truc simple, sans faire appel à du matos sophistiqué, c'est de
mettre ce qui est sensible sur des systèmes protégés (et les OS offrent pas
mal de solutions pour ça), et de crypter de façon asymétrique (SSL, ssh)
tout ce qui passe par le réseau.
J'avais développé avec le binding SSL de python (m2crypto si ma mémoire est
bonne) un chalenge-response entre une applet java et un serveur Zope basé
sur des clés publique/privées, et la bonne nouvelle, c'est que côté python
c'est un jeu d'enfant...
Pas si tu utilise in lecteur à gestion de PIN: le PIN ne passe jamais sur la "ligne" entre le lecteur et le PC: aucun debuggeur ne peut choper ça.
Ils ne sont même pas chers: google "omnikey cardman 3621" pour un example.
Je croyais que l'OP avait dit qu'il n'était pas obsédé par la sécurité...
Je crois que le principe général est qu'il est inutile d'espérer qu'un code quelconque exécuté sur une machine sur laquelle l'utilisateur à la main peut lui cacher quoi que ce soit, les obfuscateurs de code et companie c'est du bruits commercial (vous avez vu un jeu qui n'ai pas été craqué, et je peux vous garantir que l'industrie du jeu vidéo aimerait bien avoir une solution).
Donc le truc simple, sans faire appel à du matos sophistiqué, c'est de mettre ce qui est sensible sur des systèmes protégés (et les OS offrent pas mal de solutions pour ça), et de crypter de façon asymétrique (SSL, ssh) tout ce qui passe par le réseau.
J'avais développé avec le binding SSL de python (m2crypto si ma mémoire est bonne) un chalenge-response entre une applet java et un serveur Zope basé sur des clés publique/privées, et la bonne nouvelle, c'est que côté python c'est un jeu d'enfant...
-- Maric Michaud - www.aristote.info
elGringo
On 13 avr, 17:32, Maric Michaud wrote:
hg wrote:
Pas si tu utilise in lecteur à gestion de PIN: le PIN ne passe jamais sur la "ligne" entre le lecteur et le PC: aucun debuggeur ne peut choper ça.
Ils ne sont même pas chers: google "omnikey cardman 3621" pour un exa mple.
Je croyais que l'OP avait dit qu'il n'était pas obsédé par la séc urité...
Je crois que le principe général est qu'il est inutile d'espérer qu 'un code quelconque exécuté sur une machine sur laquelle l'utilisateur à la main peut lui cacher quoi que ce soit, les obfuscateurs de code et companie c'est du bruits commercial (vous avez vu un jeu qui n'ai pas été craq ué, et je peux vous garantir que l'industrie du jeu vidéo aimerait bien avoir une solution).
Donc le truc simple, sans faire appel à du matos sophistiqué, c'est de mettre ce qui est sensible sur des systèmes protégés (et les OS off rent pas mal de solutions pour ça), et de crypter de façon asymétrique (SSL, ssh) tout ce qui passe par le réseau.
J'avais développé avec le binding SSL de python (m2crypto si ma mém oire est bonne) un chalenge-response entre une applet java et un serveur Zope bas é sur des clés publique/privées, et la bonne nouvelle, c'est que côt é python c'est un jeu d'enfant...
-- Maric Michaud -www.aristote.info
Le besoin n'est pas içi la sécurité à toutes epreuves mais juste "u ne sécurité de façade". Une proposition: encoder le mot de passe en base64, le mettre en info dans un fichier zip renommé avec une extension bidon. Cela devrait suffire à detourner l'interêt de l'utilisateur lambda.
On 13 avr, 17:32, Maric Michaud <m...@aristote.info> wrote:
hg wrote:
Pas si tu utilise in lecteur à gestion de PIN: le PIN ne passe jamais sur
la "ligne" entre le lecteur et le PC: aucun debuggeur ne peut choper ça.
Ils ne sont même pas chers: google "omnikey cardman 3621" pour un exa mple.
Je croyais que l'OP avait dit qu'il n'était pas obsédé par la séc urité...
Je crois que le principe général est qu'il est inutile d'espérer qu 'un code
quelconque exécuté sur une machine sur laquelle l'utilisateur à la main
peut lui cacher quoi que ce soit, les obfuscateurs de code et companie
c'est du bruits commercial (vous avez vu un jeu qui n'ai pas été craq ué, et
je peux vous garantir que l'industrie du jeu vidéo aimerait bien avoir une
solution).
Donc le truc simple, sans faire appel à du matos sophistiqué, c'est de
mettre ce qui est sensible sur des systèmes protégés (et les OS off rent pas
mal de solutions pour ça), et de crypter de façon asymétrique (SSL, ssh)
tout ce qui passe par le réseau.
J'avais développé avec le binding SSL de python (m2crypto si ma mém oire est
bonne) un chalenge-response entre une applet java et un serveur Zope bas é
sur des clés publique/privées, et la bonne nouvelle, c'est que côt é python
c'est un jeu d'enfant...
--
Maric Michaud -www.aristote.info
Le besoin n'est pas içi la sécurité à toutes epreuves mais juste "u ne
sécurité de façade".
Une proposition: encoder le mot de passe en base64, le mettre en info
dans un fichier zip renommé avec une extension bidon. Cela devrait
suffire à detourner l'interêt de l'utilisateur lambda.
Pas si tu utilise in lecteur à gestion de PIN: le PIN ne passe jamais sur la "ligne" entre le lecteur et le PC: aucun debuggeur ne peut choper ça.
Ils ne sont même pas chers: google "omnikey cardman 3621" pour un exa mple.
Je croyais que l'OP avait dit qu'il n'était pas obsédé par la séc urité...
Je crois que le principe général est qu'il est inutile d'espérer qu 'un code quelconque exécuté sur une machine sur laquelle l'utilisateur à la main peut lui cacher quoi que ce soit, les obfuscateurs de code et companie c'est du bruits commercial (vous avez vu un jeu qui n'ai pas été craq ué, et je peux vous garantir que l'industrie du jeu vidéo aimerait bien avoir une solution).
Donc le truc simple, sans faire appel à du matos sophistiqué, c'est de mettre ce qui est sensible sur des systèmes protégés (et les OS off rent pas mal de solutions pour ça), et de crypter de façon asymétrique (SSL, ssh) tout ce qui passe par le réseau.
J'avais développé avec le binding SSL de python (m2crypto si ma mém oire est bonne) un chalenge-response entre une applet java et un serveur Zope bas é sur des clés publique/privées, et la bonne nouvelle, c'est que côt é python c'est un jeu d'enfant...
-- Maric Michaud -www.aristote.info
Le besoin n'est pas içi la sécurité à toutes epreuves mais juste "u ne sécurité de façade". Une proposition: encoder le mot de passe en base64, le mettre en info dans un fichier zip renommé avec une extension bidon. Cela devrait suffire à detourner l'interêt de l'utilisateur lambda.
Pierre Maurette
[...]
Le besoin n'est pas içi la sécurité à toutes epreuves mais juste "une sécurité de façade". Une proposition: encoder le mot de passe en base64, le mettre en info dans un fichier zip renommé avec une extension bidon. Cela devrait suffire à detourner l'interêt de l'utilisateur lambda.
Je ne souhaitais même pas détourner l'intérêt de qui que ce soit. Mon souci était purement cosmétique et se limitait à ne pas faire apparaitre en clair mon password dans un fichier éditable. Le problème est résolu depuis mon dernier message. J'avais piqué du code ici: <URL:http://wikipython.flibuste.net/moin.py/CodesDivers#head-95e329786d52ee11858485c2d32994123efeaa64> Je l'ai modifié pour le fun en une seule fonction:
def __1(self,_1,_2,_3,_4=0,_5=''): for _6 in _1:_5+=chr((_3(ord(_6),ord(_2[_4])))%256);_4=(_4+1)%len(_2) return _5
Précaution strictement inutile, il suffit de récupérer le code d'appel:
J'aurais fait un XOR à partir d'un bout de chaîne, c'était encore plus simple, j'appelais la même fonction.
De toutes façons, il n'y a aucune "protection" de quoi que ce soit. D'ailleurs, l'utilisateur peut très bien entrer 'localhost' dans le champ 'serveur' ;-)
Il n'y a dans ce contexte aucune sécurité possible, en tous cas sur un poste de travail "confortable". Si l'utilisateur doit saisir une clé pour valider le password, autant ne pas sauver ce dernier. Ma machine principale sous XP Pro x64 boote sans login, si je disparais inopinément, ou si quelqu'un s'assoit à ma place pendant que je pisse, il n'y a pas de sécurité.
-- Pierre Maurette
[...]
Le besoin n'est pas içi la sécurité à toutes epreuves mais juste "une
sécurité de façade".
Une proposition: encoder le mot de passe en base64, le mettre en info
dans un fichier zip renommé avec une extension bidon. Cela devrait
suffire à detourner l'interêt de l'utilisateur lambda.
Je ne souhaitais même pas détourner l'intérêt de qui que ce soit. Mon
souci était purement cosmétique et se limitait à ne pas faire
apparaitre en clair mon password dans un fichier éditable. Le problème
est résolu depuis mon dernier message. J'avais piqué du code ici:
<URL:http://wikipython.flibuste.net/moin.py/CodesDivers#head-95e329786d52ee11858485c2d32994123efeaa64>
Je l'ai modifié pour le fun en une seule fonction:
def __1(self,_1,_2,_3,_4=0,_5=''):
for _6 in
_1:_5+=chr((_3(ord(_6),ord(_2[_4])))%256);_4=(_4+1)%len(_2)
return _5
Précaution strictement inutile, il suffit de récupérer le code d'appel:
J'aurais fait un XOR à partir d'un bout de chaîne, c'était encore plus
simple, j'appelais la même fonction.
De toutes façons, il n'y a aucune "protection" de quoi que ce soit.
D'ailleurs, l'utilisateur peut très bien entrer 'localhost' dans le
champ 'serveur' ;-)
Il n'y a dans ce contexte aucune sécurité possible, en tous cas sur un
poste de travail "confortable". Si l'utilisateur doit saisir une clé
pour valider le password, autant ne pas sauver ce dernier. Ma machine
principale sous XP Pro x64 boote sans login, si je disparais
inopinément, ou si quelqu'un s'assoit à ma place pendant que je pisse,
il n'y a pas de sécurité.
Le besoin n'est pas içi la sécurité à toutes epreuves mais juste "une sécurité de façade". Une proposition: encoder le mot de passe en base64, le mettre en info dans un fichier zip renommé avec une extension bidon. Cela devrait suffire à detourner l'interêt de l'utilisateur lambda.
Je ne souhaitais même pas détourner l'intérêt de qui que ce soit. Mon souci était purement cosmétique et se limitait à ne pas faire apparaitre en clair mon password dans un fichier éditable. Le problème est résolu depuis mon dernier message. J'avais piqué du code ici: <URL:http://wikipython.flibuste.net/moin.py/CodesDivers#head-95e329786d52ee11858485c2d32994123efeaa64> Je l'ai modifié pour le fun en une seule fonction:
def __1(self,_1,_2,_3,_4=0,_5=''): for _6 in _1:_5+=chr((_3(ord(_6),ord(_2[_4])))%256);_4=(_4+1)%len(_2) return _5
Précaution strictement inutile, il suffit de récupérer le code d'appel:
J'aurais fait un XOR à partir d'un bout de chaîne, c'était encore plus simple, j'appelais la même fonction.
De toutes façons, il n'y a aucune "protection" de quoi que ce soit. D'ailleurs, l'utilisateur peut très bien entrer 'localhost' dans le champ 'serveur' ;-)
Il n'y a dans ce contexte aucune sécurité possible, en tous cas sur un poste de travail "confortable". Si l'utilisateur doit saisir une clé pour valider le password, autant ne pas sauver ce dernier. Ma machine principale sous XP Pro x64 boote sans login, si je disparais inopinément, ou si quelqu'un s'assoit à ma place pendant que je pisse, il n'y a pas de sécurité.
-- Pierre Maurette
Franck Pommereau
Je souhaiterais pouvoir rappeler automatiquement un mot de passe (accès à un serveur FTP), comme le font les clients FTP et les navigateurs. Je ne suis pas vraiment obsédé par la sécurité, néanmoins je ne voudrais quand même pas que ce mot de passe soit en clair dans un fichier .ini ou .cfg, ne serait-ce que pour ne pas faire rire ;-)
Ce n'est pas risible si ces fichiers sont correctement sécurisés. Dans un répertoire accessible uniquement au propriétaire par exemple et dans des fichiers avec des permissions restrictives aussi.
Disons que je me contenterai d'une sécurité de façade, la possibilité de saisir le mot de passe à chaque utilisation étant toujours offerte. Comment puis-je faire au moins mal, uniquement avec les modules standards et de façon portable ?
Une règle de base en cryptographie : la sécurité ne doit pas dépendre de l'ignorance de l'attaquant (sécurité par l'obscurité = pas de sécurité). Elle doit dépendre uniquement d'une clef secrète.
Dans le cas d'un client FTP, la bonne solution me semble que la liste des mots de passe soit chiffrée au moyen d'un mot de passe général entré par l'utilisateur, comme le font les navigateurs Web sérieux. Bien sûr les solutions carte à puce et autres dispositifs physiques sont équivalentes, l'idée est toujours de mettre le mot de passe général à l'abri quelque part (dans la tête de l'utilisateur, sur une carte personnelle protégée par un code PIN, etc.).
Sans cela, ce n'est pas la peine de se donner du mal, autant stocker les mots de passe en clair.
Tout pseudo chiffrement (xor, base64, etc.) est facile à contourner. Tout réel chiffrement avec un clef cachée dans le programme est contournable en retrouvant cette clef. Tout obscurcissement est contournable en appliquant l'algo désobsurcissement qui est disponible dans le programme distribué.
Bref : la sécurité de façade ne sert à rien. Pire, elle donne une fausse confiance dans un logiciel qui n'en est pas digne (on annonce que les mots de passe sont sécurisés alors qu'ils ne le sont pas).
À bon entendeur, Bien cordialement, Franck
Je souhaiterais pouvoir rappeler automatiquement un mot de passe (accès
à un serveur FTP), comme le font les clients FTP et les navigateurs.
Je ne suis pas vraiment obsédé par la sécurité, néanmoins je ne voudrais
quand même pas que ce mot de passe soit en clair dans un fichier .ini ou
.cfg, ne serait-ce que pour ne pas faire rire ;-)
Ce n'est pas risible si ces fichiers sont correctement sécurisés. Dans
un répertoire accessible uniquement au propriétaire par exemple et dans
des fichiers avec des permissions restrictives aussi.
Disons que je me contenterai d'une sécurité de façade, la possibilité de
saisir le mot de passe à chaque utilisation étant toujours offerte.
Comment puis-je faire au moins mal, uniquement avec les modules
standards et de façon portable ?
Une règle de base en cryptographie : la sécurité ne doit pas dépendre de
l'ignorance de l'attaquant (sécurité par l'obscurité = pas de sécurité).
Elle doit dépendre uniquement d'une clef secrète.
Dans le cas d'un client FTP, la bonne solution me semble que la liste
des mots de passe soit chiffrée au moyen d'un mot de passe général entré
par l'utilisateur, comme le font les navigateurs Web sérieux. Bien sûr
les solutions carte à puce et autres dispositifs physiques sont
équivalentes, l'idée est toujours de mettre le mot de passe général à
l'abri quelque part (dans la tête de l'utilisateur, sur une carte
personnelle protégée par un code PIN, etc.).
Sans cela, ce n'est pas la peine de se donner du mal, autant stocker les
mots de passe en clair.
Tout pseudo chiffrement (xor, base64, etc.) est facile à contourner.
Tout réel chiffrement avec un clef cachée dans le programme est
contournable en retrouvant cette clef. Tout obscurcissement est
contournable en appliquant l'algo désobsurcissement qui est disponible
dans le programme distribué.
Bref : la sécurité de façade ne sert à rien. Pire, elle donne une fausse
confiance dans un logiciel qui n'en est pas digne (on annonce que les
mots de passe sont sécurisés alors qu'ils ne le sont pas).
Je souhaiterais pouvoir rappeler automatiquement un mot de passe (accès à un serveur FTP), comme le font les clients FTP et les navigateurs. Je ne suis pas vraiment obsédé par la sécurité, néanmoins je ne voudrais quand même pas que ce mot de passe soit en clair dans un fichier .ini ou .cfg, ne serait-ce que pour ne pas faire rire ;-)
Ce n'est pas risible si ces fichiers sont correctement sécurisés. Dans un répertoire accessible uniquement au propriétaire par exemple et dans des fichiers avec des permissions restrictives aussi.
Disons que je me contenterai d'une sécurité de façade, la possibilité de saisir le mot de passe à chaque utilisation étant toujours offerte. Comment puis-je faire au moins mal, uniquement avec les modules standards et de façon portable ?
Une règle de base en cryptographie : la sécurité ne doit pas dépendre de l'ignorance de l'attaquant (sécurité par l'obscurité = pas de sécurité). Elle doit dépendre uniquement d'une clef secrète.
Dans le cas d'un client FTP, la bonne solution me semble que la liste des mots de passe soit chiffrée au moyen d'un mot de passe général entré par l'utilisateur, comme le font les navigateurs Web sérieux. Bien sûr les solutions carte à puce et autres dispositifs physiques sont équivalentes, l'idée est toujours de mettre le mot de passe général à l'abri quelque part (dans la tête de l'utilisateur, sur une carte personnelle protégée par un code PIN, etc.).
Sans cela, ce n'est pas la peine de se donner du mal, autant stocker les mots de passe en clair.
Tout pseudo chiffrement (xor, base64, etc.) est facile à contourner. Tout réel chiffrement avec un clef cachée dans le programme est contournable en retrouvant cette clef. Tout obscurcissement est contournable en appliquant l'algo désobsurcissement qui est disponible dans le programme distribué.
Bref : la sécurité de façade ne sert à rien. Pire, elle donne une fausse confiance dans un logiciel qui n'en est pas digne (on annonce que les mots de passe sont sécurisés alors qu'ils ne le sont pas).
