Certains utilisateurs ont eu la désagréable surprise de recevoir un email de la société leur demandant de changer leur mot de passe.
« Nous prenons cette mesure par mesure de précaution, en raison d’une erreur que nous avons découverte […] Le 21 décembre 2020, Slack a ajouté un bug qui a conduit certaines versions de notre application Android à enregistrer les informations d'identification des utilisateurs en clair sur leur appareil ».
Le pot aux roses a été découvert le 20 janvier et un correctif a été déployé le 21 janvier. L’entreprise se veut rassurante : « il n’y a aucune preuve d’un accès non autorisé ou par des tiers à ces informations ».
Slack précise à Android Police que moins de 1 % des utilisateurs Android sont concernés.
Commentaires (11)
#1
Encore une preuve que les phases béta ne servent plus a rien, ce genre de bug n’aurais jamais du passé le state de béta test.
#1.1
Un bêta-test, c’est un test publique, je ne vois pas comment ça aurait pu changer à cette histoire. L’utilisateur lambda d’un smartphone ne fouille pas les fichiers posés par les applications… Ça relève plutôt d’un test specifique de vulnérabilité…
Au final on a une version qui a presenté une vulnérabilité (sérieuse, j’en conviens, mais locale à l’appareil) pendant un mois. Aussitôt révélée aussitôt corrigée. Et en attendant en France, Free continue de vous renvoyer en clair et par email votre mot de passe si vous dites l’avoir perdu. Mais ça n’affole personne.
#2
il existe également des phase de béta test sur android/ios prévue justement pour trouvé les problème des app, mais quasi aucune app n’utilise ces systèmes et push direct en prod.
Tous comme pour les jeux vidéo, les app sont de plus en plus souvent lancé sans test préalable
#2.1
Ce genre de bug peut se détecter via un test unitaire, pas via un bêta-test auprès d’utilisateurs
#2.3
N’importe quoi. Tu m’expliqueras par quelle magie tu peux écrire un test unitaire qui vérifie que quelque chose que le programme n’est pas sensé faire ne se produit pas.
Un test unitaire ne peut servir qu’à vérifier qu’une fonction fait bien ce qu’elle est sensée faire. Et il est tout à fait possible d’écrire des programmes qui font 100% de ce qu’on attend d’eux, mais qui font aussi des choses que l’on n’attend pas d’eux. C’est même plutôt la norme en fait.
#2.4
Si ça enregistrait en clair c’est que ça ne chiffrait pas, ce qui a priori, se test.
#2.5
Personne n’a dit où c’était enregistré.
Il n’y a absolument aucune raison valable pour l’appli Slack de sauvegarder le mot de passe en local : la persistance de l’authentification de fait par un token unique par utilisateur et par appareil. Même si ils sauvegardaient pour x ou y raisons le mot de passe sur l’appareil, une verion hashée ne servirait à rien. Donc il n’y a aucune raison de tester que le mot de passe est sauvegardé chiffré puisqu’il n’y a aucune raison que le code ne sauvegarde quoi que ce soit en premier lieu.
Dans 90% des cas ce genre de bug de stockage de mot de passe en clair se fait dans un fichier de log à cause d’un mauvais parametrage du logger ou parce que qu’un dev a malencontreusement oublié un log() dans une fonction qui est appelée à chaque input utilisateur sans réflechir au fait que le mot de passe est un input utilisateur.
#2.6
Je n’ai jamais parlé de mot de passe, j’ai juste que ce genre de comportement pouvait parfois être détecté (test unitaite, revue de code, …). Après inutile de spéculer sur ce qui a pu se passer vu qu’on ne sait pas.
Les logs je n’y crois pas tellement ce n’est pas persistent sur Android
#2.2
Puis Slack à une version bêta sur Android ! Accessible ultra facilement depuis la page de description de l’app sur le play store.
Donc c’est bien la preuve que la bêta n’a pas relevé l’erreur et n’est donc pas la solution miracle (surtout dans ce cas précis)
#3
ANDROID étant une passoire en terme de sécurité, même si c’est “local”, les données peuvent vite se retrouver ailleurs…
#3.1
Trop gros, passe pas