L'application Starbucks pour iOS stocke les identifiants en clair

L’application Starbucks pour iOS stocke les identifiants en clair

Ajoutons le problème de la réutilisation des mots de passe...

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

16/01/2014 3 minutes
30

L'application Starbucks pour iOS stocke les identifiants en clair

Alors que le monde de la sécurité est en pleine ébullition suite aux révélations d’Edward Snowden sur la surveillance de masse opérée par les États-Unis, la société Starbucks vient d’avouer que les mots de passe enregistrés par son application américaine pour iOS n’étaient pas chiffrés.

 starbucksstarbucksstarbucksstarbucks

Un stockage en clair des identifiants 

Au sein de la plupart des applications mobiles, le stockage des mots de passe se fait sous une forme sécurisée, autrement dit chiffrée. Ce n’est toutefois pas le cas de l’application américaine Starbucks sur iOS. C’est en effet ce que viennent d’admettre les dirigeants de la fameuse enseigne. Les mots de passe sont ainsi stockés en clair au sein de la zone de stockage de l’application.

 

En quoi est-ce un problème ? En cas de raccordement de l’iPhone sur un ordinateur, cela signifie une transmission en clair lors de la sauvegarde. Selon ComputerWorld, il serait également possible d’obtenir très facilement les informations d’identification en récupérant les fichiers d’erreurs générés par l’application.

 

La faille a été initialement rapportée à Starbucks par le chercheur Daniel Wood, qui avait expliqué sa trouvaille sur Seclists. Starbucks avait bien été avertie, mais la mise à jour intervenue entre temps n’a pas corrigé le problème. Dans son billet initial, Wood rappelle qu’un développeur ne devrait jamais utiliser l’espace local pour stocker des identifiants. L’utilisateur devrait s’authentifier via une méthode en ligne et une connexion chiffrée.

Le problème de la réutilisation des mots de passe 

Dans la pratique, le risque n’est évidemment pas catastrophique. En cas de piratage de ces données, il ne s’agit que des identifiants et de l’adresse email. Aucune donnée vraiment sensible n’est donc piratable, mais la situation pourrait être pire, et c’est surtout l’inaction de Starbucks qui est pointée du doigt par le chercheur. Après tout, l’adresse postale ou encore le numéro de carte bancaire pourraient être inclus pour simplifier les achats, ce qui causerait alors de vrais problèmes.

 

Cependant, il ne faut pas oublier qu’il existe un danger connexe et qui n’est pas forcément visible tout de suite : la réutilisation des mots de passe. Même si les informations ne sont pas forcément dangereuses prises isolément, la « fainéantise » des utilisateurs pourrait leur causer du tort. Beaucoup se servent en effet des mêmes identifiants un peu partout, notamment quand les comptes sont créés sur la base d’une adresse email : on réutilise alors la même, avec un même mot de passe pour aller plus vite. Auquel cas, le vol de ces informations pourrait s’avérer plus dangereux.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un stockage en clair des identifiants 

Le problème de la réutilisation des mots de passe 

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (30)


Jarodd Abonné
Le 16/01/2014 à 14h 58



Beaucoup se servent en effet des mêmes identifiants un peu partout, notamment quand les comptes sont créés sur la base d’une adresse email : on réutilise alors la même, avec un même mot de passe pour aller plus vite.





Et parfois, le mdp associé à l’e-mail pour un compte sur un site, est le même pour accéder à ladite boite e-mail… <img data-src=" /> <img data-src=" />


seboquoi
Le 16/01/2014 à 14h 59

C’est induit par la citation…


feuille_de_lune
Le 16/01/2014 à 15h 00







Jarodd a écrit :



Et parfois, le mdp associé à l’e-mail pour un compte sur un site, est le même pour accéder à ladite boite e-mail… <img data-src=" /> <img data-src=" />





ce n’est pas juste parfois, c’est très souvent le cas même <img data-src=" />



Jossy
Le 16/01/2014 à 15h 06

Quel intérêt d’une appli Starbucks honnêtement ? Trouver à quel coin de rue il n’y en a pas encore ? (vraie question, pas simple troll)


Nycom
Le 16/01/2014 à 15h 08

Un mot de passe est un authentifiant et non un identifiant.


gogo77
Le 16/01/2014 à 15h 13

Les mots de passes sont en clairs ou pas ? J’ai du mal à comprendre la news, parce que quand je lis identifiant, j’entend login, pas mot de passe.



