Hacker News new | past | comments | ask | show | jobs | submit login

>Before the incident: The attacker presumably found the maintainer’s reused email and password in a third-party breach and used them to log in to the maintainer’s npm account.

Password managers and MFA, people! Please use them. There's never a reason to not use a password manager for every website, application, and service that requires credentials. And MFA isn't everywhere, but for places that support it: use it. Ideally non-phone based if that's an option, to prevent risk of phone number/voicemail-related compromises.




> There's never a reason to not use a password manager

Sage advice. Right until the day that there is a major exploit of a popular password manager.


If you fear a browser extension-based vulnerability (like an XSS vulnerability that allows an attacker to send all of a visitor's passwords to their server), use a native application like KeePass. You lose some convenience, but it's just a few extra steps when logging in and registering.

It's certainly not impossible that some major flaw will eventually be found in KeePass, but it's stood the test of time so far, and it's hard to imagine how it could be mass exploited considering it basically just reads and writes a local AES-encrypted file. Even if someone finds something that lets you completely bypass the encryption (which is very unlikely), they'd still need to gain access to your hard drive (or wherever you're storing the file).

But I'd also say the net security benefit of a lot more people using something like LastPass or 1Password would still outweigh the damage of a future vulnerability.

Either way, there is really no excuse for password reuse in 2018, especially when your password for managing your super popular software package running on an enormous amount of devices is the same as the password to your Harry Potter fanfic forum account or whatever.


I use KeePass and have a local kbdx file for this reason - imo LastPass and the like are a huge target. This does require a lot more work since you have to manage keeping a file in sync on your laptop/phone/device and literally cannot get a password without one of those near you. (I have obscene overkill settings for encryption and key transformations in case I lose a device and someone tries to brute-force).

one thing that is without dispute is that a password manager will not reuse or slightly vary the same password which is what human beings pretty much always do.

also some popular ones have integrations for reissuing credentials for major sites. in theory if there were some huge compromise you change your master key and reissue as many pw automatically as possible. then focus on the ones in the list that you know have your credit card saved or are essential for other reasons (npm credentials). you also literally have a list to go down at the point anyway. what is the alternative scenario if your 'same password everywhere' pw is compromised ... try to remember which websites you use and might be the biggest issue and literally manually change every single one?


The surface area of attack is still lower. You need one more thing to be broken before this situation happens. If a hacker needed 3 things in place to own you, they now need 4 things. And a password manager exploit is a big 4th thing.


Great advice. I tell people that using a password manager is almost always better than not using one. Pick one that works for you and your devices and just use it.


My password manager is accessed through an SELinux enforced VM without networking. AFAIK this is as secure as I'm going to get (debating the tradeoffs between a VM and airgapped machine) without using Qubes.

But at least, in the event of an exploit, the VM is still without networking.


I guess it may depend if you're running on Intel or AMD hardware i.e. if the Intel ME stuff has total memory access and its own Minix OS and networking etc.


The alternative here is password reuse for most people. That's so much worse. Lesser "evil" I'd say.


> Password managers and MFA

You conveniently forgot about the MFA part. The attacker will still need the other factor.


As long as they encrypt the stored passwords and you don't use your master password anywhere else, there's not much that can go wrong.


Unless, say, someone uploaded malicious code to a repo with a dependancy the password manager pulls in which changes that behaviour...

Some code somewhere needs to be able to decrypt all those stored encrypted passwords - that code is a _super_ high value target.

I like/use/recommend/have-paid-for 1Password for 5-6 years now - but I worry that the online and 1Password for Teams implementation - even though I trust the 1Password team to "get it right" - has got to be a really "fun" target for sufficiently motivated and resourced attackers. (If I were sitting round at the NSA looking for a fun project - automated MITM of 1Password traffic at p0wned or backdoored-by-agreement carrier or IX routers, using trusted root CA certs to create legitimate-seeming SSL certs, and on-the-wire JavaScript code injection... I reckon I could sell that to my super-sekrit-PHB as a worthwhile research project. )


I use self-synced standalone 1Password for this reason. Much smaller attach surface.


The browser extensions can provide a big attack surface. But otherwise, you're right.


I use `pass`, which is basically gpg+git+xsel. My user account could be compromised, but it won't be through my password manager.


Well, on the worst case scenario, you get not worse than before. So this seems a net win.


> Password managers and MFA, people!

You're preaching to the choir on HN.

This needs to be posted on LinkedIn, Facebook, the *Grams, Imgur, Pinterest, etc.


>You're preaching to the choir on HN.

I would've thought so, but clearly one of the maintainers of eslint-scope didn't follow the advice.


Do you think the ESLint maintainer does not visit HN?


There are lots of technical people that do not visit HN, and there are lots that do. The set of HN users/visitors is not the entire set of technical people.


That's how you get the choir to sing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: