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
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
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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw > zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw > zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw > zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
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.
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.
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.
Pierre Maurette wrote:
[...]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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw >>> zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
Pierre Maurette
C'est une question que je vois souvent posée sur le forum python
Anglophone ... et à chaque fois les réponses sont à peu près les mêmes:
un binaire peut être décompilé; un .pyc aussi.
Mon métier c'est la carte à puce ... il n'y a à ma connaisance aucun
moyen de sécuriser une transaction (financière, d'identification, ....)
sans passer pas un "token" qui lui est certifié incracable (au moment de
la certif. ;-) )
Les techniques de code "auto-modifiable" de chez les vieux de
l'assembleur ne sont pas applicables en Python ... à part peut être en
passant par un module décrypté dynamiquement ... et même là les attaques
possibles sont nombreuses: Si une personne désire/peut mettre les moyens
pour attaquer, elle trouvera une faille.
La solution que je préconise à chaque fois est: d'abord définir le niveau
de sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis
mettre les moyens en face => l'avantage que tu as sur un fournisseur
d'anti-virus (mon analogie préférée) c'est que tu définis tes spécs. ...
et peux les garder propriétaires.
Je me permets de te préciser qu'un système à carte à puce est maintenant
_très_ abordable; même pour un petit volume ... et te fournirai les liens
nécessaires si celà à un intérêt (sans vendre mes softs. ou
mon "consulting" ... promis)
hg
Cela dit ... y compris avec des token quel qu'il soit il est
"relativement aisé" de craquer n'importe quoi si on a accès au code ne
serait ce même qu'avec un débuggeur, la volonté et du temps. Les cartes
à puces permettent d'avoir une assez bonne sécurisation des
transmissions, mais le fait d'avoir accès à une machine et déjà une
faille ;)
Bertrand qui a quelque fois joué avec AFD (il y a prescription ;) )
Pierre Maurette wrote:
[...]
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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw >>> zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
Pierre Maurette
C'est une question que je vois souvent posée sur le forum python
Anglophone ... et à chaque fois les réponses sont à peu près les mêmes:
un binaire peut être décompilé; un .pyc aussi.
Mon métier c'est la carte à puce ... il n'y a à ma connaisance aucun
moyen de sécuriser une transaction (financière, d'identification, ....)
sans passer pas un "token" qui lui est certifié incracable (au moment de
la certif. ;-) )
Les techniques de code "auto-modifiable" de chez les vieux de
l'assembleur ne sont pas applicables en Python ... à part peut être en
passant par un module décrypté dynamiquement ... et même là les attaques
possibles sont nombreuses: Si une personne désire/peut mettre les moyens
pour attaquer, elle trouvera une faille.
La solution que je préconise à chaque fois est: d'abord définir le niveau
de sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis
mettre les moyens en face => l'avantage que tu as sur un fournisseur
d'anti-virus (mon analogie préférée) c'est que tu définis tes spécs. ...
et peux les garder propriétaires.
Je me permets de te préciser qu'un système à carte à puce est maintenant
_très_ abordable; même pour un petit volume ... et te fournirai les liens
nécessaires si celà à un intérêt (sans vendre mes softs. ou
mon "consulting" ... promis)
hg
Cela dit ... y compris avec des token quel qu'il soit il est
"relativement aisé" de craquer n'importe quoi si on a accès au code ne
serait ce même qu'avec un débuggeur, la volonté et du temps. Les cartes
à puces permettent d'avoir une assez bonne sécurisation des
transmissions, mais le fait d'avoir accès à une machine et déjà une
faille ;)
Bertrand qui a quelque fois joué avec AFD (il y a prescription ;) )
Pierre Maurette wrote:
[...]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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw >>> zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
Pierre Maurette
C'est une question que je vois souvent posée sur le forum python
Anglophone ... et à chaque fois les réponses sont à peu près les mêmes:
un binaire peut être décompilé; un .pyc aussi.
Mon métier c'est la carte à puce ... il n'y a à ma connaisance aucun
moyen de sécuriser une transaction (financière, d'identification, ....)
sans passer pas un "token" qui lui est certifié incracable (au moment de
la certif. ;-) )
Les techniques de code "auto-modifiable" de chez les vieux de
l'assembleur ne sont pas applicables en Python ... à part peut être en
passant par un module décrypté dynamiquement ... et même là les attaques
possibles sont nombreuses: Si une personne désire/peut mettre les moyens
pour attaquer, elle trouvera une faille.
La solution que je préconise à chaque fois est: d'abord définir le niveau
de sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis
mettre les moyens en face => l'avantage que tu as sur un fournisseur
d'anti-virus (mon analogie préférée) c'est que tu définis tes spécs. ...
et peux les garder propriétaires.
Je me permets de te préciser qu'un système à carte à puce est maintenant
_très_ abordable; même pour un petit volume ... et te fournirai les liens
nécessaires si celà à un intérêt (sans vendre mes softs. ou
mon "consulting" ... promis)
hg
Cela dit ... y compris avec des token quel qu'il soit il est
"relativement aisé" de craquer n'importe quoi si on a accès au code ne
serait ce même qu'avec un débuggeur, la volonté et du temps. Les cartes
à puces permettent d'avoir une assez bonne sécurisation des
transmissions, mais le fait d'avoir accès à une machine et déjà une
faille ;)
Bertrand qui a quelque fois joué avec AFD (il y a prescription ;) )
Pierre Maurette wrote:
[...]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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw >> zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
Pierre Maurette
C'est une question que je vois souvent posée sur le forum python
Anglophone ... et à chaque fois les réponses sont à peu près les mêmes: un
binaire peut être décompilé; un .pyc aussi.
Mon métier c'est la carte à puce ... il n'y a à ma connaisance aucun moyen
de sécuriser une transaction (financière, d'identification, ....) sans
passer pas un "token" qui lui est certifié incracable (au moment de la
certif. ;-) )
Les techniques de code "auto-modifiable" de chez les vieux de l'assembleur
ne sont pas applicables en Python ... à part peut être en passant par un
module décrypté dynamiquement ... et même là les attaques possibles sont
nombreuses: Si une personne désire/peut mettre les moyens pour attaquer,
elle trouvera une faille.
La solution que je préconise à chaque fois est: d'abord définir le niveau de
sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis mettre
les moyens en face => l'avantage que tu as sur un fournisseur d'anti-virus
(mon analogie préférée) c'est que tu définis tes spécs. ... et peux les
garder propriétaires.
Je me permets de te préciser qu'un système à carte à puce est maintenant
_très_ abordable; même pour un petit volume ... et te fournirai les liens
nécessaires si celà à un intérêt (sans vendre mes softs. ou
mon "consulting" ... promis)
hg
Cela dit ... y compris avec des token quel qu'il soit il est
Pierre Maurette wrote:
[...]
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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw >> zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
Pierre Maurette
C'est une question que je vois souvent posée sur le forum python
Anglophone ... et à chaque fois les réponses sont à peu près les mêmes: un
binaire peut être décompilé; un .pyc aussi.
Mon métier c'est la carte à puce ... il n'y a à ma connaisance aucun moyen
de sécuriser une transaction (financière, d'identification, ....) sans
passer pas un "token" qui lui est certifié incracable (au moment de la
certif. ;-) )
Les techniques de code "auto-modifiable" de chez les vieux de l'assembleur
ne sont pas applicables en Python ... à part peut être en passant par un
module décrypté dynamiquement ... et même là les attaques possibles sont
nombreuses: Si une personne désire/peut mettre les moyens pour attaquer,
elle trouvera une faille.
La solution que je préconise à chaque fois est: d'abord définir le niveau de
sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis mettre
les moyens en face => l'avantage que tu as sur un fournisseur d'anti-virus
(mon analogie préférée) c'est que tu définis tes spécs. ... et peux les
garder propriétaires.
Je me permets de te préciser qu'un système à carte à puce est maintenant
_très_ abordable; même pour un petit volume ... et te fournirai les liens
nécessaires si celà à un intérêt (sans vendre mes softs. ou
mon "consulting" ... promis)
hg
Cela dit ... y compris avec des token quel qu'il soit il est
Pierre Maurette wrote:
[...]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.
Ou même un peu mieux, quand même. En fait, crypter / décrypter n'est
pas un souci. Je me posais des problèmes d'obfuscation du code, ce qui
en définitive est prématuré et pas en rapport avec ma problématique.
Soit c'est une machine perso, et je me contente de ne pas avoir pw >> zorglub en clair dans un .ini, soit je ne sauvegarde pas du tout les
mots de passe. D'ailleurs, la version en ligne de commande impose sa
saisie.
Merci d'avoir pris le temps de répondre.
--
Pierre Maurette
C'est une question que je vois souvent posée sur le forum python
Anglophone ... et à chaque fois les réponses sont à peu près les mêmes: un
binaire peut être décompilé; un .pyc aussi.
Mon métier c'est la carte à puce ... il n'y a à ma connaisance aucun moyen
de sécuriser une transaction (financière, d'identification, ....) sans
passer pas un "token" qui lui est certifié incracable (au moment de la
certif. ;-) )
Les techniques de code "auto-modifiable" de chez les vieux de l'assembleur
ne sont pas applicables en Python ... à part peut être en passant par un
module décrypté dynamiquement ... et même là les attaques possibles sont
nombreuses: Si une personne désire/peut mettre les moyens pour attaquer,
elle trouvera une faille.
La solution que je préconise à chaque fois est: d'abord définir le niveau de
sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis mettre
les moyens en face => l'avantage que tu as sur un fournisseur d'anti-virus
(mon analogie préférée) c'est que tu définis tes spécs. ... et peux les
garder propriétaires.
Je me permets de te préciser qu'un système à carte à puce est maintenant
_très_ abordable; même pour un petit volume ... et te fournirai les liens
nécessaires si celà à un intérêt (sans vendre mes softs. ou
mon "consulting" ... promis)
hg
Cela dit ... y compris avec des token quel qu'il soit il est
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 ;-)
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 ;-)
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 ;-)
D'un autre côté, le mot de passe circule en clair sur le réseau et peut être
aussi retrouvé dans l'historique de la ligne de commande.
Donc le sauvegarder en clair dans un fichier n'est pas si risible que ça (à
mon sens).
D'un autre côté, le mot de passe circule en clair sur le réseau et peut être
aussi retrouvé dans l'historique de la ligne de commande.
Donc le sauvegarder en clair dans un fichier n'est pas si risible que ça (à
mon sens).
D'un autre côté, le mot de passe circule en clair sur le réseau et peut être
aussi retrouvé dans l'historique de la ligne de commande.
Donc le sauvegarder en clair dans un fichier n'est pas si risible que ça (à
mon sens).
D'un autre côté, le mot de passe circule en clair sur le réseau et
peut être
aussi retrouvé dans l'historique de la ligne de commande.
Donc le sauvegarder en clair dans un fichier n'est pas si risible que
ça (à
mon sens).
Oui, surtout si le fichier est dans un espace sécurisé.
D'un autre côté, le mot de passe circule en clair sur le réseau et
peut être
aussi retrouvé dans l'historique de la ligne de commande.
Donc le sauvegarder en clair dans un fichier n'est pas si risible que
ça (à
mon sens).
Oui, surtout si le fichier est dans un espace sécurisé.
D'un autre côté, le mot de passe circule en clair sur le réseau et
peut être
aussi retrouvé dans l'historique de la ligne de commande.
Donc le sauvegarder en clair dans un fichier n'est pas si risible que
ça (à
mon sens).
Oui, surtout si le fichier est dans un espace sécurisé.
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...
--
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...
--
Maric Michaud - www.aristote.info
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
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
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.
La solution que je préconise à chaque fois est: d'abord définir le niveau
de
sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis mettre
les moyens en face => l'avantage que tu as sur un fournisseur d'anti-virus
(mon analogie préférée) c'est que tu définis tes spécs. ... et peux les
garder propriétaires.
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
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
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.
La solution que je préconise à chaque fois est: d'abord définir le niveau
de
sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis mettre
les moyens en face => l'avantage que tu as sur un fournisseur d'anti-virus
(mon analogie préférée) c'est que tu définis tes spécs. ... et peux les
garder propriétaires.
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
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
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.
La solution que je préconise à chaque fois est: d'abord définir le niveau
de
sécurité à atteindre (qu'est-ce que je perds s'ils rentrent?) puis mettre
les moyens en face => l'avantage que tu as sur un fournisseur d'anti-virus
(mon analogie préférée) c'est que tu définis tes spécs. ... et peux les
garder propriétaires.