Google, gmail, la sécurité et son écosystème

Perso je paie 10$ par an pour gmail pour du 20 gigas.

Et t’as un SAV ? Un interlocuteur quelconque ? Parce que ça peut être intéressant, oui.

Pas testé le sav encore :confused:

la question que je me pose est “que peut on faire avec les mots de passe d’application” ?

Parce que j’aime bien l’idée d’avoir un mot de passe particulier pour pidgin par exemple. Surtout que Pidgin stock les mot de passe en clair !
Donc dans le cas ou je passe à la 2 step activation, que je génère un mot de passe pour pidgin, et que se mot de passe se fait voler. Qu’est ce qui se passe ? Est-ce que le voleur peut acceder a mon compte gmail et changer mon mot de passe et autre ? Ou est-ce qu’il a simplement la possibilité de se connecter en lecture ?

Parce que si ces mots de passes d’application permettent de se connecter de la meme facon à son compte, ca sert à rien au final.

@Ben : nop, les mots de passes sont uniques et ne servent qu’à autoriser une application, au cas par cas. Sur ton compte Gmail depuis ton ordinateur, tu continues de te connecter avec ton MDP actuel, qui est vérifié tous les 30 jours par un SMS (et à chaque fois que tu te connectes à Gmail sur un autre appareil).

oui j’ai compris, mais qu’est-ce qui différencie une application d’une autre ? ou d’une personne ?
Le mot de passe est valide par définition, sinon l’application se ferait jeter.

Donc la question reste entière : si quelqu’un un récupère d’une manière ou d’une autre le mot de passe dédié à une application, que peut il faire avec ? Au moins la même chose que ce que pouvait faire l’application ! D’où ma question.

Le mot de passe n’est valide qu’une fois :P. C’est plus une clef d’activation qu’un mot de passe, en fait, dans la mesure où il ne fonctionne qu’avec les applications qui le retiennent. Dès qu’une fonction Gmail native et “dynamique” est requise, il y a besoin de mettre un code reçu par sms. Et dans le cas improbable où un système choperait le mdp à 16 caractères alphanumériques aléatoires, tu as toujours le contrôle, puisque tu révoques ce mdp en un clic depuis ton compte mail (qui n’est accessible que via la combinaison mdp perso + sms). Toujours dans ce cas improbable, il ne pourrait typiquement rien en faire, parce que même sur un hardware/software similaire, le code ne serait plus valable : je regarde ma liste de codes et j’ai Galaxy S II 1, Galaxy S II 2, Galaxy S II 3 etc. qui correspondent aux moment où j’ai dû formater l’engin.

Donc même avec ce code, une tierce personne ne pourra ni l’utiliser dans une application, même similaire, ni sur un appareil, même similaire. J’ai du mal à voir quelle pourrait être l’utilité de le choper en fait.

Alors je comprends pas comment marche cette activation.
Pour reprendre l’exemple de Pidgin (un client gtalk), pour se connecter sur le reseau, il lui faut un couple login/mot de passe. Ce couple, il va l’utiliser à chaque fois qu’il va se connecter.
Pour le moment, comme pigdin stock les mots de passe en clair, je retape à chaque fois mon mot de passe google quand je le lance.

Si j’active le 2step, pidgin ne fonctionnera plus. Donc je génère un mot de passe d’application que je met dans pidgin. Mais s’il n’est valide qu’une seule fois, alors çà ne marchera qu’une fois aussi non ? C’est ca que je comprends pas dans ce que tu me dis.
Et s’il est valide tout le temps, alors il peut etre voler, et ma question revient : que peut on faire avec.

Je crois que tu as ta réponse dans l’intervention de Bussière : problème similaire avec une messagerie externe dans laquelle il ne veut pas enregistrer son mdp, obligé donc de refaire une association à chaque ouverture. Ce genre d’appli ne devrait pas te demander d’entrer ton mdp en fait, mais utiliser le système d’autorisation de Gmail, qui fonctionne sans mdp en associant, à partir de ton compte, la dite application (que tu peux révoquer par la suite). J’ai pas d’exemple concret à part http://www.monae.fr/ en tête là.