Un identifiant permet justement d’identifier un utilisateur, ce que ne fait pas un mot de passe. Auquel cas, si ce n’est que les logins qui sont stockés, ceux qui mettraient la main dessus ne pourraient pas en faire grand chose.





EDIT : la prochaine fois je lirai mieux la news, c’est précisé dans l’article (mais ça reste ambigüe) <img data-src=" />


misterB
Le 16/01/2014 à 15h 28







Jossy a écrit :



Quel intérêt d’une appli Starbucks honnêtement ? Trouver à quel coin de rue il n’y en a pas encore ? (vraie question, pas simple troll)





Payer avec, récupérer ses points fidélité et autre trucs inutiles <img data-src=" />



par contre il faut vouloir boire du mauvais café hors de prix <img data-src=" />



NiCr Abonné
Le 16/01/2014 à 15h 37







misterB a écrit :



par contre il faut vouloir boire du mauvais café hors de prix <img data-src=" />







Leur café filtre est plus que correct.



Mais c’est vrai que c’est loin d’être leur produit phare. On va surtout là bas pour s’enfiler 100g de sucre liquide aromatisé au café <img data-src=" />



John Shaft Abonné
Le 16/01/2014 à 15h 38



L’application Starbucks pour iOS stocke les identifiants en clair





C’est un peu fort de café ! <img data-src=" />



