C'est valide c'est valide, je vois pas ce que ca va changer de filer toutes les sources au monde entier,
Ben vu que "Dieu" dis que c'est valide sans montrer en quoi c'est valide, ca permet aux autres de vérifier ses dires.
Si ensuite tu as plus de choses (labo de certif indépendant, etc...) c'est pas franchement la meme chose (chose que j'avais déjà dites).
Mais si tu étais si sur de ton algo et de sa fiabilité, tu n'aurais pas de problème à le filer au monde entier, vu que tu serais sur qu'il ne risquerais rien.
Alors, les clients en question, c'est des banques.
Ce qui en soit ne veut rien dire.
Je peux te citer une anecdote d'une banque pour générer des clés de CB, qui
avait une procédure très lourde de sécurité physique pour accéder au terminal qui générait la clé, et qui générait des clé de 40 bits sur le terminal parce que quand ils générait lés clés de 700 bits "ça plantait" (le temps d'attente était tellement long qu'ils pensaient que ça plantaient).
Alors certe, la situation à, je l'espère, changé. Mais le role d'un client, même si c'est une banque, ce n'est pas de vérifier la fiabilité/pertinence d'une solution vu qu'ils l'achètent! (et vu les retours que j'ai sur une grosse banque au niveau mondial, ca je peux l'affirmer).
Si le process d'authent' est en cause, devines quoi?
Avant de tomber lors de l'audit sur le process d'authent ca mettre un certain temps. Et les marketeux pourraient très bien dire que non leur produit marche très bien mais que c'est l'intégration qui a pu causer un bug (c'est la faute du client) ou tout autre connerie.
Ne t'inquiète pas, si tu crois que le risque empêche les gens de jouer, tu es vraiment mal renseigné.
On est donc en droit de penser que si le fournisseur ne s'est jamais fait engueuler comme du poisson pourri, c'est que le systeme n'a jamais ete penetre.
On que l'audit n'a pas trouvé ça comme faille, ou que la banque a utiliser ton processus d'auth en COMPLEMENT d'autres systemes, et que ces systemes soient fiables, ou que l'ensemble des systemes de sécu est fiable.
Enfin ta preuve de sécurité me fait froid dans le dos "le client à pas raler, c'est donc que c'est fiable".
Par contre les mechants auquels je faisais reference, c'est les gens dont les clients veulent precisement se proteger. Et a eux, ca serait completement CON de leur donner des infos supplementaires (meme s'ils iront pas bien loin sans les cles des clients a attaquer).
Si les infos qu'ils ont ils ne peuvent rien en faire, ce n'est pas complètement con
1°) tu permet à ton client de choisir ta solution en informant que
- il peut auditer lui meme la solution si il en ressent le besoin
- il pourra, si il le souhaite, changer de fournisseur tout en conservant un systeme compatible.
2°) vu que tu affirme que ton système est fiable, les attaquants possibles ne pourront rien trouver.
3°) La communauté des cryptologues et/ou des agences gouvernementales pourront considérer votre implémentation comme une "best practice", vous faisant une pub importante par conséquent/
Heureusement que t'es la dis donc, ils y avaient pas pense avant toi...
Les sarcasme de quelqu'un qui considère qu'une preuve de sécurité c'est que son client n'as pas encore eu d'attaques sur le produit/ne l'a pas détecté, me font ni froid ni chaud.
[^] # Re: 3D Secure
Posté par briaeros007 . En réponse au journal "MasterCard Secure Code" ou "Verified by Visa" ou comment ne plus assumer. Évalué à 2.
Ben vu que "Dieu" dis que c'est valide sans montrer en quoi c'est valide, ca permet aux autres de vérifier ses dires.
Si ensuite tu as plus de choses (labo de certif indépendant, etc...) c'est pas franchement la meme chose (chose que j'avais déjà dites).
Mais si tu étais si sur de ton algo et de sa fiabilité, tu n'aurais pas de problème à le filer au monde entier, vu que tu serais sur qu'il ne risquerais rien.
Alors, les clients en question, c'est des banques.
Ce qui en soit ne veut rien dire.
Je peux te citer une anecdote d'une banque pour générer des clés de CB, qui
avait une procédure très lourde de sécurité physique pour accéder au terminal qui générait la clé, et qui générait des clé de 40 bits sur le terminal parce que quand ils générait lés clés de 700 bits "ça plantait" (le temps d'attente était tellement long qu'ils pensaient que ça plantaient).
Alors certe, la situation à, je l'espère, changé. Mais le role d'un client, même si c'est une banque, ce n'est pas de vérifier la fiabilité/pertinence d'une solution vu qu'ils l'achètent! (et vu les retours que j'ai sur une grosse banque au niveau mondial, ca je peux l'affirmer).
Si le process d'authent' est en cause, devines quoi?
Avant de tomber lors de l'audit sur le process d'authent ca mettre un certain temps. Et les marketeux pourraient très bien dire que non leur produit marche très bien mais que c'est l'intégration qui a pu causer un bug (c'est la faute du client) ou tout autre connerie.
Ne t'inquiète pas, si tu crois que le risque empêche les gens de jouer, tu es vraiment mal renseigné.
On est donc en droit de penser que si le fournisseur ne s'est jamais fait engueuler comme du poisson pourri, c'est que le systeme n'a jamais ete penetre.
On que l'audit n'a pas trouvé ça comme faille, ou que la banque a utiliser ton processus d'auth en COMPLEMENT d'autres systemes, et que ces systemes soient fiables, ou que l'ensemble des systemes de sécu est fiable.
Enfin ta preuve de sécurité me fait froid dans le dos "le client à pas raler, c'est donc que c'est fiable".
Par contre les mechants auquels je faisais reference, c'est les gens dont les clients veulent precisement se proteger. Et a eux, ca serait completement CON de leur donner des infos supplementaires (meme s'ils iront pas bien loin sans les cles des clients a attaquer).
Si les infos qu'ils ont ils ne peuvent rien en faire, ce n'est pas complètement con
1°) tu permet à ton client de choisir ta solution en informant que
- il peut auditer lui meme la solution si il en ressent le besoin
- il pourra, si il le souhaite, changer de fournisseur tout en conservant un systeme compatible.
2°) vu que tu affirme que ton système est fiable, les attaquants possibles ne pourront rien trouver.
3°) La communauté des cryptologues et/ou des agences gouvernementales pourront considérer votre implémentation comme une "best practice", vous faisant une pub importante par conséquent/
Heureusement que t'es la dis donc, ils y avaient pas pense avant toi...
Les sarcasme de quelqu'un qui considère qu'une preuve de sécurité c'est que son client n'as pas encore eu d'attaques sur le produit/ne l'a pas détecté, me font ni froid ni chaud.