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é dansSociété numérique

16/01/2014
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.

30
Avatar de l'auteur

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Technique contre marketing

17:36 Soft 6
Einstein avec des qubits en arrière plan

Informatique quantique, qubits : avez-vous les bases ?

Q-Doliprane sur demande

16:10 HardScience 6
Notifications iPhone

Surveillance des notifications : un sénateur américain demande la fin du secret

De qui ? Quand ? Comment ?

12:00 DroitSécu 13

Sommaire de l'article

Introduction

Un stockage en clair des identifiants 

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

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Soft 6
Einstein avec des qubits en arrière plan

Informatique quantique, qubits : avez-vous les bases ?

HardScience 6
Notifications iPhone

Surveillance des notifications : un sénateur américain demande la fin du secret

DroitSécu 13

En ligne, les promos foireuses restent d’actualité

DroitWeb 16

#LeBrief : modalité des amendes RGPD, cyberattaque agricole, hallucinations d’Amazon Q, 25 ans d’ISS

Logo Twitch

Citant des « coûts prohibitifs », Twitch quitte la Corée du Sud

ÉcoWeb 26
Formation aux cryptomonnaies par Binance à Pôle Emploi

Binance fait son marketing pendant des formations sur la blockchain destinées aux chômeurs

Éco 8
Consommation électrique du CERN

L’empreinte écologique CERN en 2022 : 1 215 GWh, 184 173 teqCO₂, 3 234 Ml…

Science 6
station électrique pour voitures

Voitures électriques : dans la jungle, terrible jungle, des bornes de recharge publiques

Société 73

#LeBrief : intelligence artificielle à tous les étages, fichier biométrique EURODAC

KDE Plasma 6

KDE Plasma 6 a sa première bêta, le tour des nouveautés

Soft 13
Un homme noir regarde la caméra. Sur son visage, des traits blancs suggèrent un traitement algorithmique.

AI Act et reconnaissance faciale : la France interpelée par 45 eurodéputés

DroitSociété 4
Api

La CNIL préconise l’utilisation des API pour le partage de données personnelles entre organismes

SécuSociété 3
Fouet de l’Arcep avec de la fibre

Orange sanctionnée sur la fibre : l’argumentaire de l’opérateur démonté par l’Arcep

DroitWeb 22
Bombes

Israël – Hamas : comment l’IA intensifie les attaques contre Gaza

IA 22

#LeBrief : bande-annonce GTA VI, guerre électronique, Spotify licencie massivement

Poing Dev

Le poing Dev – Round 7

Next 99
Logo de Gaia-X sour la forme d’un arbre, avec la légende : infrastructure de données en forme de réseau

Gaia-X « vit toujours » et « arrive à des étapes très concrètes »

WebSécu 6

Trois consoles portables en quelques semaines

Hard 37
Une tasse estampillée "Keep calm and carry on teaching"

Cyberrésilience : les compromis (provisoires) du trilogue européen

DroitSécu 3

#LeBrief : fuite de tests ADN 23andMe, le milliard pour Android Messages, il y a 30 ans Hubble voyait clair

#Flock a sa propre vision de l’inclusion

Flock 25
Un Sébastien transformé en lapin par Flock pour imiter le Quoi de neuf Docteur des Looney Tunes

Quoi de neuf à la rédac’ #10 : nous contacter et résumé de la semaine

44
Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (30)


Jarodd Abonné
Hier à 14h58


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
Hier à 14h59

C’est induit par la citation…


feuille_de_lune
Hier à 15h00






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
Hier à 15h06

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
Hier à 15h08

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


gogo77
Hier à 15h13

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
Hier à 15h28






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é
Hier à 15h37






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é
Hier à 15h38


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é
Hier à 15h38

rm mycomment.txt


anonyme_751eb151a3e6ce065481d43bf0d18298
Hier à 15h42






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
Hier à 15h47






Nycom a écrit :

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


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



jojofoufou
Hier à 16h40

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
Hier à 16h57

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


pyro-700
Hier à 17h12

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


kikoo25
Hier à 17h27


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é
Hier à 21h40

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
Hier à 23h38






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
Hier à 08h49






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é
Hier à 10h46






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é
Hier à 10h53






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é
Hier à 10h59






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
Hier à 12h00






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
Hier à 12h34






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
Hier à 14h51

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
Hier à 16h12






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
Hier à 16h56






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
Hier à 20h37






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
Hier à 21h44






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
Hier à 02h12






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=" />