(désolé il fallait que je la fasse <img data-src=" />)


NiCr Abonné
Le 16/01/2014 à 15h 38

rm mycomment.txt








John Shaft a écrit :



C’est un peu fort de café ! <img data-src=" />



(désolé il fallait que je la fasse <img data-src=" />)





<img data-src=" />



J’allais la faire <img data-src=" />



maestro321
Le 16/01/2014 à 15h 47







Nycom a écrit :



Un mot de passe est un authentifiant et non un identifiant.





+1, rien de choquant à stocker les identifiants en clair.



jojofoufou
Le 16/01/2014 à 16h 40

C’est au faux problème, certes les devs auraient pu chiffrer le mot de passe avec “Data protection”, m’enfin les informations ne sont pas nécessairement sensibles, d’autant plus que difficilement accessibles a distance (hors jailbreak).



Le plus grave serais que les mots de passes soient stockées en clair ou avec un algo de hash dépassé (MD5) sur leurs serveurs.


anarkhki
Le 16/01/2014 à 16h 57

logique pour une boite où l’on écrit les prénoms des clients sur les produits


pyro-700
Le 16/01/2014 à 17h 12

c’est fort de café starbuck que de facilite le travail de la NSA. <img data-src=" />


kikoo25
Le 16/01/2014 à 17h 27



la société Starbucks vient d’avouer que les mots de passe enregistrés par son application américaine pour iOS n’étaient pas chiffrés



FileZilla fait pareil. L’argument donné étant qu’entre un mot de passe en clair et un mot de passe pseudo chiffré (car c’est bien de ça qu’il s’agit, à moins d’imposer à l’utilisateur de rentrer la clé de chiffrement à chaque utilisation), la différence ne mérite pas l’effort.

https://forum.filezilla-project.org/viewtopic.php?f=1&t=9543



Après, on est d’accord ou pas, mais en tout cas je vois pas pourquoi on jetterait la pierre spécifiquement sur Starbucks. La sécurité sur les smartphones est une grosse blague de toute façon, en l’état actuel des choses. Si on veut la jouer en mode parano (le seul mode qui marche en sécurité), on considère que le smartphone est en permanence compromis et on ne met dessus que des données qu’on peut accepter de voir fuiter.


JCLB Abonné
Le 16/01/2014 à 21h 40

Quelqu’un a t’il un site simple et clair sur les best practices en ce qui concerne le chiffrement des com, des pass, le non envoi de passe par mail, le hashage,…





Voilà par exemple le retour d’une société l’autre jour, après que je leur ai indiqué que je n’appréciais pas que le pass que je saisisse à l’inscription arrive en clair dans mes mails, déjà car il est lisible par les opérateurs Tier 1, 2, et les fouineurs gouvernementaux. Ensuite car c’est indexe par le serveur mail pour la recherche. <img data-src=" />





Réponse d’un support:

“Effectivement le mot de passe n’est pas crypté, mais cela n’aurait aucun intérêt de le crypter dans un mail de confirmation censé être conservé par le conso au cas où il oublie ses identifiants.

De même pour le mail de mot de passe oublié : nous sommes bien obligés d’envoyer le mot de passe tel quel.

De plus, aucune données de ce type n’est stockée.





<img data-src=" /><img data-src=" /><img data-src=" />


kikoo25
Le 16/01/2014 à 23h 38







JCLB a écrit :



Réponse d’un support:

“Effectivement le mot de passe n’est pas crypté, mais cela n’aurait aucun intérêt de le crypter dans un mail de confirmation censé être conservé par le conso au cas où il oublie ses identifiants.

De même pour le mail de mot de passe oublié : nous sommes bien obligés d’envoyer le mot de passe tel quel.

De plus, aucune données de ce type n’est stockée.





<img data-src=" /><img data-src=" /><img data-src=" />





Ca serait pas firstheberg, des fois? <img data-src=" /> Ils avaient fait une réponse de ce genre sur leur forum, il y a longtemps.

Un point pour eux à propos du mot de passe oublié, quand même. Dans ce cas (et uniquement dans ce cas), il faut bien envoyer un truc en clair, que ce soit un mot de passe (temporaire!) ou un token de réinitialisation (cela dit c’est vrai aussi que GnuPG c’est pas pour les chiens).

Mais sinon le compte e-mail n’est pas censé être une archive de mots de passe pour les têtes en l’air… Le pire c’est les imbéciles qui t’envoient ton mot de passe en clair _à chaque fois que tu le changes_ <img data-src=" />



Anonyme
Le 17/01/2014 à 08h 49







Jarodd a écrit :



Et parfois, le mdp associé à l’e-mail pour un compte sur un site, est le même pour accéder à ladite boite e-mail… <img data-src=" /> <img data-src=" />







Oui c’est exactement ce que dit ce que tu as quote



JCLB Abonné
Le 17/01/2014 à 10h 46







kikoo25 a écrit :



Ca serait pas firstheberg, des fois? <img data-src=" /> Ils avaient fait une réponse de ce genre sur leur forum, il y a longtemps.

Un point pour eux à propos du mot de passe oublié, quand même. Dans ce cas (et uniquement dans ce cas), il faut bien envoyer un truc en clair, que ce soit un mot de passe (temporaire!) ou un token de réinitialisation (cela dit c’est vrai aussi que GnuPG c’est pas pour les chiens).

Mais sinon le compte e-mail n’est pas censé être une archive de mots de passe pour les têtes en l’air… Le pire c’est les imbéciles qui t’envoient ton mot de passe en clair _à chaque fois que tu le changes_ <img data-src=" />





Ce dernier point qignifie qu’ils ne hash même pas ton pass, et ça m’étonnerait qu’il le chiffre.





Dans mon cas ils ne stockent pas le MDP, et tu dois changer si mdp perdu.

En attendant y’a pas à envoyer le pass à l’inscription par mail.



Jarodd Abonné
Le 17/01/2014 à 10h 53







ff9098 a écrit :



Oui c’est exactement ce que dit ce que tu as quote







La citation parle de réutiliser un même couple email/mdp pour différents sites. Je parlais de réutiliser ce couple pour l’accès à cette boite e-mail.



Jarodd Abonné
Le 17/01/2014 à 10h 59







JCLB a écrit :



Réponse d’un support:

[…]







J’ai eu exactement la même réponse du SAV d’Oxybul (Fnac Eveil & jeux). Il faut les dénoncer, aucune raison de cacher le nom de ses boîtes qui jouent avec nos données parce qu’ils sont INcompétents ou ont la flemme d’ajouter une simple fonctione de hashage du mdp <img data-src=" />



kikoo25
Le 17/01/2014 à 12h 00







Jarodd a écrit :



Il faut les dénoncer, aucune raison de cacher le nom de ses boîtes qui jouent avec nos données parce qu’ils sont INcompétents ou ont la flemme d’ajouter une simple fonctione de hashage du mdp <img data-src=" />





Euh… Dans ce que JCLB raconte, rien n’indique que les mdp soient stockés en clair:




  • envoi à la création: ça n’empêche pas que le mdp soit chiffré également à la cr’éation

  • envoi d’un nouveau mot de passe si oubli: on parle bien d’un nouveau mot de passe, là, pas du renvoi de l’ancien (ou alors le post était pas clair et oui c’est une abomination… mais en effet il y a des fous qui le font encore…)



RaoulC
Le 17/01/2014 à 12h 34







kikoo25 a écrit :



FileZilla fait pareil. L’argument donné étant qu’entre un mot de passe en clair et un mot de passe pseudo chiffré (car c’est bien de ça qu’il s’agit, à moins d’imposer à l’utilisateur de rentrer la clé de chiffrement à chaque utilisation), la différence ne mérite pas l’effort.

https://forum.filezilla-project.org/viewtopic.php?f=1&t=9543



.







Ouais. De toute façon, si il s’agit du protocole FTP, tout circule en clair (je parle pas de FTPS ou autre). Et le projet étant comment dire, open source, rien de plus facile que de reverser l’algo de chiffrement si il existait. Et sinon, il reste la rétro-ingénierie.



Plus largement, les applications sur le pc qui retiennent les mots de passe ne les chiffrent généralement pas. Et même quand c’est fait, au moment de recracher le mot de passe au site web, il faut bien qu’il ressorte en clair le vilain mot de passe.



Alors oui, le chiffrement peut arrêter le keke du dimanche qui veut lire le mot de passe, mais même le keke peut trouver des outils tout prêt pour le déchiffrer pour lui. Et les malwares intègrent les méthodes de déchiffrement, donc bon …



Hors mot de passe maitre….Mais bon, le mot de passe maitre ca fait suer les michus<img data-src=" />



L’important, c’est que le stockage soit sécurisé sur le serveur distant.



Hurloon
Le 17/01/2014 à 14h 51

Starbucks, c’est bien entreprise qui ne paye pas ses impôts en France? Bon alors on s’en cogne de son application et de ses failles.


Khalev
Le 17/01/2014 à 16h 12







RaoulC a écrit :



(…)





Ouch, je peux corriger 2-3 trucs?





RaoulC a écrit :



Ouais. De toute façon, si il s’agit du protocole FTP, tout circule en clair (je parle pas de FTPS ou autre). Et le projet étant comment dire, open source, rien de plus facile que de reverser l’algo de chiffrement si il existait. Et sinon, il reste la rétro-ingénierie.





+1 pour le FTP où tout passe en clair.

Cependant : pour stocker un mot de passe en général on le stock sous forme de hash. Or les algo de hash sont publiques, documentés et (censés être) non réversible. C’est à dire que si je te donne A et que l’algo te retourne B, si je te donne B tu ne peux pas retrouver A en prenant l’algo à l’envers.

Et en plus en général pour les mots de pass on y ajoute du sel (c’est à dire un nombre, connu du serveur seul que l’on mélange au mot de passe envoyé).

Du coup quand tu envoies A, le serveur va faire le hash de A+sel.

Donc même si tu sais que A=&gt;B, si tu trouves que le hash de mon compte c’est B, ça ne veut pas dire que mon mdp est A.

L’intérêt du sel et d’éviter l’utilisation de “Rainbow table” qui sont des tables qui te donnent pour chaque B possible un A correspondant. Mais vu que le sel est sensé être unique à chaque serveur ça demanderait de regénérer la Rainbow table pour chaque sel existant. Ce qui devient impossible. (générer une rainbow table prend des années)

Et concernant le chiffrement des communications la sécurité repose sur la clé, pas sur l’algo. Idem les algos sont publiques, documentées & co, ce qui est important c’est la clé (privée pour les algo asymétriques). Dans certains cas très très particuliers on va utiliser des algos secret, mais en général c’est parce qu’il y a des limitations de ressources et que les algos publiques suffisamment léger sont déjà tous cassés.





RaoulC a écrit :



Plus largement, les applications sur le pc qui retiennent les mots de passe ne les chiffrent généralement pas. Et même quand c’est fait, au moment de recracher le mot de passe au site web, il faut bien qu’il ressorte en clair le vilain mot de passe.





C’est normal c’est en local et ça reste en local, si après tu es assez fou pour balancer ton mot de passe sur une connexion non-sécurisée, c’est pas la faute au porte-clés. Les portes-clés c’est très pratique pour éviter de retaper ses mots-de-passe. Les mdp maîtres ne sont utiles que pour empêcher la personne qui est à l’instant t sur ton PC d’accéder tout de suite à ton mdp. En fonction de où se situe le PC et du type de PC c’est pas déconnant de pas mettre de mdp maître.





RaoulC a écrit :



Alors oui, le chiffrement peut arrêter le keke du dimanche qui veut lire le mot de passe, mais même le keke peut trouver des outils tout prêt pour le déchiffrer pour lui. Et les malwares intègrent les méthodes de déchiffrement, donc bon …





Euh… si les chiffrements étaient si faciles à craquer crois-moi que l’e-commerce se serait cassé la gueule depuis longtemps au vu du nombre d’achats frauduleux qu’il y aurait. Les malwares se démerdent surtout pour chopper les clés où les données quand elles sont encore en clair (ou après qu’elles ait été déchiffrées).





RaoulC a écrit :



L’important, c’est que le stockage soit sécurisé sur le serveur distant.





L’important c’est que la chaîne entre ton PC et le serveur distant soit sécurisée. Si, au moment où les données arrivent à ta carte réseau, elles ne sont pas chiffrées tu peux les considérer comme corrompues (hors proxy chiffrant/vpn au niveau du routeur local).



kikoo25
Le 17/01/2014 à 16h 56







Khalev a écrit :



Ouch, je peux corriger 2-3 trucs?

[…..]





On parle du stockage sur le PC client pour une utilisation cliente (envoyer son login+mdp), pas du stockage sur le serveur pour une utilisation serveur (réceptionner et vérifier). Sur le serveur on peut (il faut) hacher. Sur le client, il faut disposer du mot de passe source d’une manière ou d’une autre: soit 1) stocké en clair, soit 2) stocké chiffré, voire soyons fou 3) stocké haché avec une combine du genre un premier hachage local puis un autre sur le serveur distant - mais l’intérêt de la chose est franchement limité pour ne pas dire nul (ça empêche de deviner le mdp d’origine, mais la version hachée permet de se connecter).



