4 ms·
The most important lessons here is clear: always turn on MFA if you can, but more importantly: use a password manager. The risk from password reuse is just far
by OskarS 8y ago
The most important lessons here is clear: always turn on MFA if you can, but more importantly: use a password manager. The risk from password reuse is just far too great, and there's no other reasonable way to have unique, strong passwords everywhere. In this day and age, it's irresponsible security practice to not take this step, especially if you're a developer with special access.
- TheDong 8y agoOther lessons could be taken from this. For example: When you build a package management system that has user-configurable exec scripts, run them in a secure sandbox/container by default. If you provide an override, require a user to approve it and show them the command that will be run on their system. If npm package.json scripts only ran in a lightweight linux container with no access to the filesystem, the mere act of doing an `npm install` could not pwn your box. Another possible takeaway would be that everyone should use Qubes, or some similar project, such that the machine where they use npm doesn't contain any important credentials, and then all publishing is done in CI or in another qubes vm dedicated to the purpose which publishes a shrinkwrapped artifact rather than installing locally.
- mort96 8y agoWhile it would be nice to be able to run `npm install` fearlessly, how much would it truly help? In almost all cases, the code downloaded from npm will be executed non-sandboxed anyways; that's probably the reason you installed the package after all.
- deleted 8y ago[deleted]
- tetha 8y agoYou don't even need containers on linux. If SELinux was more accessible, this would be a very cool use case. You could set the security context of your NPM access credentials to something other than unconfined and ensure that only processes with a specific security label can access files tagged with that security context. These security labels in term are kernel controlled. So at that point, a malicious install script needs to escalate to root in order to steal your credentials. It's kinda sad how such a powerful and rather simple tool is so hard to use.
- rebuilder 8y agoRegarding password managers, I feel uncomfortable, especially when it comes to high-value targets like developers of important software. If you're a potential target for malicious actors, is it a good idea to have a single point of failure for your logins? I certainly see the point about the realities of password reuse, but can we quantify the risks of one approach vs the other somehow?
- TheDong 8y agofwiw a password manager doesn't have to be such a single point of failure. I use `password-store`, which means to get a password I just need access to my gpg key. My gpg key lives on 3 yubikeys and in 1 bankvault as a paper backup. If my main yubikey is destroyed or I somehow forget the pin to it, I just need to go to the bank vault. If I wanted to err on the side of being more able to access it, I could leave an unencrypted copy of the gpg master key with a trusted friend. Since there are many password managers with different models, I think it's difficult to quantify exactly the failure mode of each. However, the reality is almost all security experts recommend password managers, and almost everyone who uses 1password for a while doesn't want to go back.. so clearly there's something to it. The only people I see doubting are people who have uneasy feelings but haven't really written down their threat model nor consulted security professionals.
- thephyber 8y ago> is it a good idea to have a single point of failure for your logins? Just like logging into to 2 SaaSes from the same computer... at which point a keylogger/camera/microphone on/near that computer becomes the single point of failure. There is a point at which too much paranoia paralyzes a person into inaction. Criticizing people for not defending against nation-state level attacks (eg. Password Manager attacks) when we can't even defend ourselves against the neighbor's son (credential stuffing without 2FA) seems like putting the cart before the horse.
- bigiain 8y agoWhile I really like 1Password - I do in my more paranoid moments wonder if it's become so well known and popular that it's probably a worthwhile target for attackers smaller than nation states? It's pretty obvious some of the cryptocurrency thefts have been for amounts far in excess of what a seriously talented group would need to consider taking on a password manager...
- numbsafari 8y agoI thought the most important lesson here is that npm is a horrible single-point of failure with a terrible security track record and obtuse leadership, but has somehow become the backbone of an entire ecosystem within our industry.
- drb91 8y agoThat’s one takeaway. There isn’t an alternative, though, so this isn’t actionable.
- swsieber 8y agoNo, it is actionable - create an alternative.
- drb91 8y agoPlease do! I cannot.
- flukus 8y ago> create an alternative Or maybe just adopt one of the dozens that have been around for longer than NPM in the first place.
- swsieber 8y agoWas there ever a real adoptable alternative to npm for node packages? I'm all ears for suggestions.
- flukus 8y agohttps://en.wikipedia.org/wiki/List_of_software_package_management_systems https://en.wikipedia.org/wiki/List_of_software_package_manag... There are many, most are open source, several have or could be ported to windows. What does npm offer that couldn't have been handled with an apt or rpm repository? The obsessions of reinventing everything in every language is a giant waste of time.
- pier25 8y agoSpecially maintainers of popular NPM packages. eslint-scope has 500K downloads every day for god's sake.