[MFC]Login et mot de passe

Version imprimable

18/07/2006, 12h05
jacklafrip

[MFC]Login et mot de passe

Bonjour à toi qui à la bonté de lire ce post.
Voici une petite question, après avoir lu les différents autres posts traitant du sujet.
J'ai déjà créé mon interface graphique avec deux EditBox, et je sais récupérer les données envoyées.
Mais je n'ai pas le droit de faire une base de données, je dois donc faire un fichier crypté. J'ai trouvé sur ce forum, un lien expliquant comment crypter et decrypter.

Le problème devient donc simplissime : comment faire pour lire ce ****** de fichier crypté ?
J'ai décidé de ne crypter que le mot de passe, et laisser le login en clair.
Un readfiletoend me parait tres tres lourd, et pour me sortir d'un fgets avec deux boucles imbriquées, je vois pas trop...

D'après vous, comment me sortir de ce pétrin ?

Merci pour vos réponses
18/07/2006, 13h42
Médinoc

Euh... Tu le cryptes comment, le fichier ?
Il est déconseillé de le lire avec fgets() si ce n'est plus du texte après cryptage...
(surtout que le caractère Ctrl-Z stoppe une lecture en mode texte)
18/07/2006, 16h16
jacklafrip

Bon, j'arrive à écrire dans mon fichier.
En fait, sur chaque ligne, j'ai deux informations : une en clair (l'identifiant), l'autre en brouillé(le mot de passe).
J'utilise la classe CCryptString trouvé sur codeguru, et j'utilise la méthode CALG_SHA (voir MSDN)

Mon problème vient justement de fgets().
Le problème, c'est que je ne vois pas bien comment extraire les informations : un strtok sur la ligne obtenue par fgets me donnerait à chaque fois deux valeurs par ligne (au moins si je ne dois pas ajouter des trucs plus tard comme des droits...).
Je vois pas trop comment faire pour récupérer ca comme il faut ..
18/07/2006, 16h27
la drogue c'est mal

je comprends pas le probleme. Si tu récuperes 2 éléments par ligne, c'est bon vu que c'est le login+pass, non ?
18/07/2006, 17h02
Médinoc

Je viens de jeter un coup d'oeil au code sample, et apparemment, c'est bien ce que je craignais: La chaîne une fois cryptée n'est plus une chaîne, mais du binaire.
Elle n'est donc plus sûre d'être terminée par un caractère nul, et peut même se retrouver avec un caractère nul au beau milieu!

Donc, le mot de passe crypté n'est plus une chaîne, tu dois le gérer en tant que données binaires (soit tu l'écris directement dans un fichier binaire, soit tu l'encodes (en base64 par exemple) pour l'écrire dans un fichier texte.
19/07/2006, 10h21
jacklafrip

Merci médinoc
Là, je ne comprend plus :
Comment est-ce possible que ce ne soit plus une chaine une fois cryptée ?
Pourtant, elle reste en TCHAR*, c'est pas une chaine de caractères ça ?
Si ce n'est plus une chaine, je fais comment pour l'écrire dans un fichier, puisque fwrite, et fread demande des chaines ...

A moins que je n'ai vraiment rien compris du tout...:oops:
19/07/2006, 11h08
Médinoc

Elle reste en TCHAR *, mais c'est une erreur, car son contenu n'est plus lisible en tant que chaîne.
En fait, cela devrait plustôt être un void*.

La fonction utilisée, CryptEncrypt(), ne traite que des données binaires. La chaine est donc considérée comme des données binaires, puis cryptée en d'autres données binaires. Mais les données binaires d'arrivée ne correspondent plus à une chaîne.

PS: fwrite() et fread() peuvent écrire des données binaires.

Ou bien, tu peux encoder tes données binaires sous forme de chaîne (en hexa ou en base64 par exemple)

Donc si je comprends bien, si je fais
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 FILE *file = fopen("C:\\Temp\\passe.bin","wb"); CCryptString oCrypt; CString truc; truc = Dlg.identif +";"+ Dlg.passwd +"\n"; TCHAR passwdenc[256]=_T(""); oCrypt.EncryptString((TCHAR*)(const char*)(truc),passwdenc,cryptkey); for (int i=0;i<(int)strlen(passwdenc);i++){ fwrite(passwdenc,sizeof(TCHAR*),strlen(passwdenc),file); } fclose(file); return TRUE;
ca peut pas marcher ?
Parceque :
1°) strlen(passwdenc) retourne n'importe quoi,
2°) et que passwdenc c'est un void* et par un TCHAR*

Bon, bah, comme je ne suis qu'un simple et jeune padawan, aurais-tu une de tes nombreuses idées géniales, ô grand maître médinoc ?

PS : Si d'autres se sentent chauds pour répondre, ils ont le droit aussi ...:roll:

19/07/2006, 11h27
jacklafrip

Précisions :
1°) Je fais le fopen avec l'option "ab" et non "wb" pour écrire en fin de fichier...
2°) Pour le moment, mon code est écrit ainsi, et mon fichier binaire, quand j'essaye de le lire, me montre toujours la même chaîne : 0A 00 00 00 00 00 00 quelque soient les valeurs entrées pour l'identifiant et le mot de passe. Pourtant, elles sont bien reconnues car si je les ecris en clair, pas de problème, c'est bien les bonnes.
19/07/2006, 11h49
Médinoc

1°) Oui
2°) Non, mais surtout parce que ton sizeof() ne désigne pas la bonne chose.

