More info on Google OAuth token revive. Npm 'everything' package prank. 23andMe at it again.

A while back there was an article detailing how some malware groups claimed to have the ability to revive Google session cookies. There's now confirmation that this actually works, and more detail on how.

The short version is that it uses an undocumented "MultiLogin" endpoint that Google uses to sync authenticated sessions in Chrome across different services like Youtube, Gmail, etc. The article itself goes into more technical detail.

Google is aware of the issue, as some effort to mitigate the exploit has been rolled out, but malware groups are already working around that. Google says that these kind of attacks are not new, and clearly states that despite news saying otherwise, the stolen session tokens can definitely be revoked by signing out of the affected browser or remotely revoke tokens through the user's device page.

This was an interesting "prank". Over the holidays, the npm package registry was flooded with more than 3,000 packages, including one called "everything". If you were to installed the "everything" package, it would gradually start downloading -all- npm packages until your hard drive runs out. It did this by requiring all existing packages, albeit in "chunks" (those were those other 3000 packages).

The thing is, it also meant that no one could remove a package from the registry as long as the "everything" package existed. Once an npm package is mentioned as a dependency somewhere, you can't just pull it. This is a security measure implemented after the "left pad" incident in 2016 where a developer pulled their much-used package, breaking a huge set of dependencies. What a world.

My favorite genetic company is still at it, digging that hole just a little deeper. 23andMe has responded in a letter to data breach victims that they were to blame for re-using passwords.

But, as 23andMe well knows, only a fraction of users impacted were through credential re-use, the rest happened through their own app functionality.

More importantly to me, and I'll repeat this again: credential re-use is a big mistake, yes. But you can actually mitigate that risk by pro-actively preventing the use of known passwords, enforce 2fa, and much more. And I'd argue that it's your responsibility to do so if you hold freakin' genetics data. Although to be fair, I'm sure 23andMe's security team knows all about this, it's much more likely that this is a matter of resources made available to them.

In case you're curious about preventing credential stuffing, I'll link to the relevant OWASP page. Worth reading up on!

GraphQL’s becoming a go-to choice for modern API design. Explore key vulnerabilities, trends, and security best practices identified by Escape through scanning over 1.5k endpoints. (Sponsored)

That's definitely something I hadn't thought of before. The incident prompted Ukraine's security service to ask webcam operators in the country to stop live broadcasts, and block the operation of around 10,000 IP camera's.

Good. They will also start checking new or updated master passwords against a database of credentials previously leaked on the dark web to ensure that they don't match already compromised accounts.

The challenge is an effort by the FTC to monitor and stop scammers from exploiting voice cloning technology. Rightfully so, I don't think we're ready for what voice (and video) cloning is going to do to us. Submissions are due January 12, the winner will receive $25,000.

Solid security shouldn't have to come at the expense of a great user experience. That's why Passage by 1Password is building a passwordless auth service that allows you to implement passkey logins in your app or website with just a few lines of code. (Sponsored)