Google has just updated its 2FA Authenticator app and added a much-needed feature: the ability to sync secrets across devices.
TL;DR: Don't turn it on.
The new update allows users to sign in with their Google Account and sync 2FA secrets across their iOS and Android devices.
We analyzed the network traffic when the app syncs the secrets, and it turns out the traffic is not end-to-end encrypted. As shown in the screenshots, this means that Google can see the secrets, likely even while they’re stored on their servers. There is no option to add a passphrase to protect the secrets, to make them accessible only by the user.
Why is this bad?
Every 2FA QR code contains a secret, or a seed, that’s used to generate the one-time codes. If someone else knows the secret, they can generate the same one-time codes and defeat 2FA protections. So, if there’s ever a data breach or if someone obtains access .... 🧵
.... if someone obtains access to your Google Account, all of your 2FA secrets would be compromised.
Also, 2FA QR codes typically contain other information such as account name and the name of the service (e.g. Twitter, Amazon, etc). Since Google can see all this data, it knows which online services you use, and could potentially use this information for personalized ads.
Surprisingly, Google data exports do not include the 2FA secrets that are stored in the user's Google Account. We downloaded all the data associated with the Google account we used, and we found no traces of the 2FA secrets.
The bottom line: although syncing 2FA secrets across devices is convenient, it comes at the expense of your privacy. Fortunately, Google Authenticator still offers the option to use the app without signing in or syncing secrets. We recommend using the app without the new syncing feature for now.
We talk about wanting professional journalists to ditch Twitter and come to Mastodon.
When they do we need to make them welcome!
Today Chris Bing @Bing_Chris a distinguished Reuters reporter covering hacking and foreign affairs has joined Mastodon saying "Hi - Twitter is a garbage fire. I am going to try to use this platform more. Love,-Bing."
@mastodonmigration - Gavin Maguire from Reuters also just joined Mastodon - @gavinjmaguire - can he get a boost too please! Reuters Global Energy Transition Columnist #energy#climate change
@maxleibman I have not done our halfyearly phishing training for 2 or 3 years because it comes from an external address and asks me to click on a link. So I report it (and the 3 or 4 reminders) as phishing and go on with my life.
My manager caught flak for this from his manager. My manager is fine with what I'm doing.
@maxleibman Our IT security sent out an invite for courses on corporate security that were developed and hosted by Kevin Mitnick. I'm like "yeah, right, this is a crafty tiger team ploy to see if we're dumb enough to click on anything with the name of one of the most notorious hackers in history". I flagged it as phising and commented "most amusing". No. Turns out it was a real course they wanted us to take.
I don't know who needs to hear this but #TruthSocial, which is running a forked version of Mastodon, does not from the source code appear to have appropriate mitigations in place for CVE-2023-36460, which theoretically allows attackers to create and overwrite any file Mastodon has access to, allowing Denial of Service and arbitrary Remote Code Execution https://nvd.nist.gov/vuln/detail/CVE-2023-36460 (probably other CVE's as well, but some rely on federation which Truth Social doesn't use?) #infosec
As an update, Truth Social's posted Mastodon source code has not been updated since my initial post in this thread, and has seemingly not been updated since at least June of 2022 (compare: http://web.archive.org/web/20220614001551/https://opensource.truthsocial.com/mastodon-current.zip). So if they're still using and updating Mastodon internally, they're no longer complying with its AGPL license at that link.
Ça fait deux jours que je suis fasciné par ce qui se passe dans le monde de la sécurité informatique, autour de la backdoor XZ. Je vais essayer de vous l'expliquer, ça va être technique, mais c'est important.
Pour Internet, c'est l'équivalent d'un gros astéroïde qui serait passé à 5000km de la Terre. Pas d'impact, pas de dégâts directs, mais on aurait pu tous y passer et personne ne l'a vu venir.
Je vais chercher à vulgariser un maximum, tout en donnant des liens vers les sources directes, qui sont souvent très techniques et en anglais. Ça va être un peu long, mais c'est passionnant.
On ne sait pas qui a fait le coup. La stratégie a été progressivement mise en place sur deux ans, il faut être très organisé et très solide pour voir aussi grand et aussi loin. Beaucoup pensent que seul un Etat a pu mettre en pratique un projet d'une telle ampleur.
Les analyses sont en cours, on en saura plus dans les prochains jours. Des débats on déjà commencé sur les responsabilités, et notament sur le rôle critique de la communauté open-source (et son sous-financement).
Les révélations ont commencé vendredi matin, le 29 mars 2024, avec un post sur un forum suivi d'un pouet sur Mastodon.
Tout est en place quand, en février 2024, Jia Tan ajoute le code de la backdoor dans XZ. Il envoie ensuite des messages aux mainteneurs des différentes distributions Linux pour leur demander de mettre à jour avec la nouvelle version.
Tout se passe comme prévu, jusqu'à ce qu'Andres Freund découvre tout par hasard.
Voilà ce qui vient d'arriver. Un plan mené sur 2 ans et demi, qui cible une des infrastructures de sécurité les plus importantes d'Internet. Un plan qui a failli réussir.
@thisismissem Which attributes are you referring to?
Since I am using Mastodon's search API, cvecrowd should already respect the setting "Include public posts in search results". If this setting is disabled, I would assume that posts are not being detected by the crawler.
@nixCraft I wish banks offered TLS client certificates as a form of authentication. In my opinion it's the best balance between security and convenience.
This xz backdoor thing reminds me of a story I heard from friends that worked at a tech company that made cell phones. They had a great coder that worked on the project, he had put in work as a contractor for a few months, and due to the quality of his work he was hired in full time. After two months he simply stopped showing up to the office.
An investigation turned up the following interesting items. His account had accessed all files including source code to all cellular projects - in that he had apparently downloaded a copy of everything. He had committed a large amount of contributions to the project he was assigned to. None of his paychecks were ever cashed. A wellness check to the house he had rented was performed and the house was completely empty. Per the landlord he'd paid for 6 months rent in advance in cash. Apparently he never physically moved in. No record for him nor his social security number seemed to check out. The guy was a ghost.
I was asked about recommendations on future prevention by friends who worked there - no idea how far they got in their investigation, if backdoors were ever found or even existed, or if the Feds were ever involved. The punch line? This was probably a couple of decades ago.
This shit is real, and it has been going on for a long time.
@simplenomad Had a similar experience early in my career. At the time there were basically two providers of DECnet for non-DEC systems, and I'd worked at one. My next employer had gone with the other, so I got to see their code.
Some of it looked a bit familiar. Unnecessarily so. Investigating further, I started seeing some of my own code and (even more damning) comments. Further investigation revealed a contractor who had worked at my company for a very short time then went to the other.
@simplenomad There was never any conclusive proof that the contractor had taken a tape of our source code with him, so no action was taken, but we (and many others in that part of the industry) totally knew.
Had another person at that second company who came from a competitor and then went back to them after only a couple of months. Always wondered about that one. Industrial espionage is more common than people think.
If you ever used a tool known as "Mastochist" or "Mastodon Super Tools" and connected it to your Mastodon account, you need to remove the affected token.
Preferences > Account > Authorized Apps
It would be a good time to revoke access to other apps there that haven't been used in awhile, too.
My mastodon authorized application list is a mile long. Sure wish there was a better way to manage it en masse. Like, "Revoke all but internal/required." or "Group by App Name" at least.
I know I'm kind of a masto-geek and try out every new app under the sun, but I'm betting I'm not the only one this affects.
So wait building all these "secure" chat apps on a browser engine packaged in a thin layer of UI, with its insane number of dependencies and the gigantic, immense attack surface that this entails, was somehow a bad idea?
Who knew! Who could have foreseen this! Shocking, really.