On oublie le 3) parce que voilà. On dit que le 1) c’est mal, et maintenant on va voir si le 2) c’est mieux. Donc le mdp est chiffré, maintenant 2 options:

a) il est chiffré avec un clé… stockée. Et là pour déchiffrer, ben oui c’est du niveau du “chiffrement [qui] peut [à peine] arrêter le keke du dimanche”. Pas parce que les algos de chiffrement sont nuls, juste parce qu’ils sont connus (ou trouvables/devinables), et que la clé est en libre service

b) il est chiffré avec un mot de passe maître. Là on est d’accord, c’est la seule option vraiment sécurisée. Seulement en fait en pratique, ben au lieu de te retrouver à taper ton mot de passe Starbucks, tu te retrouves à taper ta clé. Moralité le stockage du mot de passe a servi à rien.



(bon en pratique pour moi la bonne option c’est 2c) un gestionnaire de mots de passe genre KeePass)



(sinon au passage, pour un mot de passe en carton - ie un type de mot de passe très répandu <img data-src=" /> - bruteforcer son hash peut être relativement rapide)



RaoulC
Le 17/01/2014 à 20h 37







Khalev a écrit :



Ouch, je peux corriger 2-3 trucs?



+1 pour le FTP où tout passe en clair.

Cependant : pour stocker un mot de passe en général on le stock sous forme de hash. Or les algo de hash sont publiques, documentés et (censés être) non réversible. C’est à dire que si je te donne A et que l’algo te retourne B, si je te donne B tu ne peux pas retrouver A en prenant l’algo à l’envers.

Et en plus en général pour les mots de pass on y ajoute du sel (c’est à dire un nombre, connu du serveur seul que l’on mélange au mot de passe envoyé).

Du coup quand tu envoies A, le serveur va faire le hash de A+sel.

Donc même si tu sais que A=&gt;B, si tu trouves que le hash de mon compte c’est B, ça ne veut pas dire que mon mdp est A.

L’intérêt du sel et d’éviter l’utilisation de “Rainbow table” qui sont des tables qui te donnent pour chaque B possible un A correspondant. Mais vu que le sel est sensé être unique à chaque serveur ça demanderait de regénérer la Rainbow table pour chaque sel existant. Ce qui devient impossible. (générer une rainbow table prend des années)

Et concernant le chiffrement des communications la sécurité repose sur la clé, pas sur l’algo. Idem les algos sont publiques, documentées & co, ce qui est important c’est la clé (privée pour les algo asymétriques). Dans certains cas très très particuliers on va utiliser des algos secret, mais en général c’est parce qu’il y a des limitations de ressources et que les algos publiques suffisamment léger sont déjà tous cassés.



C’est normal c’est en local et ça reste en local, si après tu es assez fou pour balancer ton mot de passe sur une connexion non-sécurisée, c’est pas la faute au porte-clés. Les portes-clés c’est très pratique pour éviter de retaper ses mots-de-passe. Les mdp maîtres ne sont utiles que pour empêcher la personne qui est à l’instant t sur ton PC d’accéder tout de suite à ton mdp. En fonction de où se situe le PC et du type de PC c’est pas déconnant de pas mettre de mdp maître.



Euh… si les chiffrements étaient si faciles à craquer crois-moi que l’e-commerce se serait cassé la gueule depuis longtemps au vu du nombre d’achats frauduleux qu’il y aurait. Les malwares se démerdent surtout pour chopper les clés où les données quand elles sont encore en clair (ou après qu’elles ait été déchiffrées).



L’important c’est que la chaîne entre ton PC et le serveur distant soit sécurisée. Si, au moment où les données arrivent à ta carte réseau, elles ne sont pas chiffrées tu peux les considérer comme corrompues (hors proxy chiffrant/vpn au niveau du routeur local).







Merci, je sais ce qu’est un hash, le chiffrement symétrique et asymétrique.

<img data-src=" />



Je sais aussi que pour bien faire il faut stocker des hash..

Sauf que là, on parle de stockage dans une appli client…



Tu sais très bien que le serveur qui t’identifie stocke un hash, et qu’il le compare a la version hashée du mdp que tu est bien obligé de fournir tel quel (sans parler du moyen de transmission, chiffré ou pas)

Et je parle pas du salage encore :)



