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?
| Gabriel Dos Reis wrote on 23/06/2006 16:57: | > | le PO indique: | > ce sont tes follow-ups qui m'intéressent. | | un follow-up ici ? c'est encore de l'ironie ? | | il est impossible ici de discuter d'un problème algorithmique précis | sans que l'on déforme/extrapole/amplifie un détail hors sujet en | manquement grave à un 'idiome', une 'façon professionelle de'.
C'est une belle description de l'impression que j'ai eue en lisant tes messages :-)
| > Tu fustigeais l'utilisation de std::string. Retourne en arrière, | | tu peux me citer stp, on ne doit pas partager la même def. de "fustiguer"
# mais c'est vrai que la réponse très normée et formattée std::machin # est surement suffisante si on ne se pose aucune question, d'age ou # autre.
-- Gaby
Sylvain <noSpam@mail.net> writes:
| Gabriel Dos Reis wrote on 23/06/2006 16:57:
| > | le PO indique:
| > ce sont tes follow-ups qui m'intéressent.
|
| un follow-up ici ? c'est encore de l'ironie ?
|
| il est impossible ici de discuter d'un problème algorithmique précis
| sans que l'on déforme/extrapole/amplifie un détail hors sujet en
| manquement grave à un 'idiome', une 'façon professionelle de'.
C'est une belle description de l'impression que j'ai eue en lisant
tes messages :-)
| > Tu fustigeais l'utilisation de std::string. Retourne en arrière,
|
| tu peux me citer stp, on ne doit pas partager la même def. de "fustiguer"
# mais c'est vrai que la réponse très normée et formattée std::machin
# est surement suffisante si on ne se pose aucune question, d'age ou
# autre.
| Gabriel Dos Reis wrote on 23/06/2006 16:57: | > | le PO indique: | > ce sont tes follow-ups qui m'intéressent. | | un follow-up ici ? c'est encore de l'ironie ? | | il est impossible ici de discuter d'un problème algorithmique précis | sans que l'on déforme/extrapole/amplifie un détail hors sujet en | manquement grave à un 'idiome', une 'façon professionelle de'.
C'est une belle description de l'impression que j'ai eue en lisant tes messages :-)
| > Tu fustigeais l'utilisation de std::string. Retourne en arrière, | | tu peux me citer stp, on ne doit pas partager la même def. de "fustiguer"
# mais c'est vrai que la réponse très normée et formattée std::machin # est surement suffisante si on ne se pose aucune question, d'age ou # autre.
-- Gaby
Sylvain
Gabriel Dos Reis wrote on 24/06/2006 01:54:
C'est une belle description de l'impression que j'ai eue en lisant tes messages :-)
ah tu m'éclaires, moi j'exprimais et partageais des vues techniques pas
des impressions. ben j'ai tout faux alors parce s'il ne faut que partager des impressions (consensuelles naturellement) c'est un peu galatineux pour moi. je vais continuer à lire tes propositions techniques qui ont des vrais morceaux factuels dedans et oublier ses potins de comptoir alors.
| > Tu fustigeais l'utilisation de std::string. Retourne en arrière, | | tu peux me citer stp, on ne doit pas partager la même def. de "fustiguer"
# mais c'est vrai que la réponse très normée et formattée std::machin # est surement suffisante si on ne se pose aucune question, d'age ou # autre.
cela s'appelle de la fierté mal placée cher ami!
l'ISO et l'ANSI sont en tête de mes comptes-fournisseurs; je respecte autant la sueur mise dans une norme que le front qu'il l'a versée.
toutefois, quand une discussion dénigre les finesses (problème masqué, corollaire, pour aller plus loin, etc) pour juste se planquer derrière une norme (par ailleurs déjà suggérée et retenue), cela peut nuire à mon style.
ayant noté que ton "pourquoi le temps ne varira pas avec la saisie" n'est, dis-tu, que lié à "ma réaction [] par rapport à l'utilisation de std::string" (moi je ne vois aucun rapport) je constate en effet que le style peut prendre des formes étonnantes.
Sylvain.
Gabriel Dos Reis wrote on 24/06/2006 01:54:
C'est une belle description de l'impression que j'ai eue en lisant
tes messages :-)
ah tu m'éclaires, moi j'exprimais et partageais des vues techniques pas
des impressions.
ben j'ai tout faux alors parce s'il ne faut que partager des impressions
(consensuelles naturellement) c'est un peu galatineux pour moi.
je vais continuer à lire tes propositions techniques qui ont des vrais
morceaux factuels dedans et oublier ses potins de comptoir alors.
| > Tu fustigeais l'utilisation de std::string. Retourne en arrière,
|
| tu peux me citer stp, on ne doit pas partager la même def. de "fustiguer"
# mais c'est vrai que la réponse très normée et formattée std::machin
# est surement suffisante si on ne se pose aucune question, d'age ou
# autre.
cela s'appelle de la fierté mal placée cher ami!
l'ISO et l'ANSI sont en tête de mes comptes-fournisseurs; je respecte
autant la sueur mise dans une norme que le front qu'il l'a versée.
toutefois, quand une discussion dénigre les finesses (problème masqué,
corollaire, pour aller plus loin, etc) pour juste se planquer derrière
une norme (par ailleurs déjà suggérée et retenue), cela peut nuire à mon
style.
ayant noté que ton "pourquoi le temps ne varira pas avec la saisie"
n'est, dis-tu, que lié à "ma réaction [] par rapport à l'utilisation de
std::string" (moi je ne vois aucun rapport) je constate en effet que le
style peut prendre des formes étonnantes.
C'est une belle description de l'impression que j'ai eue en lisant tes messages :-)
ah tu m'éclaires, moi j'exprimais et partageais des vues techniques pas
des impressions. ben j'ai tout faux alors parce s'il ne faut que partager des impressions (consensuelles naturellement) c'est un peu galatineux pour moi. je vais continuer à lire tes propositions techniques qui ont des vrais morceaux factuels dedans et oublier ses potins de comptoir alors.
| > Tu fustigeais l'utilisation de std::string. Retourne en arrière, | | tu peux me citer stp, on ne doit pas partager la même def. de "fustiguer"
# mais c'est vrai que la réponse très normée et formattée std::machin # est surement suffisante si on ne se pose aucune question, d'age ou # autre.
cela s'appelle de la fierté mal placée cher ami!
l'ISO et l'ANSI sont en tête de mes comptes-fournisseurs; je respecte autant la sueur mise dans une norme que le front qu'il l'a versée.
toutefois, quand une discussion dénigre les finesses (problème masqué, corollaire, pour aller plus loin, etc) pour juste se planquer derrière une norme (par ailleurs déjà suggérée et retenue), cela peut nuire à mon style.
ayant noté que ton "pourquoi le temps ne varira pas avec la saisie" n'est, dis-tu, que lié à "ma réaction [] par rapport à l'utilisation de std::string" (moi je ne vois aucun rapport) je constate en effet que le style peut prendre des formes étonnantes.
Sylvain.
Arnaud Meurgues
Jean-Marc Bourguet wrote:
Question : l'introduction de nop aléatoires ne pourraient-ils pas être plus simple tout en étant suffisante pour empêcher de déduire quoique ce soit du temps d'analyse ? De l'aleatoire asser sur pour ce genre d'application c'est difficile a
faire d'une part, d'autre part ca ne fait qu'ajouter du bruit qu'on peut filtrer au prix d'un facteur constant.
En pratique, on rentre un grand nombre de fois le même mot de passe candidat et on « statistise » le temps de réponse ?
Mais il me semblait que depuis un bon moment déjà, et notamment sur unix, les temps de réponse de vérification de mot passe étaient volontairement longs de manière à décourager des longs traitements.
Combien faut-il d'essais pour avoir une mesure statistique fiable et utilisable ?
-- Arnaud
Jean-Marc Bourguet wrote:
Question : l'introduction de nop aléatoires ne pourraient-ils pas être
plus simple tout en étant suffisante pour empêcher de déduire quoique ce
soit du temps d'analyse ?
De l'aleatoire asser sur pour ce genre d'application c'est difficile a
faire d'une part, d'autre part ca ne fait qu'ajouter du bruit qu'on
peut filtrer au prix d'un facteur constant.
En pratique, on rentre un grand nombre de fois le même mot de passe
candidat et on « statistise » le temps de réponse ?
Mais il me semblait que depuis un bon moment déjà, et notamment sur
unix, les temps de réponse de vérification de mot passe étaient
volontairement longs de manière à décourager des longs traitements.
Combien faut-il d'essais pour avoir une mesure statistique fiable et
utilisable ?
Question : l'introduction de nop aléatoires ne pourraient-ils pas être plus simple tout en étant suffisante pour empêcher de déduire quoique ce soit du temps d'analyse ? De l'aleatoire asser sur pour ce genre d'application c'est difficile a
faire d'une part, d'autre part ca ne fait qu'ajouter du bruit qu'on peut filtrer au prix d'un facteur constant.
En pratique, on rentre un grand nombre de fois le même mot de passe candidat et on « statistise » le temps de réponse ?
Mais il me semblait que depuis un bon moment déjà, et notamment sur unix, les temps de réponse de vérification de mot passe étaient volontairement longs de manière à décourager des longs traitements.
Combien faut-il d'essais pour avoir une mesure statistique fiable et utilisable ?
-- Arnaud
Jean-Marc Bourguet
Note préalable: je ne prétends pas avoir des connaissances en matière de sécurité...
Arnaud Meurgues writes:
Jean-Marc Bourguet wrote:
Question : l'introduction de nop aléatoires ne pourraient-ils pas être plus simple tout en étant suffisante pour empêcher de déduire quoique ce soit du temps d'analyse ?
De l'aleatoire asser sur pour ce genre d'application c'est difficile a faire d'une part, d'autre part ca ne fait qu'ajouter du bruit qu'on peut filtrer au prix d'un facteur constant.
En pratique, on rentre un grand nombre de fois le même mot de passe candidat et on « statistise » le temps de réponse ?
Dans le cas présent, l'analyse statistique n'est pas compliquée: tu prends le temps minimum...
Mais il me semblait que depuis un bon moment déjà, et notamment sur unix, les temps de réponse de vérification de mot passe étaient volontairement longs de manière à décourager des longs traitements.
C'est une des techniques utilisées. On peut combiner avec un changement de mot de passe régulier (toutes les 30 secondes par exemple) comme ça faire des longs traitements est impossible.
Je suppose que dans les systèmes où la sécurité est importante, on a aussi des process qui surveillent les échecs et avertissent les personnes compétantes quand il y en a trop de manière trop rapprochées, ou suivant des schémas bizarres même étalés, ou de provenance étrange.
Combien faut-il d'essais pour avoir une mesure statistique fiable et utilisable ?
Ca fait trop longtemps que j'ai fait de l'identification de paramètres pour pouvoir répondre. Ca va dépendre vraissemblablement de la nature du bruit, mais bon ça ne doit prendre qu'un temps constant de mesurer cette distribution si on ne la connait pas.
Mais on est bien loin des préoccupations de l'OP qui n'avait qu'un petit exercice de programmation et pas de sécurité. Si
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Note préalable: je ne prétends pas avoir des connaissances
en matière de sécurité...
Question : l'introduction de nop aléatoires ne
pourraient-ils pas être plus simple tout en étant
suffisante pour empêcher de déduire quoique ce soit du
temps d'analyse ?
De l'aleatoire asser sur pour ce genre d'application
c'est difficile a faire d'une part, d'autre part ca ne
fait qu'ajouter du bruit qu'on peut filtrer au prix d'un
facteur constant.
En pratique, on rentre un grand nombre de fois le même mot de passe
candidat et on « statistise » le temps de réponse ?
Dans le cas présent, l'analyse statistique n'est pas
compliquée: tu prends le temps minimum...
Mais il me semblait que depuis un bon moment déjà, et
notamment sur unix, les temps de réponse de vérification
de mot passe étaient volontairement longs de manière à
décourager des longs traitements.
C'est une des techniques utilisées. On peut combiner avec
un changement de mot de passe régulier (toutes les 30
secondes par exemple) comme ça faire des longs traitements
est impossible.
Je suppose que dans les systèmes où la sécurité est
importante, on a aussi des process qui surveillent les
échecs et avertissent les personnes compétantes quand il y
en a trop de manière trop rapprochées, ou suivant des
schémas bizarres même étalés, ou de provenance étrange.
Combien faut-il d'essais pour avoir une mesure statistique
fiable et utilisable ?
Ca fait trop longtemps que j'ai fait de l'identification de
paramètres pour pouvoir répondre. Ca va dépendre
vraissemblablement de la nature du bruit, mais bon ça ne
doit prendre qu'un temps constant de mesurer cette
distribution si on ne la connait pas.
Mais on est bien loin des préoccupations de l'OP qui n'avait
qu'un petit exercice de programmation et pas de sécurité.
Si
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Note préalable: je ne prétends pas avoir des connaissances en matière de sécurité...
Arnaud Meurgues writes:
Jean-Marc Bourguet wrote:
Question : l'introduction de nop aléatoires ne pourraient-ils pas être plus simple tout en étant suffisante pour empêcher de déduire quoique ce soit du temps d'analyse ?
De l'aleatoire asser sur pour ce genre d'application c'est difficile a faire d'une part, d'autre part ca ne fait qu'ajouter du bruit qu'on peut filtrer au prix d'un facteur constant.
En pratique, on rentre un grand nombre de fois le même mot de passe candidat et on « statistise » le temps de réponse ?
Dans le cas présent, l'analyse statistique n'est pas compliquée: tu prends le temps minimum...
Mais il me semblait que depuis un bon moment déjà, et notamment sur unix, les temps de réponse de vérification de mot passe étaient volontairement longs de manière à décourager des longs traitements.
C'est une des techniques utilisées. On peut combiner avec un changement de mot de passe régulier (toutes les 30 secondes par exemple) comme ça faire des longs traitements est impossible.
Je suppose que dans les systèmes où la sécurité est importante, on a aussi des process qui surveillent les échecs et avertissent les personnes compétantes quand il y en a trop de manière trop rapprochées, ou suivant des schémas bizarres même étalés, ou de provenance étrange.
Combien faut-il d'essais pour avoir une mesure statistique fiable et utilisable ?
Ca fait trop longtemps que j'ai fait de l'identification de paramètres pour pouvoir répondre. Ca va dépendre vraissemblablement de la nature du bruit, mais bon ça ne doit prendre qu'un temps constant de mesurer cette distribution si on ne la connait pas.
Mais on est bien loin des préoccupations de l'OP qui n'avait qu'un petit exercice de programmation et pas de sécurité. Si
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gabriel Dos Reis
Sylvain writes:
| Gabriel Dos Reis wrote on 24/06/2006 01:54: | > C'est une belle description de l'impression que j'ai eue en lisant | > tes messages :-) | > | ah tu m'éclaires, moi j'exprimais et partageais des vues techniques | pas des impressions.
comme tes contacts avec le monde ne peut se faire qu'à travers tes sens, tu ne peux avoir que des impressions. Le mieux que tu puisses souhaiter, c'est que ces impressions correspondent un peu à quelque chose proche de la réalité.
[...]
| toutefois, quand une discussion dénigre les finesses
Je n'ai aucun problème que tu dénigres lorsque tu proposes quelque chose qui a un sens.
-- Gaby
Sylvain <noSpam@mail.net> writes:
| Gabriel Dos Reis wrote on 24/06/2006 01:54:
| > C'est une belle description de l'impression que j'ai eue en lisant
| > tes messages :-)
| >
| ah tu m'éclaires, moi j'exprimais et partageais des vues techniques
| pas des impressions.
comme tes contacts avec le monde ne peut se faire qu'à travers tes
sens, tu ne peux avoir que des impressions. Le mieux que tu puisses
souhaiter, c'est que ces impressions correspondent un peu à quelque
chose proche de la réalité.
[...]
| toutefois, quand une discussion dénigre les finesses
Je n'ai aucun problème que tu dénigres lorsque tu proposes quelque
chose qui a un sens.
| Gabriel Dos Reis wrote on 24/06/2006 01:54: | > C'est une belle description de l'impression que j'ai eue en lisant | > tes messages :-) | > | ah tu m'éclaires, moi j'exprimais et partageais des vues techniques | pas des impressions.
comme tes contacts avec le monde ne peut se faire qu'à travers tes sens, tu ne peux avoir que des impressions. Le mieux que tu puisses souhaiter, c'est que ces impressions correspondent un peu à quelque chose proche de la réalité.
[...]
| toutefois, quand une discussion dénigre les finesses
Je n'ai aucun problème que tu dénigres lorsque tu proposes quelque chose qui a un sens.
-- Gaby
Gabriel Dos Reis
Sylvain writes:
[...]
| je n'affectionne pas / ne comprends pas ce type de comm. !
C'est bien.
-- Gaby
Sylvain <noSpam@mail.net> writes:
[...]
| je n'affectionne pas / ne comprends pas ce type de comm. !
| je n'affectionne pas / ne comprends pas ce type de comm. !
C'est bien.
-- Gaby
James Kanze
Sylvain wrote:
Michel Decima wrote on 23/06/2006 13:56:
Si tu ne traite pas EOF, le compteur cnt ne contient pas le nombre de caracteres fournis par l'utilisateur.
ah c'est l'injection d'un buffer nul qui te gène !... je vois.
Je crois que c'est le code incorrect qui le gène. Lis au moins ce qu'il a écrit, et régarde les exemples de test.
donc j'ai affaire à des gens qui confondent "temps passé à taper au clavier" et temps du traitement de strcmp; il faut leur expliquer qu'un pipe permet d'injecter des *annuaires* (plusieurs *mega*) de mots de passe et tu viens noter que zéro car. ne marche pas !... tu as tout à fait raison et on s'en fout complètement par rapport au pb exposé.
Le problème exposé, c'est un programme qui ne marche pas ; qui donne un mauvais résultat, permet dès débordements de buffer, etc. Ton code continue à présenter des erreurs sérieuses.
Si tu ne complete pas le buffer, l'algorithme de comparaison ne marche pas.
ne veux rien dire. je peux calculer un digest sur tout nombre de caractères (enfin de 0 à 2305843009213693952 pour les classiques). je peux comparer bit à bit 20 octets qlq soit la façon dont ce hash est calculé.
Manifestement, tu n'as pas compris le problème dans ton code.
Dans un de tes postings, tu as listé un bon nombre de précautions à prendre pour la sécurité. C'était très bien, et très informatif ; je conclus que tu connais assez bien les problèmes de sécurité. En revanche, d'après tes postings, j'ai de très fortes doutes sur tes compétences en C++, ou dans les bases de la génie logicielle. La qualité de ton code ne passerait pas de revue de code dans les boîtes où j'ai travaillé. (Note bien que ce n'est pas une critique en soi. Dans une application, il faut en général d'avantage d'experts métiers que d'experts techniques.)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Sylvain wrote:
Michel Decima wrote on 23/06/2006 13:56:
Si tu ne traite pas EOF, le compteur cnt ne contient pas le
nombre de caracteres fournis par l'utilisateur.
ah c'est l'injection d'un buffer nul qui te gène !... je vois.
Je crois que c'est le code incorrect qui le gène. Lis au moins
ce qu'il a écrit, et régarde les exemples de test.
donc j'ai affaire à des gens qui confondent "temps passé à
taper au clavier" et temps du traitement de strcmp; il faut
leur expliquer qu'un pipe permet d'injecter des *annuaires*
(plusieurs *mega*) de mots de passe et tu viens noter que zéro
car. ne marche pas !... tu as tout à fait raison et on s'en
fout complètement par rapport au pb exposé.
Le problème exposé, c'est un programme qui ne marche pas ; qui
donne un mauvais résultat, permet dès débordements de buffer,
etc. Ton code continue à présenter des erreurs sérieuses.
Si tu ne complete pas le buffer, l'algorithme de comparaison
ne marche pas.
ne veux rien dire. je peux calculer un digest sur tout nombre
de caractères (enfin de 0 à 2305843009213693952 pour les
classiques). je peux comparer bit à bit 20 octets qlq soit la
façon dont ce hash est calculé.
Manifestement, tu n'as pas compris le problème dans ton code.
Dans un de tes postings, tu as listé un bon nombre de
précautions à prendre pour la sécurité. C'était très bien, et
très informatif ; je conclus que tu connais assez bien les
problèmes de sécurité. En revanche, d'après tes postings, j'ai
de très fortes doutes sur tes compétences en C++, ou dans les
bases de la génie logicielle. La qualité de ton code ne
passerait pas de revue de code dans les boîtes où j'ai
travaillé. (Note bien que ce n'est pas une critique en soi. Dans
une application, il faut en général d'avantage d'experts métiers
que d'experts techniques.)
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Si tu ne traite pas EOF, le compteur cnt ne contient pas le nombre de caracteres fournis par l'utilisateur.
ah c'est l'injection d'un buffer nul qui te gène !... je vois.
Je crois que c'est le code incorrect qui le gène. Lis au moins ce qu'il a écrit, et régarde les exemples de test.
donc j'ai affaire à des gens qui confondent "temps passé à taper au clavier" et temps du traitement de strcmp; il faut leur expliquer qu'un pipe permet d'injecter des *annuaires* (plusieurs *mega*) de mots de passe et tu viens noter que zéro car. ne marche pas !... tu as tout à fait raison et on s'en fout complètement par rapport au pb exposé.
Le problème exposé, c'est un programme qui ne marche pas ; qui donne un mauvais résultat, permet dès débordements de buffer, etc. Ton code continue à présenter des erreurs sérieuses.
Si tu ne complete pas le buffer, l'algorithme de comparaison ne marche pas.
ne veux rien dire. je peux calculer un digest sur tout nombre de caractères (enfin de 0 à 2305843009213693952 pour les classiques). je peux comparer bit à bit 20 octets qlq soit la façon dont ce hash est calculé.
Manifestement, tu n'as pas compris le problème dans ton code.
Dans un de tes postings, tu as listé un bon nombre de précautions à prendre pour la sécurité. C'était très bien, et très informatif ; je conclus que tu connais assez bien les problèmes de sécurité. En revanche, d'après tes postings, j'ai de très fortes doutes sur tes compétences en C++, ou dans les bases de la génie logicielle. La qualité de ton code ne passerait pas de revue de code dans les boîtes où j'ai travaillé. (Note bien que ce n'est pas une critique en soi. Dans une application, il faut en général d'avantage d'experts métiers que d'experts techniques.)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Arnaud Meurgues wrote:
[...]
Mais il me semblait que depuis un bon moment déjà, et notamment sur unix, les temps de réponse de vérification de mot passe étaient volontairement longs de manière à décourager des longs traitements.
Depuis au moins vingt ans:-). J'avais lu quelque chose de Richie déjà aux années 1980, où il disait avoir choisi un algorithme exprès qui prenait la plus grande partie d'une séconde à exécuter. Les machines sont évolues depuis, et la vérification d'un mot de passe Unix aujourd'hui dure bien peu -- quelque millisecondes, peut-être, voire moins d'une milliséconde.
Reste que certains programmes qui les utilisent ajoute une attente après une erreur, de façon justement à ne pas répondre trop vite.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Arnaud Meurgues wrote:
[...]
Mais il me semblait que depuis un bon moment déjà, et
notamment sur unix, les temps de réponse de vérification de
mot passe étaient volontairement longs de manière à décourager
des longs traitements.
Depuis au moins vingt ans:-). J'avais lu quelque chose de Richie
déjà aux années 1980, où il disait avoir choisi un algorithme
exprès qui prenait la plus grande partie d'une séconde à
exécuter. Les machines sont évolues depuis, et la vérification
d'un mot de passe Unix aujourd'hui dure bien peu -- quelque
millisecondes, peut-être, voire moins d'une milliséconde.
Reste que certains programmes qui les utilisent ajoute une
attente après une erreur, de façon justement à ne pas répondre
trop vite.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Mais il me semblait que depuis un bon moment déjà, et notamment sur unix, les temps de réponse de vérification de mot passe étaient volontairement longs de manière à décourager des longs traitements.
Depuis au moins vingt ans:-). J'avais lu quelque chose de Richie déjà aux années 1980, où il disait avoir choisi un algorithme exprès qui prenait la plus grande partie d'une séconde à exécuter. Les machines sont évolues depuis, et la vérification d'un mot de passe Unix aujourd'hui dure bien peu -- quelque millisecondes, peut-être, voire moins d'une milliséconde.
Reste que certains programmes qui les utilisent ajoute une attente après une erreur, de façon justement à ne pas répondre trop vite.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Sylvain
James Kanze wrote on 24/06/2006 13:11:
Sylvain wrote:
ah c'est l'injection d'un buffer nul qui te gène !... je vois.
Je crois que c'est le code incorrect qui le gène. Lis au moins ce qu'il a écrit, et régarde les exemples de test.
ma réponse à son point n'a pas considérée toutes ses remarques et était inutilement sèche, dont acte, désolé Michel !
ils étaient toutefois non liés à mon simple propos (ne pas utiliser strcmp) et je n'ai pas eu envie de m'attarder dessus.
Le problème exposé, c'est un programme qui ne marche pas ; qui donne un mauvais résultat, permet dès débordements de buffer,
en effet, mais l'interrogation première du posteur tenait de comment fonctionne "strcmp" (l'auteur présumait un code retour 0/1, vrai ou faux).
preque par hasard, on touve dans le fil l'intégralité des codes retours (1, 0 et -1) et l'information sur le sens de ces codes. aurait-il utilisé par inexpérience stricmp ou strcmpi qu'apparemment on aurait choisi de ne pas répondre à /sa/ question: "comment faire en sorte de comparer tous les caractères".
j'ai voulu répondre à cette question par un (bool) state &= (ref[i] == cdt[i]); ou (byte) state |= (ref[i] ^ cdt[i]);
répondre au problème d'overflow était bien sur nécessaire, et cela avait été réalisé quand j'ai posté.
Ton code continue à présenter des erreurs sérieuses.
ce n'était pas un /code réponse au problème posé/ mais une illustration du fait qu'une solution basée sur char[] n'impliquait pas les "pas mal de complications" indiquées - je n'ai pas pour autant encourager cette utilisation ni prétendu qu'elle était parfaite - de manière factuelle il est évident qu'utiliser std::string est plus simple, ce fait est certain; annoncer par contre que toute autre solution sera bancale et/ou dispendieuse et/ou compliquée ne me parait pas honnête: la pédagogie passe selon moi par l'évaluation et la comparaison des solutions, pas par le simple dogme.
je peux calculer un digest sur tout nombre [...]
Manifestement, tu n'as pas compris le problème dans ton code.
je comprends très bien que le cas limite où la saisie n'inclut pas de marque de fin de ligne (telle que générée par les 3 exemples donnés) résulte en une valeur incorrecte de 'cnt'.
dans ces trois cas la probabilité que le hash de 20 octets aléatoires (dump mémoire) où fixe ( 0ff) matche celui du passphrase référence est nulle, donc le code ne délivrera pas des autorisations d'accès à tort (et ne provoque pas de B.Ovrflw).
En revanche, d'après tes postings, j'ai de très fortes doutes sur tes compétences en C++, ou dans les bases de la génie logicielle. [...]
tu confonds encore C++ et utilisation des bibliothèques standards. tu ne connais rien de mes éventuelles compétences - et btw, je ne comprends pas pourquoi cela te préoccuperais puisque cela n'a aucune raison d'intéresser quiconque ici. un ng n'est ni un démonstrateur, ni un étalonneur de compétences .
Sylvain.
James Kanze wrote on 24/06/2006 13:11:
Sylvain wrote:
ah c'est l'injection d'un buffer nul qui te gène !... je vois.
Je crois que c'est le code incorrect qui le gène. Lis au moins
ce qu'il a écrit, et régarde les exemples de test.
ma réponse à son point n'a pas considérée toutes ses remarques et était
inutilement sèche, dont acte, désolé Michel !
ils étaient toutefois non liés à mon simple propos (ne pas utiliser
strcmp) et je n'ai pas eu envie de m'attarder dessus.
Le problème exposé, c'est un programme qui ne marche pas ; qui
donne un mauvais résultat, permet dès débordements de buffer,
en effet, mais l'interrogation première du posteur tenait de comment
fonctionne "strcmp" (l'auteur présumait un code retour 0/1, vrai ou faux).
preque par hasard, on touve dans le fil l'intégralité des codes retours
(1, 0 et -1) et l'information sur le sens de ces codes. aurait-il
utilisé par inexpérience stricmp ou strcmpi qu'apparemment on aurait
choisi de ne pas répondre à /sa/ question: "comment faire en sorte de
comparer tous les caractères".
j'ai voulu répondre à cette question par un
(bool) state &= (ref[i] == cdt[i]);
ou (byte) state |= (ref[i] ^ cdt[i]);
répondre au problème d'overflow était bien sur nécessaire, et cela avait
été réalisé quand j'ai posté.
Ton code continue à présenter des erreurs sérieuses.
ce n'était pas un /code réponse au problème posé/ mais une illustration
du fait qu'une solution basée sur char[] n'impliquait pas les "pas mal
de complications" indiquées - je n'ai pas pour autant encourager cette
utilisation ni prétendu qu'elle était parfaite - de manière factuelle il
est évident qu'utiliser std::string est plus simple, ce fait est
certain; annoncer par contre que toute autre solution sera bancale et/ou
dispendieuse et/ou compliquée ne me parait pas honnête: la pédagogie
passe selon moi par l'évaluation et la comparaison des solutions, pas
par le simple dogme.
je peux calculer un digest sur tout nombre [...]
Manifestement, tu n'as pas compris le problème dans ton code.
je comprends très bien que le cas limite où la saisie n'inclut pas de
marque de fin de ligne (telle que générée par les 3 exemples donnés)
résulte en une valeur incorrecte de 'cnt'.
dans ces trois cas la probabilité que le hash de 20 octets aléatoires
(dump mémoire) où fixe ( 0ff) matche celui du passphrase référence est
nulle, donc le code ne délivrera pas des autorisations d'accès à tort
(et ne provoque pas de B.Ovrflw).
En revanche, d'après tes postings, j'ai
de très fortes doutes sur tes compétences en C++, ou dans les
bases de la génie logicielle. [...]
tu confonds encore C++ et utilisation des bibliothèques standards.
tu ne connais rien de mes éventuelles compétences - et btw, je ne
comprends pas pourquoi cela te préoccuperais puisque cela n'a aucune
raison d'intéresser quiconque ici. un ng n'est ni un démonstrateur, ni
un étalonneur de compétences .
ah c'est l'injection d'un buffer nul qui te gène !... je vois.
Je crois que c'est le code incorrect qui le gène. Lis au moins ce qu'il a écrit, et régarde les exemples de test.
ma réponse à son point n'a pas considérée toutes ses remarques et était inutilement sèche, dont acte, désolé Michel !
ils étaient toutefois non liés à mon simple propos (ne pas utiliser strcmp) et je n'ai pas eu envie de m'attarder dessus.
Le problème exposé, c'est un programme qui ne marche pas ; qui donne un mauvais résultat, permet dès débordements de buffer,
en effet, mais l'interrogation première du posteur tenait de comment fonctionne "strcmp" (l'auteur présumait un code retour 0/1, vrai ou faux).
preque par hasard, on touve dans le fil l'intégralité des codes retours (1, 0 et -1) et l'information sur le sens de ces codes. aurait-il utilisé par inexpérience stricmp ou strcmpi qu'apparemment on aurait choisi de ne pas répondre à /sa/ question: "comment faire en sorte de comparer tous les caractères".
j'ai voulu répondre à cette question par un (bool) state &= (ref[i] == cdt[i]); ou (byte) state |= (ref[i] ^ cdt[i]);
répondre au problème d'overflow était bien sur nécessaire, et cela avait été réalisé quand j'ai posté.
Ton code continue à présenter des erreurs sérieuses.
ce n'était pas un /code réponse au problème posé/ mais une illustration du fait qu'une solution basée sur char[] n'impliquait pas les "pas mal de complications" indiquées - je n'ai pas pour autant encourager cette utilisation ni prétendu qu'elle était parfaite - de manière factuelle il est évident qu'utiliser std::string est plus simple, ce fait est certain; annoncer par contre que toute autre solution sera bancale et/ou dispendieuse et/ou compliquée ne me parait pas honnête: la pédagogie passe selon moi par l'évaluation et la comparaison des solutions, pas par le simple dogme.
je peux calculer un digest sur tout nombre [...]
Manifestement, tu n'as pas compris le problème dans ton code.
je comprends très bien que le cas limite où la saisie n'inclut pas de marque de fin de ligne (telle que générée par les 3 exemples donnés) résulte en une valeur incorrecte de 'cnt'.
dans ces trois cas la probabilité que le hash de 20 octets aléatoires (dump mémoire) où fixe ( 0ff) matche celui du passphrase référence est nulle, donc le code ne délivrera pas des autorisations d'accès à tort (et ne provoque pas de B.Ovrflw).
En revanche, d'après tes postings, j'ai de très fortes doutes sur tes compétences en C++, ou dans les bases de la génie logicielle. [...]
tu confonds encore C++ et utilisation des bibliothèques standards. tu ne connais rien de mes éventuelles compétences - et btw, je ne comprends pas pourquoi cela te préoccuperais puisque cela n'a aucune raison d'intéresser quiconque ici. un ng n'est ni un démonstrateur, ni un étalonneur de compétences .
Sylvain.
Sylvain
James Kanze wrote on 24/06/2006 13:11:
j'ai de très fortes doutes ...
moi aussi j'avais de très fort doutes constatant que 'Gabi Software' n'est enregistré sur aucun registre de commerce et 'gabi-soft.fr' non déclaré comme domaine.
ce nouveau 'neuf.fr' dissipe mes doutes, comme quoi il y a surement plein de façons d'être professionnel. :)
Sylvain.
James Kanze wrote on 24/06/2006 13:11:
j'ai de très fortes doutes ...
moi aussi j'avais de très fort doutes constatant que 'Gabi Software'
n'est enregistré sur aucun registre de commerce et 'gabi-soft.fr' non
déclaré comme domaine.
ce nouveau 'neuf.fr' dissipe mes doutes, comme quoi il y a surement
plein de façons d'être professionnel. :)
moi aussi j'avais de très fort doutes constatant que 'Gabi Software' n'est enregistré sur aucun registre de commerce et 'gabi-soft.fr' non déclaré comme domaine.
ce nouveau 'neuf.fr' dissipe mes doutes, comme quoi il y a surement plein de façons d'être professionnel. :)