ha ok je comprends mieux.
Vous connaissez un client gtalk qui soit pas trop mal et qui fonctionne comme ca ?

up ?

Je suis sûr à 90% que les password d’application Google sont des passwords comme les autres et que la seule différence est que tu en génères un par application. C’est une chose différente du système d’authentification par token de l’API Google.

Donc n’importe quel client Gtalk qui retient ton mot de passe fonctionnera.
(ou alors j’ai raté un truc et je veux bien qu’on m’explique aussi)

mais du coup, c’est tout bidon non ? Si ce mot de passe est compromis d’une manière ou d’une autre, ca reviens au meme que perdre son mot de passe principal en identification standard ?

Edit :
Bon, j’ai essayé de me logger sur l’ihm web de gmail avec un mot de passe d’application, et ca déclenche une erreur « Veuillez utiliser le mot de passe de votre compte, et non un mot de passe spécifique à l’application. ».

Donc on peut pas passer par la.
Reste à voir ce qu’autorise l’API de google. A mon avis, on doit rien pouvoir changer sur les parametres de securité, donc c’est plutot pas mal fait.

Je l’adopte, on verra à l’usage.

Ca doit etre (et je n’y connais rien donc je dit ptet une connerie) un systeme lié a openid, ou le pass est utilisé une fois, puis un token d’auth est recu. Lu et decrypté par l’app a chaque fois, il ne peut pas servir autrement.

Surement pour les appli qui supporte l’identification google, mais pas pour celles sont je parle, qui passe simplement sur une autorisation login/pwd.

Non, le mot de passe applicatif ne permet que d’accéder aux API Google du type mail et quelques autres, pas de faire de changement sur le compte par exemple. (comme tu t’en es rendu compte en tentant de te connecter à ton compte Google avec)

C’est normal, pour te connecter à ton compte Google (et pas juste accéder à une API), il te faut le mot de passe principal et la seconde étatpe d’authentification (SMS ou code généré par une appli mobile).
Essaye le mot de passe applicatif directement dans ton client Gtalk. Je pense vraiment que ça marchera.

oui j’essaye ce soir :slight_smile:

Bon je viens de faire 2/3 tests.
Les mots de passe d’applications sont des mots de passe standard, qui restreignent simplement l’accès à l’API. Ils sont pas du tout jetables et sont complétement interchangeables.

J’ai fais le test suivant :

  • Génération d’un mot de passe d’application A pour Pidgin.
  • déclaration du mot de passe dans pidgin : connexion à gtalk OK
  • déconnexion / reconnexion de pidgin avec mémorisation du mot de passe A : OK, se connecte à chaque fois -> le mot de passe n’expire pas après la premiere utilisation
  • utilisation du mot de passe A dans l’application mail de l’ipad : se connecte bien à la messagerie, envoi / réception de mail OK -> les mots de passe ne sont pas liés à une application
  • déconnexion / reconnexion de pidgin avec l’ipad toujours enregistré : OK -> pas d’unicité d’utilisation du mot de passe
  • génération d’un mot de passe B et déclaration de ce mot de passe dans l’ipad : OK

Conclusion : il n’y a pas de notion d’expiration de ces mots de passes, et l’association du mot de passe par appareil n’est ni une obligation, ni une restriction technique. C’est juste pour s’organiser.

Mais c’est pas mal en fait. Je vais suivre la préconisation de google d’un mot de passe / un appareil.

Par contre, quelqu’un qui récupère un de ces mots de passe pourra se connecter au compte au travers de l’api, et donc de consulter les mails, tous les effacer, mais ne pourra pas s’approprier votre compte.
Mais chaque mot de passe supplémentaire augmente les chances d’en trouver un valide en brute force.

Je vais voir s’il y a un moyen de suivre les connexions actives des applications.

C’est bien ce qu’il me semblait. :stuck_out_tongue:

oui, mais contrairement à ce qui a été dit, ce ne sont pas des mot de passe one shot qui expirent. Donc s’ils sont compromis, c’est moins grave que le mdp du compte, mais ca reste embêtant : on peut nuire quand même pas mal via l’api (suppression de tout les mails par exemple, ou envoi de nouveau mot de passe sur l’adresse et lecture du resultat via l’api).