Et je pense que ton double-cast est inutile. Pour la CString, essaie en utilisant tout simplement un static_cast< LPCTSTR >(truc).

Mon conseil: Tu connais la première taille, et je pense que la taille ne change pas, la chaîne cryptée doit donc toujours avoir une taille de (longueur+1)*sizeof(TCHAR).
Donc, ceci devrait marcher:

Code:

fwrite(passwdenc, sizeof(*passwdenc), truc.GetLength()+1, file);

Note qu'il n'y a pas de boucle for.
19/07/2006, 13h48
jacklafrip

Après avoir remis des choses dans mon estomac, j'ai essayé ta méthode, médinoc, mais ca ne marche pas...
1°) Un simple cast comme tu proposes me donne l'erreur suivante :

Code:

error C2664: 'CCryptString::EncryptString' : cannot convert parameter 1 from 'LPCTSTR' to 'TCHAR *'

J'ai donc remis un double cast, en laissant le premier comme tu le fait.
2°) Lorsque j'essaye de lire mon fichier avec ultraedit, je ne vois qu'une ligne remplie de zéro, donc je pense que c'est quelque peu raté...:cry: :pleure:

Je ne suis plus très loin de :arf:

J'avoue être pas mal perdu, là ...
19/07/2006, 14h00
Médinoc

Ah, je n'avais pas vu, la fonction de cryptage est mal déclarée.
Passe truc.GetBuffer() et appelle truc.ReleaseBuffer() après cryptage, c'est plus élégant qu'un double-cast.

Quand à l'enregistrement, bizarre. Je peux voir ton code final après modification?

Et, peux-tu regarder si les fonctions ne retournent pas une valeur d'erreur?
19/07/2006, 14h35
jacklafrip

C'est cool, même si ca marche toujours pas, ca avance...
Voici donc les dernières nouvelles :
1°) Effectivement, ta méthode est bien plus belle et marche très bien.
2°) Voici le problème désormais, cerné, il ne va pas s'en tirer ...
C'est la fonction EncryptString qui déconne : (sortie toujours à FALSE)
J'ai rajouté un entier pour savoir pourquoi la sortie de la fonction est toujours "false", et le plantage se fait sur

Code:

if (CryptDeriveKey(hProv, MY_ENCRYPT, hHash, CRYPT_EXPORTABLE, &hKey))

(ligne 121 pour moi)
il ne rentre pas dedans, car il trouve toujours FALSE.

Sinon, voici le code de mon appel :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
CDlgIdentification Dlg;
Dlg.DoModal();
if (newcompte == TRUE){
	CDlgNewCompte Dlg;
	Dlg.DoModal();
 
	FILE *file = fopen("C:\\Temp\\passe.bin","wb");
	CCryptString oCrypt;
	CString truc;
	TCHAR passwdenc[256]=_T("");
 
	truc= Dlg.identif +";"+ Dlg.passwd + "\n";
 
	oCrypt.EncryptString(truc.GetBuffer(),passwdenc,cryptkey);
	truc.ReleaseBuffer();
 
	fwrite(passwdenc,sizeof(*passwdenc),truc.GetLength() + 1,file);
	fclose(file);
 
	return TRUE;
}

19/07/2006, 14h54
Médinoc

Je ne vois rien qui me choque dans ton code.

Tu peux essayer de débugguer le code de cryptage à coup de GetLastError()+FormatMessage()+MessageBox()...
19/07/2006, 15h33
jacklafrip
ca y est, j'ai trouvé l'erreur :
"algorithme spécifié non valide"
pourtant, j'ai mis au début de CString.cpp :
Code:

1 2 3 #define _WIN32_WINNT 0x0400 #define MY_ENCRYPT CALG_SHA1
c'est pas une bonne déinfition d'alogorithme ca ?
pourtant, j'étais allé faire un tour sur la msdn là où il faut

Quoi ais-je fait encore comme :furieux: ??
19/07/2006, 15h44
Médinoc

CALG_SHA1 est un algo de hachage.
Pour CryptDeriveKey(), on te demande un algo de cryptage (d'où le nom MY_ENCRYPT)
19/07/2006, 16h20
jacklafrip

:oops: :oops: :oops: :oops: Désolé pour cette question à la con.
J'ai donc changé l'algo en prenant cette fois-ci

Code:

#define MY_ENCRYPT CALG_3DES

et ca passe... jusqu'au plantage suivant

Maintenant, l'erreur a encore changé : "Plus de données disponibles"
L'erreur retournée est donc ERROR_MORE_DATA, c'est à dire, si je comprend bien, que la taille des données à crypter est supérieure à la taille des données.

Pourtant, juste avant, la ligne

Code:

dwLength = sizeof(TCHAR)*(_tcslen(szPassword));

ne reserve-t-elle pas la bonne taille ?
J'avoue que je rame, je rame, mais dans une barque qui prend l'eau...
19/07/2006, 21h36
Médinoc

C'est pasce que cette *$^$$* de fonction est mal faite.
Ou bien, qu'il te faut un chiffrement de flux (essaie CALG_RC4), qui lui, devrait te donner la même taille.
24/07/2006, 08h59
jacklafrip

Merci beaucoup Medinoc pour ces conseils, ca a l'air de marcher avec CALG_RC4.
J'obtiens en effet un fichier crypté qui change suivant les paramètres que je rentre.
A plus tard pour de nouvelles aventures.

Fuseau horaire GMT +2. Il est actuellement 19h09.