GOLDEN PASSWORDS - STOCKEZ VOS MOTS DE PASSE !
Bacterius
Messages postés
3792
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
-
9 août 2009 à 17:39
Bacterius Messages postés 3792 Date d'inscription samedi 22 décembre 2007 Statut Membre Dernière intervention 3 juin 2016 - 9 avril 2010 à 16:09
Bacterius Messages postés 3792 Date d'inscription samedi 22 décembre 2007 Statut Membre Dernière intervention 3 juin 2016 - 9 avril 2010 à 16:09
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/50425-golden-passwords-stockez-vos-mots-de-passe
https://codes-sources.commentcamarche.net/source/50425-golden-passwords-stockez-vos-mots-de-passe
9 avril 2010 à 16:09
Cordialement, Bacterius !
9 avril 2010 à 16:05
Couleau vide
Login vide
MDP vide
Comentaire : des tas et des tas de caracteres chinois ....
- Delphi 2005 :
Couleau noir
Login vide
MDP vide
Comentaire : vide
Dans les deux delphi, si je cree ma table, ca ouvre sans bug. Décidemment je ne connaitrais jamais tes mots de passe !!! Bizarre donc.
9 avril 2010 à 02:18
"Un probleme d'incompatibilité avec XP et seven ??"
j'ai conçu cette source sous XP et ensuite Vista, bizarre ...
Je vais retélécharger la source et essayer pour voir.
...
Apparemment chez moi ça marche (mis à part un léger bug d'affichage de la toolbar), sous Delphi 6.
Quelle version de Delphi utilises-tu ? Car les caractères chinois me font penser à l'unicode, et il est possible que cela pose un problème de lecture du fichier (et de parsage des champs) à cause de la différence unicode/ascii ... le problème vient sûrement de là si tu utilises une version récente de Delphi.
Cordialement, Bacterius !
8 avril 2010 à 17:45
Comentaire : des tas et des tas de caracteres chinois ....
8 avril 2010 à 17:44
C'est peut-etre sans importance, mais si j'essaie d'ouvrir le fichier exemple, ca ne marche pas.
Par contre si je cree un fichier pour le reouvrir par la suite aucun probleme.
Un probleme d'incompatibilité avec XP et seven ??
Login vide
MDP vide
Comentaire : Œ?????? ..........
18 août 2009 à 15:20
Bacteius, si je me permet de tenter de te conseille un peux dans le dommaine c'est parce que dans un autre monde que celui de windows, je articipe au développement d'un de ces petits outils que certains apellent en francais "troussau de clefs", et qui en gros fait la meme chose que ton programme.
Au debut cet outil a eu du mal a s'imposer et a etre compris par les utilisateur (encore maintenant,il n'est utiliser que tres partiellement).
Des le départ ce project a été abordé en visant un maximum de sécurité. En effet il falais un outil utilisable et dont la sécurité devais etre acceptable par la majorité.
Le choix final a été de laisser l'utilisateur libre d'utiliser le ou les algo(s) de cryptage qu'il veut.
Cet autre os est plus flexible, il permet ce genre de choses tres facilement,il suffit d'installer les composants (paquets) et de configurer un fichier (voir d'ajouter un ou des scripts).
Malheureusement la meme technique sous windows me semble complexe a mettre en oeuvre.
Cependant pour etre utilsable réellement, il faut passer par une securité aceptable.
J'ai regardé un peux ton ago perso, je ne vois pas pourquoi tu ne pourrais pas le "mélanger" a ssl par exemple, ton algo meme si "incertain" niveau sécurité (puisque non certfié) permetrais quand meme de brouiller les pistes, je ne pense pas que son utilisation serais nusible ou povoqueras des failles de sécurité, un rsa+ton algo+ssl,ca deviendrais a mon avis une sécurité plus que "acceptable" et rendrais ton outil fonctionnel et utilisble réellement, il serais dommage de ne pas rendre fonctionnel ton outil qui a mon sens a une place parmis les gestionnaires de mot de passe.
En plus il aurais l'avantage que ses sources sonts disponibles...
ni69, de rien pour les précision delphi est "une usine a gaz" et en plus chaque version du compilateur apporte son lot de surprises....
Bon Coding...
ManChesTer.
18 août 2009 à 13:22
- utiliser des algos résistants (AES, Blowfish);
- eventuellement cumuler plusieurs algos ... car le fichier de stockage dépasse rarement le mégaoctet (ou a la rigueur, la dizaine de mégaoctets) pour une personne normale, donc les performances ne s'en ressentiront pas trop.
Le reste me semble correct (ergonomie, fonctionnalités), enfin du moins pour moi, qui ai horreur des usines à gaz comportant dix mille boutons et trois cents menu déroulants ...
Merci également Manchester, précisions utiles sur la gestion des String en Delphi.
Cordialement, Bacterius !
18 août 2009 à 10:05
@ Bacterius : ManChesTer a raison concernant la sécurité, et je le soutiens sur ce point. Si tu tiens à faire un programme réellement utilisable par d'autres, et pas un "simple gadget", il faut vraiment modifier ce point. Au moins pour atteindre un niveau de sécurité suffisant en regard des informations à protéger.
18 août 2009 à 03:16
Evidemment, algo maison, mais si tu veux on peut tenter AES+Blowfish+3DES, le tout avec 3 clefs mathématiquement liées, couplé d'une authentification SHA-512 ... mais après on se s'arrête plus ... pourquoi pas effectuer 100 fois cette combinaison ? Et pourquoi pas 1000 fois ? Etc ...
Cordialement, Bacterius !
18 août 2009 à 03:04
Avec certains "os" ou plutot la facon dont on fais tourné cet os ,fais un teste en vm (eg: virtualbox 64 bits fesant tourné xp 32 ou vice versa), tu veras, la c'est la cata le fillchar sans move...
D'autre part un string peut etre unicode, le fillchar sur un unicode fais parfois une nouvelle variable comme a:="123" a="124" te laisse 123 en ram c'est du aux routinnes de conversions de la vcl... voila le pourquoi de ma var "vide" (qui doit etre du meme type que la var a "effacer").
En plus tu dois maitrisé la totalité des doublons de cette variable fait par delphi ou la vcl ou meme les apis (la vcl appelant les apis)...
Perso, pour ce genre d'appli, je me passe de la vcl, et j'utilise les apis textout sur dc (en dessin) afin d'éviter tout problemes liés aux apis,vcl, unicode etc... Pour etre franc, je l'écrit en asm direct, les routines que le compilateur delphi utilise lors du déploiement de ce type de variables prennent baucoups de libertés...
Le second move remet dans la "varlist" le pointeur de la variable a 0 de cette facon, il est plus complexe de retrouver ou celle ci pointais dans la ram.
c'est un peux comme quand tu fais freeandnil (ou monobject.free; monobject:=nil;) pour un object.
Evidament réutiliser cette variable apres va générer une erreur.
Sinon, je trouve ta gestion interessante, bravo a toi, juste la sécurité qui peut etre mieux mais le parfait n'existe pas dans ce dommaine.
Bon Coding...
ManChesTer.
17 août 2009 à 16:36
Cordialement, Bacterius !
17 août 2009 à 14:19
En effet la sécurité a 100% n'existe pas cependant on peut toujours tenter de s'en approcher...
Par exemple pour "bien" proteger un mot de passe que l'on veut placer dans un fichier, souvent on utilise une ou plusieurs sur encryption.
un exemple :
le mot de passe est "CodeS-SourceS"
nous encrypton avc rsa 2048 CodeS-SourceS
ce qui donne un premier résultat.
Ensuite avec un second algo on ré-encypte le résultat ou une partie du résultat.
En mélangant plusieurs algo le "pirate" devra etre capable de casser les algos succesifs... Ce qui complique fortement son travail.
Etant doné que la vitesse n'a que peux d'importance dans le stockage de mot de passe 5 ou 6 sur encryptions me semble pouvoir etre unesécurité acceptable. Surtout si l'on change régulièrement les mots de passes et que ceux-ci sont suffisament long et complexes.
Autre chose, une simple astuce pour bien vider et detruire une variable de type string:
var monnulstring : string;
mastringvar='PassAdetruire';
fillchar(#0,monulstring,length(mastringvar));
move(monnulstring[1],mastringvar[1],length(mastringvar));
move(monulstring,mastringvar,sizeof(mastringvar));
Bon Coding...
ManChesTer.
15 août 2009 à 20:58
15 août 2009 à 19:32
c'est l'éternel souci:
dès que l'on met une protection en place il faut s'assurer aussitôt de posséder l'antidote...
tout dépend évidemment du niveau de protection que l'on veut mettre.
Mais pour en revenir aux mots de passe sensibles, nous sommes d'accords sur un point: "ne pas les stocker".
15 août 2009 à 13:41
15 août 2009 à 13:40
15 août 2009 à 12:06
faut pas trop regarder les séries TV..
La protection biométrique en est à sa début :
les prochains micros seront à reconnaissance vocale, rétinienne etc. etc.
il sera très difficile de pénétrer un système...
15 août 2009 à 09:16
"Je n'ai pas parlé d'utiliser des chaînes de caractères totalement aléatoires pour les mots de passe, mais pour les "questions secrètes/réponses secrètes", qui se doivent de ne pas représenter de faiblesse trop notoire en matière de sécurité."
15 août 2009 à 09:15
Dans l'idéal, il faudrait en faire de même avec ses mots de passe, mais il semble évidemment complexe de retenir des identifiants aléatoires différents pour chaque session que l'on est amené à ouvrir. Cela peut cependant se contourner facilement en transformant des phrases en mots de passe, ce qui donne une impression de "pseudo-aléatoire".
Ainsi, la phrase suivante :
"Ceci est une Phrase qui me permet de m'Authentifier sur DelphiFR !"
peut donner, en prenant la première lettre de chaque mot et en transformant [une -> 1] et [sur -> @] :
"Ce1Pqupdm'A@D!"
Ce qui est un bon mot de passe (14 caractères + alpha + différente casse + numérique + caractères spéciaux + "introuvable" à partir de dictionnaires + ...)
(note : ne prenez même pas la peine d'essayer, ceci n'est pas mon mot de passe sur CS :p)
15 août 2009 à 00:18
Cordialement, Bacterius !
14 août 2009 à 23:31
Protection biométrique --->>> il ne faut pas que l'on te coupe un doigt ! Et il faut également noter que les lecteurs biométriques vendus dans le commerce sont pour la plupart faillibles (au niveau matériel OU même logiciel!)...
La meilleure solution de "pseudo-sécurité" reste bien évidemment d'avoir un mot de passe différent pour chaque demande d'identification, et qu'il ne réside que dans la mémoire de l'utilisateur. De plus, mieux vaut entrer des suites de caractères aléatoires dans tous les champs "question secrète/réponse secrète" que l'on peut trouver!
10 août 2009 à 22:54
--->>> Protection biométrique !
10 août 2009 à 17:51
Cordialement, Bacterius !
10 août 2009 à 17:47
Une simple calculette de poche à mémoire suffit (avec aucune connexion possible à un réseau)
.....ou avoir une bonne mémoire cervicale comme Bacterius.
cantador
10 août 2009 à 17:36
Cordialement, Bacterius !
10 août 2009 à 17:25
Et dans ce domaine, les meilleurs se sont tous faits avoir
(Pentagone, Armée française, Scotland Yard etc.)
Ce qui n'enlève rien à ton travail de qualité Bacterius..
10 août 2009 à 14:59
Cordialement, Bacterius !
10 août 2009 à 14:51
10 août 2009 à 03:47
- possibilité de redimensionner la fenêtre (j'ai dû déplacer un bouton pour cela)
- clic sur l'icône de la barre des tâches = affichage de la fenêtre
Prochaine étape (et pas petite ...) : tenter de réaliser l'idée de Ni69 (utiliser differemment les codes couleurs, par exemple). Bref, il faut y réfléchir :s
Cordialement, Bacterius !
10 août 2009 à 02:29
- clic sur l'icône de la barre des tâches
Mais comment peut-on faire l'implémentation de ton idée ? (avec le logiciel "gestion.exe") ?
Cordialement, Bacterius !
10 août 2009 à 01:24
Oui effectivement SEA est par flux/flot, même si son architecture laisse à penser que c'est par bloc. Je prends des blocs pour aller plus vite, mais j'applique la même opération bit-à-bit logique. Et je ne me suis pas basé sur AES, autant faire quelque chose d'innovant :p
Si tu regardes bien, LEA s'occupe de générer une suite totalement aléatoire d'entiers 32 bits pour chaque clef, puis additionne/soustrait cette suite avec le message.
Cordialement, Bacterius !
10 août 2009 à 01:20
10 août 2009 à 01:19
10 août 2009 à 01:06
Cordialement, Bacterius !
10 août 2009 à 01:05
Cordialement, Bacterius !
10 août 2009 à 01:03
@ni69 & John Dogget : Ok pour le clic sur l'icône (gestionnaire d'évènement TrayOnClick).
Et pour la sécurité, je ne comprends pas. J'utilise bien deux fois SEA pour la sauvegarde, mais cela est très facilement arrangé. Mais pour l'ouverture du fichier, je décrypte d'abord l'empreinte et je ne continue que si le mot de passe est bon.
"Il faut dans l'idéal que ton fichier ne contienne qu'un seul encodage des données (sinon cela revient à fournir à un attaquant deux informations, et on revient au même point)
"
Faire SEA(Donnée1, Clef) + SEA(Donnée2, Clef) est équivalent à SEA(Donnée1 + Donnée2, Clef), car SEA est un algorithme de chiffrement par flux (et non par bloc comme son code semble le suggérer). Donc au fond il n'y a qu'un seul encodage de données ? Enfin je suis embrouillé là ...
Cordialement, Bacterius !
10 août 2009 à 00:33
Je t'échange 2 barils de source contre 2 kilos de macarons citron et pistache ;-))
Salutations,
Luc.
10 août 2009 à 00:02
10 août 2009 à 00:00
9 août 2009 à 23:57
Pour l'aspect sécurité, je pense que nous nous sommes mal compris.
Ce que je te propose se résume au schéma suivant :
[BLOC_1] = empreinte LEA de [PASSWORD]
[BLOC_2] = données, c'est à dire combinaisons login/password/comments
Lors de l'enregistrement, tu encodes (SEA) l'ENSEMBLE [ [BLOC_1] [BLOC_2] ], ce qui te donne [BLOC_CODE], que tu enregistres dans le fichier.
Lors de l'ouverture du fichier, tu décodes (SEA) l'ENSEMBLE [BLOC_CODE], PUIS tu sépares le résultat en [BLOC_1] et [BLOC_2].
Ce n'est que maintenant que tu vérifies si [BLOC_1] = [PASSWORD], et si c'est le cas, tu charges les données contenues dans [BLOC_2].
De ce que j'ai compris, tu utilises actuellement deux fois SEA pour la sauvegarde (une fois pour l'encodage de l'empreinte, une autre fois pour l'encodage des données. Il faut dans l'idéal que ton fichier ne contienne qu'un seul encodage des données (sinon cela revient à fournir à un attaquant deux informations, et on revient au même point)
9 août 2009 à 23:26
9 août 2009 à 23:18
Oui le double-clic est voulu (enfin pas voulu mais c'est supposé faire ça), c'est clic droit : menu surgissant.
Cordialement, Bacterius !
9 août 2009 à 23:10
- quand on reduit l'application, on a le popup dans le systray mais l'application reste visible dans la barre des tâches
- quand on double-clic sur l'icône du systray, il ne se passe ... rien
9 août 2009 à 22:23
1. L'utilisateur crée un compte nommé "Gestion", entre les paramètres (nom de la fenêtre, etc ...).
2. L'utilisateur se connecte à ce compte.
3. L'utilisateur lance Gestion.exe
4. A ce moment, notre logiciel se rend compte que Gestion.exe est lancé, et va donc, accordément aux paramètres saisis par l'utilisateur, injecter les mots de passe adéquats directement dans les TEdit de Gestion.exe via des messages ?
(de façon générale)
Cordialement, Bacterius !
9 août 2009 à 22:21
Tu voulais sûrement dire "LEA ou SEA" :p
Et oui c'est ce qu'il se passait dans la toute première version déposée sur CS. Mais je crois avoir mis à jour (j'y ai pensé), en encryptant également l'empreinte LEA.
Regarde le code du CheckPassword du cryptosystème actuel :
{ Dans B, on stocke l'empreinte du mot de passe du fichier }
F.ReadBuffer(B, SizeOf(THash));
{ On décrypte l'empreinte }
Encrypt(B, SizeOf(THash), A, OP_DECRYPT);
{ On compare }
Result := SameHash(A, B);
Mais tu as raison, j'avais commis cette faute dans la première version, ce qui donnait à l'attaquant l'empreinte sur un plateau d'argent.
Mais tu ne sais pas tout ! Juste avant de poster sur CS, j'ai modifié en urgence l'algorithme SEA. En effet, il n'était pas du tout adapté pour l'utilisation que ce logiciel en fait. Dans la version "traditionnelle" de SEA, on va hasher le mot de passe, puis hasher le hash du mot de passe, etc ... Seulement, avec cette méthode, voilà ce qu'il se passait :
E est l'empreinte LEA du mot de passe.
On va donc placer dans le fichier l'empreinte LEA, puis la crypter (la fonction de cryptage est appellée C, et de décyptage C-1) :
Puisque SEA ajoute le hashage de la clef au message, on a donc : C(E, Clé) = 2E
Tu vois l'énorme faille ? Mais j'ai corrigé, maintenant c'est différent.
Cordialement, Bacterius !
9 août 2009 à 22:12
Non, pas nécessairement de protocole. Un exemple :
- une application GESTION.EXE me demande, par l'intermédiaire d'une fenêtre de connexion, un login/password pour la gestion d'une DB
- ces login/password sont stockés dans ton logiciel
- si une session est ouverte sur ton logiciel (un utilisateur a ouvert son fichier protégé), ton logiciel reconnaît la fenêtre de GESTION.EXE, réupère les Handle des Edit correspondant aux login/password, injecte dedans les identifiants, et valide.
- l'utilisateur n'a rien eu à faire, et il est automatiquement connecté sur sa DB. Le logiciel GESTION.EXE n'a jamais eu à entrer en contact avec ton logiciel, qui s'est chargé de tout.
Un point important également sur la sécurité de la méthode de stockage (même si il est établi que de toute façon, LEA ou AES ne sont pas "sûrs") : tu utilises le mot de passe principal à deux fins différentes dans la lecture du fichier : d'une part tu testes une valeur de hachage (empreinte LEA sur 64 bits), et d'autre part tu décodes (SEA) le reste du texte. C'est une méthode qui peut sembler plus sécurisée au premier abord, mais qui se révèle être une faiblesse !
D'un point de vue cryptanalytique, cela fournit à un attaquant DEUX informations sur le mot de passe, au lieu d'UNE seule, si tu ne faisais que crypter le contenu ! Si quelqu'un entreprenait de décrypter un de tes fichiers de données, il pourrait donc faire des recoupements, etc... et arriver beaucoup plus vite à ses fins.
Je crois savoir pourquoi tu as opté pour ce système (?) : cela te permet de vérifier que le mot de passe est correct et de ne pas tenter de charger dans ta liste des données illisibles (décodées avec un mauvais password).
Ainsi, il serait plus judicieux à mon sens si tu tiens à garder cette caractéristique, de mettre l'empreinte LEA à l'INTERIEUR du contenu encodé par SEA. Lors du décodage, tu vérifies l'empreinte (64 premiers bits décodés), et si ça colle, tu traite le reste des données.
9 août 2009 à 21:57
Pour les injections, tu voudrais dire, créer une sorte de protocole de communication entre une application tierce et notre cryptosystème afin de permettre à cette application de se connecter à un fichier, et à effectuer des opérations dessus par programmation ?
Cordialement, Bacterius !
9 août 2009 à 21:53
En général, les algorithmes d'encodage "maison" sont beaucoup beaucoup plus faibles que les renommés et éprouvés (Twofish, Triple DES, Rijndael ...), pour de multiples raisons :
- leurs créateurs ne sont pas des experts en cryptologie (il faut de solides connaissances en la matière pour envisager des scénarios d'attaque complexes, et ainsi protéger son algorithme)
- ils n'ont pas subi de cryptanalyse poussée par des experts
- de nombreuses faiblesses sont exploitables (par exemple les tunnels dans les algos de hachage)
- etc...
Il est donc fortement déconseillé de s'en servir pour réellement protéger des données sensibles. Ca va si ça reste dans le cadre du "bricolage".
9 août 2009 à 21:10
- Le deuxième paragraphe je comprends pas trop bien ... enregistrer les identifiants et les mots de passe ... moyen quoi, si c'est enregistré en clair. Je pense qu'il faudrait mieux enregistrer leurs empreintes. Mais je ne comprends pas le reste ?
- Pour l'encodage SEA, au fond je ne peux pas trop me prononcer dessus non plus vu que j'en suis l'inventeur (également celui de LEA) et que je l'ai pas encore présenté devant des hommes en noir lol ! Les sources sont comprises dans le zip.
Cordialement, Bacterius !
9 août 2009 à 21:05
9 août 2009 à 21:05
Après, dans le cadre d'une évolution future, il serait sympa d'implémenter une procédure d'auto-login sur des applications externes :
En plus d'enregistrer les identifiants et mots de passe, tu pourrais garder en mémoire le path de l'application et le nom/titre de la fenêtre demandant ces login/password, et si une fenêtre ouverte correspond à quelque-chose d'enregistré dans le fichier de données courant (donc une fois que l'utilisateur a entré son mot de passe principal), faire en sorte de communiquer directement les infos, sans que l'utilisateur n'ait à le faire !
(je sais pas si c'est très clair la manière dont je l'explique... :p)
9 août 2009 à 20:53
Cordialement, Bacterius !
9 août 2009 à 20:41
Reste à appliquer ça sur toute donnée sensible (Data et les données de List).
Cordialement, Bacterius !
9 août 2009 à 20:38
9 août 2009 à 20:35
Cordialement, Bacterius !
9 août 2009 à 20:34
FillChar(Pwd[1], Length(Pwd), 1);
Ce qui a pour effet de remplacer la RAM qui contenait le mot de passe par des #1.
Cordialement, Bacterius !
9 août 2009 à 20:34
9 août 2009 à 20:33
Ainsi, si tu fais
str := 'abcd';
str := '0123';
Alors les deux valeurs 'abcd' et '0123' seront présentes dans la RAM.
Cela ne suffit donc pas de faire str := ''; comme tu le préconises !
9 août 2009 à 20:31
C'est gagné chez moi, Ni69, j'ai réussi à bien nettoyer (FillChar(Pwd[1], Length(Pwd), 1);). J'envoie le zip.
Cordialement, Bacterius !
9 août 2009 à 20:28
9 août 2009 à 20:28
Cordialement, Bacterius !
9 août 2009 à 20:27
Cordialement, Bacterius !
9 août 2009 à 20:25
9 août 2009 à 20:18
Cordialement, Bacterius !
9 août 2009 à 20:12
Cordialement, Bacterius !
9 août 2009 à 20:01
Une piste serait d'utiliser ReadProcessMemory pour localiser les occurences du mot de passe, et WriteProcessMemory pour les remplacer. Mais c'est un cercle totalement vicieux, car la lecture des données de la mémoire de l'application elle-même entraînera le stockage des données lues également dans la même mémoire, à un autre endroit !... Ainsi si on récupère toute la mémoire d'un coup, l'application doublera sa RAM allouée pour stocker le résultat, et on n'en finit plus.
9 août 2009 à 19:15
- Variable string "Pwd". Elle n'est pas libérée à la fermeture du fichier.
- Variable TStringList "Data". Son contenu est "Clear" à la fermeture, mais cela semble insuffisant.
- Variable TListView "List". Son contenu est "Clear" à la fermeture, mais cela semble insuffisant.
- Barre de status "StatusBar". Son contenu est effacé à la fermeture, mais cela semble insuffisant.
J'en ai raté ?
Cordialement, Bacterius !
9 août 2009 à 19:12
Cordialement, Bacterius !
9 août 2009 à 19:11
"DelphiFR" offsets :
009FB7F5
00A029AD
00A029EC
00A02CCD
00A0313C
00A03DE8
[Après fermeture]
"DelphiFR" offsets :
009FB7F5
00A029AD
00A029EC
00A0313C
00A03DE8
Effectivement il y a un grave problème là lol.
Cordialement, Bacterius !
9 août 2009 à 19:08
9 août 2009 à 19:06
Cordialement, Bacterius !
9 août 2009 à 18:59
Bon j'ai mis à jour :
- correction du bug de l'Ajouter
- suppression du log
- suppression des erreurs variées
- ajout d'un filtrage par couleur dans la recherche (possibilité de l'ignorer)
- double-clic dans la liste de résultats de recherche corrigée
On va pouvoir se pencher sur le problème de libération de la RAM ... car c'est bien beau d'avoir une fonction rechercher mais si on peut retrouver les mots de passe dans la RAM c'est pas terrible ...
Cordialement, Bacterius !
9 août 2009 à 18:55
9 août 2009 à 18:54
Imaginons que la zone que l'on veut libérer se situe entre l'offset 0x00000002 et 0x00000008.
Il y a des données très sensibles entre ces deux offsets.
1. On remplit cette zone de mémoire avec des zéros (ZeroMemory).
2. On libère cette mémoire.
?
Cordialement, Bacterius !
9 août 2009 à 18:51
9 août 2009 à 18:44
Oui ben c'est inévitable le but c'est quand même de les voir les mots de passe
comique
Faut-il procéder à un écrasement puis à une libération pour un nettoyage total (remplir les données avec des caractères nuls, puis libérer ?).
Cordialement, Bacterius !
9 août 2009 à 18:43
Bon, le bug d'ajouter est réglé, le log est effacé, dans le Cryptosystem.Close, on a bien "Data.Clear", ce n'est pas suffisant pour effacer les traces du fichier dans la RAM ? Et pour les erreurs multiples c'est règlé aussi. Il me reste la recherche par couleurs et le double clic ...
Cordialement, Bacterius !
9 août 2009 à 18:42
[Mot de passe : "DelphiFR"]
9 août 2009 à 18:38
Le #1 convient très bien (j'ai pas beaucoup dormi et je pensais que tu utilisais les deux caractères "#1" comme séparation !)
9 août 2009 à 18:34
Pour l'ajouter, je vais mettre à jour.
Pour la fenêtre de recherche, tu veux dire pouvoir choisir un code couleur pour approfondir le filtrage ? Et le double clic est une bonne idée, pas pensé à ça.
Merci pour l'avertissement pour la RAM, je vais voir (il m'avait semblé faire un Data.Clear pour nettoyer les mots de passe dans la RAM à la fermeture des fichiers ?). Et pour les exceptions ... finalement je suis content que tu me dises ça car ça me gênait tous ces messages différents.
Je mets à jour ... merci :)
Cordialement, Bacterius !
9 août 2009 à 18:28
Je viens de regarder ton code. Je pense qu'il serait mieux d'employer des caractères non imprimables comme séparateurs. En effet, le #1 peut être utilisé dans des mots de passe...
Petits détails : quand on fait Ajouter, puis directement Annuler, la ligne se créée quand même dans ton fichier, il faudrait qu'elle soit supprimée! Dans la fenêtre de recherche, il serait peut-être bien d'ajouter également les codes couleur. Un double-clic sur la ligne pourrait avoir le même effet qu'un clic sur "Aller à..."
Il y a un petit problème : une fois le fichier de données fermé, les mots de passe restent dans la RAM !
Au niveau de la sécurité, je pense aussi que le principe du Log est superflu, et qu'il serait plus sage de ne pas différencier les erreurs RES_LOAD_ERROR, RES_CHECK_ERROR ansi que RES_GET_ERROR, car cela indique directement à un attaquant potentiel où se situe l'impossibilité d'accès. Autant rester vague !
9 août 2009 à 17:39
Cordialement, Bacterius !