NPM security update: Attack campaign using stolen OAuth tokens

Re:NPM security update: Attack campaign using stolen OAuth t... by danpalmer on Friday May 27, 2022 @01:41PM (#31532442)

I agree it should be this simple, but I'd bet they have tests like this and unfortunately it's never quite this simple in a production system.

I've always wanted to apply strong type systems to this problem – wrapping sensitive data in types that do not have the ability to be printed to logs would theoretically allow you to know after type-checking that passwords can't be output to logs. However again I think this is wishful thinking as a password needs to be sent somewhere at some point, and that creates places where issues can occur.

[ Parent | on HN ]

Re:NPM security update: Attack campaign using stolen OAuth t... by rvnx on Friday May 27, 2022 @01:45PM (#31532479)

Well it's their choice to ask the user to send a plain-text password.

There are alternatives to avoid this, on the same model of SSH key authentication where the secret stays on the client-side.

Nothing prevents them from using a password to derive a private key using PBKDF2 in client-side and answer to a specific challenge.

[ Parent | on HN ]

Re:NPM security update: Attack campaign using stolen OAuth t... by willcipriano on Friday May 27, 2022 @01:53PM (#31532585)

That's kind of how I've always solved it at the smaller companies I've worked at. I'm on Hacker News all day and know all about these kinds of footguns so I write all the auth code myself and then provide a couple of helper functions/methods for the team to use that are unable to do anything too silly. Creating an object that throws an exception when you try to get it as a string or print it though is something I'll have to try next time.

[ Parent | on HN ]