Firefox chiffre peut etre les informations (ou pas, pas fouillé)



Ce que je sais, c’est que en tout cas c’est l’enfance de l’art de répliquer la manière dont FF décode les MDP pour les coller dans les formulaires des sites web. Parce que le navigateur DOIT les balancer en clair a un moment ou un autre, la méthode est reproductible logiciellement. Si password maitre il y a, c’est déjà autre chose <img data-src=" />



La dernière fois que j’ai regardé, dans cuteftp on avait des XOR tout bête, dans AceFtp (FtpExpert) c’est juste une permutation de caractères…



Quand à la comparaison avec le E-commerce, comment dire?

SSL c’est autrement plus complexe. Clef publique privée, clef de transaction jetable… ce qui est autrement plus complexe et surtout différent d’un mot de passe fixe. Pas spécialiste de la chose mais bon je pense pas trop me tromper que cela na vraiment rien, mais rien a voir.



Sécuriser une donnée (dans ce cas précis) sans intervention de l’utilisateur pour la déchiffrer (mot de passe, donnée autre), cela sous entend que le logiciel peut le faire tout seul, donc a priori qu’il connait la CLEF sans toi.



Bien entendu, si je me trompe ou que l’on me donne des contre exemples, je suis toujours interessé, je suis treeeeees loin d’avoir la science infuse <img data-src=" />








