Le problème est que si j'entre seulement le premiere lettre ou chiffre il
accepte alors que celles qui suivent sont fausses. Comment je peux faire
pour que le programme teste un à un les caratères?
Le problème est que si j'entre seulement le premiere lettre ou chiffre il accepte alors que celles qui suivent sont fausses. Comment je peux faire pour que le programme teste un à un les caratères?
merci
"Steph" <invite.francais@btinternet.com> a écrit dans le message de news:feudnQiloaGv3ATZRVnysw@bt.com...
Le problème est que si j'entre seulement le premiere lettre ou chiffre il
accepte alors que celles qui suivent sont fausses. Comment je peux faire
pour que le programme teste un à un les caratères?
Le problème est que si j'entre seulement le premiere lettre ou chiffre il accepte alors que celles qui suivent sont fausses. Comment je peux faire pour que le programme teste un à un les caratères?
strcmp renvoie 0 si les chaînes sont égales, - 1 ou +1 suivant que pw est avant valide dans l'ordre alphabétique ou après. Et tu ne testes que le +1. D'autre part, pour strcmp, j'incluerais <string.h>, mais c'est plutôt du C, alors va voir du côté du type string et inclues <string>.
Etienne
"Steph" <invite.francais@btinternet.com> a écrit ...
strcmp renvoie 0 si les chaînes sont égales,
- 1 ou +1 suivant que pw est avant valide dans l'ordre
alphabétique ou après. Et tu ne testes que le +1.
D'autre part, pour strcmp, j'incluerais <string.h>,
mais c'est plutôt du C, alors va voir du côté du type
string et inclues <string>.
strcmp renvoie 0 si les chaînes sont égales, - 1 ou +1 suivant que pw est avant valide dans l'ordre alphabétique ou après. Et tu ne testes que le +1. D'autre part, pour strcmp, j'incluerais <string.h>, mais c'est plutôt du C, alors va voir du côté du type string et inclues <string>.
Etienne
Cyrille
boujour
J'ai créé un programme dont voici une partie :
#include <iostream>
ajouter: #include <string>
using namespace std;
int main (void)
{ char pw[20]; const char valide[20]="12H12";
remplacer ces deux lignes par: string pw; const string valide = "12H12";
Le problème est que si j'entre seulement le premiere lettre ou chiffre il accepte alors que celles qui suivent sont fausses. Comment je peux faire pour que le programme teste un à un les caratères?
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
-- C'est ma signature qu'elle est la mieux. Pas la vôtre.
boujour
J'ai créé un programme dont voici une partie :
#include <iostream>
ajouter:
#include <string>
using namespace std;
int main (void)
{
char pw[20];
const char valide[20]="12H12";
remplacer ces deux lignes par:
string pw;
const string valide = "12H12";
Le problème est que si j'entre seulement le premiere lettre ou chiffre il
accepte alors que celles qui suivent sont fausses. Comment je peux faire
pour que le programme teste un à un les caratères?
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur
l'utilisation de std::string. Les tableaux de char à taille fixe,
surtout dans un contexte de sécurité, comme ici, sont à proscrire.
--
C'est ma signature qu'elle est la mieux. Pas la vôtre.
Le problème est que si j'entre seulement le premiere lettre ou chiffre il accepte alors que celles qui suivent sont fausses. Comment je peux faire pour que le programme teste un à un les caratères?
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
-- C'est ma signature qu'elle est la mieux. Pas la vôtre.
Sylvain
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Sylvain.
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur
l'utilisation de std::string. Les tableaux de char à taille fixe,
surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
pense-tu qu'une implémentation non balancée, à temps variable et
proportionnel à la longueur de la phrase de passe candidate, soit plus
pertinente ?
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Sylvain.
Fabien LE LEZ
On Wed, 21 Jun 2006 13:53:12 +0100, "Steph" :
char pw[20]; const char valide[20]="12H12";
cout << " Password :"; cin >> pw;
Horriblement casse-gueule, tout ça. Je ne saurais trop te conseiller d'utiliser std::string à la place des tableaux de char du C.
Accessoirement, demande-toi ce qui se passerait si je tapais le mot de passe suivant :
abcdefghijklmnopqrstabcdefghijklmnopqrst
On Wed, 21 Jun 2006 13:53:12 +0100, "Steph"
<invite.francais@btinternet.com>:
char pw[20];
const char valide[20]="12H12";
cout << " Password :";
cin >> pw;
Horriblement casse-gueule, tout ça.
Je ne saurais trop te conseiller d'utiliser std::string à la place des
tableaux de char du C.
Accessoirement, demande-toi ce qui se passerait si je tapais le mot de
passe suivant :
Horriblement casse-gueule, tout ça. Je ne saurais trop te conseiller d'utiliser std::string à la place des tableaux de char du C.
Accessoirement, demande-toi ce qui se passerait si je tapais le mot de passe suivant :
abcdefghijklmnopqrstabcdefghijklmnopqrst
Cyrille
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20 caractères pour écrire dans de la mémoire dans laquelle il ne devrait pas écrire. Je suppose que tu ne l'ignores pas.
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des fonctions de string C pour éviter les problèmes les plus évidents.
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Généralement oui.
-- C'est ma signature qu'elle est la mieux. Pas la vôtre.
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur
l'utilisation de std::string. Les tableaux de char à taille fixe,
surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20
caractères pour écrire dans de la mémoire dans laquelle il ne devrait
pas écrire. Je suppose que tu ne l'ignores pas.
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des
fonctions de string C pour éviter les problèmes les plus évidents.
pense-tu qu'une implémentation non balancée, à temps variable et
proportionnel à la longueur de la phrase de passe candidate, soit plus
pertinente ?
Généralement oui.
--
C'est ma signature qu'elle est la mieux. Pas la vôtre.
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20 caractères pour écrire dans de la mémoire dans laquelle il ne devrait pas écrire. Je suppose que tu ne l'ignores pas.
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des fonctions de string C pour éviter les problèmes les plus évidents.
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Généralement oui.
-- C'est ma signature qu'elle est la mieux. Pas la vôtre.
Sylvain
Cyrille wrote on 21/06/2006 22:43:
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20 caractères pour écrire dans de la mémoire dans laquelle il ne devrait pas écrire. Je suppose que tu ne l'ignores pas.
je l'ignore pas, et c'est pour cela que je n'utilise jamais gets() ni ce pale wrapper de "cin".
la question des buffer overflow n'est toutefois pas liée au "contexte de sécurité", donc je repose ma question: en quoi une taille variable serait un plus ici?
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des fonctions de string C pour éviter les problèmes les plus évidents.
on aimerait aussi/surtout définir dynamiquement des opérateurs pour des types inconnus de la std; difficile pour une classe fournie par le runtime.
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Généralement oui.
hmmm, 100% des cryptologes sont dans l'erreur alors, j'aimerais en lire plus ici aussi.
Sylvain.
Cyrille wrote on 21/06/2006 22:43:
Cyrille wrote on 21/06/2006 22:15:
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur
l'utilisation de std::string. Les tableaux de char à taille fixe,
surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20
caractères pour écrire dans de la mémoire dans laquelle il ne devrait
pas écrire. Je suppose que tu ne l'ignores pas.
je l'ignore pas, et c'est pour cela que je n'utilise jamais gets() ni ce
pale wrapper de "cin".
la question des buffer overflow n'est toutefois pas liée au "contexte de
sécurité", donc je repose ma question: en quoi une taille variable
serait un plus ici?
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des
fonctions de string C pour éviter les problèmes les plus évidents.
on aimerait aussi/surtout définir dynamiquement des opérateurs pour des
types inconnus de la std; difficile pour une classe fournie par le runtime.
pense-tu qu'une implémentation non balancée, à temps variable et
proportionnel à la longueur de la phrase de passe candidate, soit plus
pertinente ?
Généralement oui.
hmmm, 100% des cryptologes sont dans l'erreur alors, j'aimerais en lire
plus ici aussi.
Voir la réponse d'Etienne Rousee. Mais j'insiste vraiment sur l'utilisation de std::string. Les tableaux de char à taille fixe, surtout dans un contexte de sécurité, comme ici, sont à proscrire.
peux-tu détailler ce qui a avantage à ne pas avoir une taille fixe ?
Ben utilisés comme ça, il suffit que l'utilisateur balance plus de 20 caractères pour écrire dans de la mémoire dans laquelle il ne devrait pas écrire. Je suppose que tu ne l'ignores pas.
je l'ignore pas, et c'est pour cela que je n'utilise jamais gets() ni ce pale wrapper de "cin".
la question des buffer overflow n'est toutefois pas liée au "contexte de sécurité", donc je repose ma question: en quoi une taille variable serait un plus ici?
Bon, c'est vrai on peut aussi utiliser des versions sécurisées des fonctions de string C pour éviter les problèmes les plus évidents.
on aimerait aussi/surtout définir dynamiquement des opérateurs pour des types inconnus de la std; difficile pour une classe fournie par le runtime.
pense-tu qu'une implémentation non balancée, à temps variable et proportionnel à la longueur de la phrase de passe candidate, soit plus pertinente ?
Généralement oui.
hmmm, 100% des cryptologes sont dans l'erreur alors, j'aimerais en lire plus ici aussi.
Sylvain.
Sylvain
Gabriel Dos Reis wrote on 22/06/2006 01:44:
Sylvain writes:
| pense-tu qu'une implémentation non balancée, à temps variable et | proportionnel à la longueur de la phrase de passe candidate, soit plus | pertinente ?
Pardon ?
une "implémentation balancée" garantirait que chaque cycle d'instruction omis (du fait de la taille des registres, du nombre d'opérations scalairisées (faite en simultanée)) serait balancé par un NOP fournissant un temps constant pour une opération donnée.
la proposition de Cyrille - utiliser std::string operator==(const std::string& - n'est pas "moins balancée" que la fonction strcmp, mais elle est aussi mauvaise.
une implémentation à temps constant non proportionelle au passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
un passphrase de n caractères d'entropie p (eg 56 pour de l'alpha maj & min) est censé fournir une entropie totale p^n, ici (strcmp comme string==) s'arrète dès le premier caractère différent, l'entropie effective n'est donc que de p * n.
une telle implémentation de vérification de phrase de passe se révèlerait donc un système très facile à casser.
Sylvain.
Gabriel Dos Reis wrote on 22/06/2006 01:44:
Sylvain <noSpam@mail.net> writes:
| pense-tu qu'une implémentation non balancée, à temps variable et
| proportionnel à la longueur de la phrase de passe candidate, soit plus
| pertinente ?
Pardon ?
une "implémentation balancée" garantirait que chaque cycle d'instruction
omis (du fait de la taille des registres, du nombre d'opérations
scalairisées (faite en simultanée)) serait balancé par un NOP
fournissant un temps constant pour une opération donnée.
la proposition de Cyrille - utiliser std::string operator==(const
std::string& - n'est pas "moins balancée" que la fonction strcmp, mais
elle est aussi mauvaise.
une implémentation à temps constant non proportionelle au passphrase
candidat garantirait qu'aucune attaque basée sur le temps (les plus
faciles) ne peut être utilisée.
un passphrase de n caractères d'entropie p (eg 56 pour de l'alpha maj &
min) est censé fournir une entropie totale p^n, ici (strcmp comme
string==) s'arrète dès le premier caractère différent, l'entropie
effective n'est donc que de p * n.
une telle implémentation de vérification de phrase de passe se
révèlerait donc un système très facile à casser.
| pense-tu qu'une implémentation non balancée, à temps variable et | proportionnel à la longueur de la phrase de passe candidate, soit plus | pertinente ?
Pardon ?
une "implémentation balancée" garantirait que chaque cycle d'instruction omis (du fait de la taille des registres, du nombre d'opérations scalairisées (faite en simultanée)) serait balancé par un NOP fournissant un temps constant pour une opération donnée.
la proposition de Cyrille - utiliser std::string operator==(const std::string& - n'est pas "moins balancée" que la fonction strcmp, mais elle est aussi mauvaise.
une implémentation à temps constant non proportionelle au passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
un passphrase de n caractères d'entropie p (eg 56 pour de l'alpha maj & min) est censé fournir une entropie totale p^n, ici (strcmp comme string==) s'arrète dès le premier caractère différent, l'entropie effective n'est donc que de p * n.
une telle implémentation de vérification de phrase de passe se révèlerait donc un système très facile à casser.
Sylvain.
Sylvain
Gabriel Dos Reis wrote on 22/06/2006 01:44:
Sylvain writes:
| pense-tu qu'une implémentation non balancée, à temps variable et | proportionnel à la longueur de la phrase de passe candidate, soit plus | pertinente ?
Pardon ?
[reposté après correction des coquilles]
une "implémentation balancée" garantirait que chaque cycle d'instruction omis (du fait de la taille des registres, du nombre d'opérations scalairisées (faite en simultanée) serait balancé par un NOP fournissant un temps constant pour une opération donnée.
la proposition de Cyrille - utiliser std::string operator==(const std::string&) - n'est pas "moins balancée" que la fonction strcmp, mais elle est aussi mauvaise (sur ce point; elle corrige bien sur l'erreur faite sur la gestion de la taille des phrases).
une implémentation à temps constant non proportionelle à la longueur du passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
un passphrase de n caractères d'entropie p (eg 52 pour de l'alpha maj & min) est censé fournir une entropie totale p^n, ici strcmp() comme string==() s'arrète dès le premier caractère différent, l'entropie effective n'est donc que de p * n.
une telle implémentation de vérification de phrase de passe se révèlerait donc un système très facile à casser.
Sylvain.
Gabriel Dos Reis wrote on 22/06/2006 01:44:
Sylvain <noSpam@mail.net> writes:
| pense-tu qu'une implémentation non balancée, à temps variable et
| proportionnel à la longueur de la phrase de passe candidate, soit plus
| pertinente ?
Pardon ?
[reposté après correction des coquilles]
une "implémentation balancée" garantirait que chaque cycle d'instruction
omis (du fait de la taille des registres, du nombre d'opérations
scalairisées (faite en simultanée) serait balancé par un NOP fournissant
un temps constant pour une opération donnée.
la proposition de Cyrille - utiliser std::string operator==(const
std::string&) - n'est pas "moins balancée" que la fonction strcmp, mais
elle est aussi mauvaise (sur ce point; elle corrige bien sur l'erreur
faite sur la gestion de la taille des phrases).
une implémentation à temps constant non proportionelle à la longueur du
passphrase candidat garantirait qu'aucune attaque basée sur le temps
(les plus faciles) ne peut être utilisée.
un passphrase de n caractères d'entropie p (eg 52 pour de l'alpha maj &
min) est censé fournir une entropie totale p^n, ici strcmp() comme
string==() s'arrète dès le premier caractère différent, l'entropie
effective n'est donc que de p * n.
une telle implémentation de vérification de phrase de passe se
révèlerait donc un système très facile à casser.
| pense-tu qu'une implémentation non balancée, à temps variable et | proportionnel à la longueur de la phrase de passe candidate, soit plus | pertinente ?
Pardon ?
[reposté après correction des coquilles]
une "implémentation balancée" garantirait que chaque cycle d'instruction omis (du fait de la taille des registres, du nombre d'opérations scalairisées (faite en simultanée) serait balancé par un NOP fournissant un temps constant pour une opération donnée.
la proposition de Cyrille - utiliser std::string operator==(const std::string&) - n'est pas "moins balancée" que la fonction strcmp, mais elle est aussi mauvaise (sur ce point; elle corrige bien sur l'erreur faite sur la gestion de la taille des phrases).
une implémentation à temps constant non proportionelle à la longueur du passphrase candidat garantirait qu'aucune attaque basée sur le temps (les plus faciles) ne peut être utilisée.
un passphrase de n caractères d'entropie p (eg 52 pour de l'alpha maj & min) est censé fournir une entropie totale p^n, ici strcmp() comme string==() s'arrète dès le premier caractère différent, l'entropie effective n'est donc que de p * n.
une telle implémentation de vérification de phrase de passe se révèlerait donc un système très facile à casser.
Sylvain.
Gabriel Dos Reis
Cyrille writes:
| Bon, c'est vrai on peut aussi utiliser des versions sécurisées des | fonctions de string C pour éviter les problèmes les plus évidents.
pourquoi faire compliquer (C string) lorsqu'on peut faire simple (std::string) ?
-- Gaby
Cyrille <cyrille@frsf.invalid> writes:
| Bon, c'est vrai on peut aussi utiliser des versions sécurisées des
| fonctions de string C pour éviter les problèmes les plus évidents.
pourquoi faire compliquer (C string) lorsqu'on peut faire simple
(std::string) ?