kikoo25
Le 17/01/2014 à 21h 44







RaoulC a écrit :



Quand à la comparaison avec le E-commerce, comment dire?

SSL c’est autrement plus complexe. Clef publique privée, clef de transaction jetable… ce qui est autrement plus complexe et surtout différent d’un mot de passe fixe. Pas spécialiste de la chose mais bon je pense pas trop me tromper que cela na vraiment rien, mais rien a voir.





Bah non, dans les 2 cas on peut utiliser des algo bien costauds… Seulement, comme on a vu, soit le programme a la clé et du coup que l’algo soit costaud ou nul ça revient au même, soit le programme a pas la clé et alors faut se taper un mdp maître donc un peu inutile de stocker le mdp…



RaoulC
Le 18/01/2014 à 02h 12







kikoo25 a écrit :



Bah non, dans les 2 cas on peut utiliser des algo bien costauds… Seulement, comme on a vu, soit le programme a la clé et du coup que l’algo soit costaud ou nul ça revient au même, soit le programme a pas la clé et alors faut se taper un mdp maître donc un peu inutile de stocker le mdp…





Ouais, je me suis mal exprimé <img data-src=" />



Je voulais dire que cela ne servait a rien, mais j’ai pensé aussi à la finalité (et au comment ca marche) du coup mon propos est confus.





Pardon aux familles <img data-src=" />