Using Security Keys/FIDO2 instead of TOTP codes completely solves trivial phishing attacks like this one.
DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
281–290 of 296 posts
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#282Earlier quoted context omitted.
So if an organisation emails you from no-reply@notifications.example.com, mailing-list@examplemail.com, and bob.smith@examplecorp.com, and the phisher emails you from support@example.help, which filter based on their from addresses makes all the legitimate ones show up as the same sender while excluding the phishing email?
> which filter based on their from addresses makes all the legitimate ones show up as the same sender while excluding the phishing email? This is the wrong question. The right question is: what should we do about the fact that the organization has such terrible security practice? And the answer is: call them on the phone, and tell them that you will not do business with them until they fix their shit.
You're not doing business with NPM by pushing packages there.
And who is going to do anything about fixing their stuff when you pay them a mere subscription fee?
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#283Earlier quoted context omitted.
> I really hope you clear your clipboard history entirely after doing your copy/paste method because your credentials would otherwise persist for any other application with clipboard perms to just exfiltrate (which has already been exploited in the wild before) How does that work? If a malicious website reads the clipboard, what good is knowing an arbitrary password with no other information? If the user is using a p…
Interesting questions, I can later provide more links to more indepth security resources that go over similar points if you would be interested but currently on my phone so I will just jot down some quick surface level points. > If a malicious website reads the clipboard, what good is knowing an arbitrary password with no other information? Even if assuming unique username+url pairings, clipboard history can store mu…
>Even if assuming unique username+url pairings, clipboard history can store multiple items including emails or usernames which could be linked to any data breach and service (or just shotgunned towards the most popular services). It's not really a "no other information" scenario and you drastically reduce the effort required for an attacker regardless.
Webpages can't read clipboard history, so this wouldn't apply.
I was responding to your guidance to clear your clipboard history after copying a password.
>The app does not have to be overtly malicious, AccuWeather (among others) was caught exfiltrating users' clipboard data for over 4 years to an analytics company who may or may not have gotten compromised.
But clearing your clipboard after pasting passwords wouldn't protect you from this attack. That was the recommendation I disagreed with.
The same reasoning can be used for pretty much anything really, why protect anything locally since they could just keylog you or intercept requests you make.
Yes, I agree. But that's why I think people should focus their energy on defending along trust boundaries.[0] There's no trust boundaries between applications running in the same user context on the same system. There is a trust boundary between a web app and local apps, so I think it makes sense to consider what a malicious web app can do (e.g., read the most recent clipboard contents), but we shouldn't lump web apps in with local desktop apps.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#284Earlier quoted context omitted.
The one I use (KeePassXC) is also a separate app, but there are browser extensions for the major browsers to support autofill. Of course plenty of sites don't actually work with autofill, even the browser builtin autofill, because they don't mark the form fields properly. So autofill not working is common enough that it's not a reliable red flag. Separate password managers have the advantage that they can store passw…
> Of course plenty of sites don't actually work with autofill, even the browser builtin autofill, because they don't mark the form fields properly. Can't KeePass use the autotype functionality, but still filter it by website domain/host that it gets from the extension? So basically you'll still never have to copy&paste, and any site requiring this would be a reliable red flag?
Yes, that should generally work. I'm sure someone will decide to make a page requiring a CAPTCHA in between entering the username & the password to create an exception to this case though. It's the sort of insecure-by-design nonsense banks love.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#285So far, it seems to be a bog-standard phishing email, with not much novelty or sophistication, seems the people running the operation got very lucky with their victims though. I'm starting to think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?
>> So far, it seems to be a bog-standard phishing email The fact this is NOT the standard phishing email shows how low the bar is: 1. the text of the email reads like one you'd get from npm in the tone, format and lack of obvious spelling & grammatical errors. It pushes you to move quicker than you might normally, without triggering the typical suspicions. 2. the landing domain and website copy seem really close to l…
> the text of the email reads like one you'd get from npm in the tone, format and lack of obvious spelling & grammatical errors.
As a university professor whose email address is public, I've been regularly getting phishing emails for years. Many of these are targeted and devoid of any spelling or grammatical errors. I am sure generative AI is making writing these emails easier but by how much is unknown.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#286Earlier quoted context omitted.
I can answer why this is at the company I work at right now: It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will gene…
Are you arguing that it’s a good idea for random developers to be able to set up new subdomains on the company domain without any oversight?
[deleted]
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#287Earlier quoted context omitted.
I can answer why this is at the company I work at right now: It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will gene…
Are you arguing that it’s a good idea for random developers to be able to set up new subdomains on the company domain without any oversight?
What's your threat model that says they shouldn't? If you don't trust your senior devs, you're already pwned.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#288Earlier quoted context omitted.
> it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it USE PASSKEYS. Passkeys are phishing-resistant MFA, which has been a US govt directive for agencies and suppliers for three years now[1]. There is no excuse for infrastructure as critical as NPM to still be allowing TOTP for MFA. [1] https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0...
Use WebAuthn as the second factor. Passkeys are a single factor authentication, and a downgrade from password+WebAuthn.
Depends on where you store them. If they're in TPM (like WHFB) it's two-factor (because you need the TPM itself, something you have, and PIN or biometric to unlock it, something you know/are). But if you're just loading keys into a software password manager, yes, it's single factor.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#289Earlier quoted context omitted.
You can just create a new passkey on the new device after logging in. It's a non-issue.
It is not a given that multiple services let you enroll multiple keys. How many year did it take before Amazon allowed multiple Yubikeys? Which means you are in a real pickle if you ever lose your one hardware device with keys (lost, stolen, bricked, whatever).
It's an incorrect implementation, the same as when eg an account provider truncates a long password to 8 characters.
Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
#290Earlier quoted context omitted.
Yes, the idea you are presenting is that the human being must manually check for mistakes. As should be clear by now, this idea does not work at scale. Passkeys will automate and enforce the check, removing human error from the equation.
> Yes, the idea you are presenting is that the human being must manually check for mistakes. Not at all? The password manager handles that automatically, have you never used a password manager before? > Passkeys will automate and enforce the check What happens to the passkey when the origin changes, is it automatically recognising it as the new domain without any manual input? Curious to see what magic is responsible…
> Not at all?
Yes: '...you double-check the domain.' That's manually checking for mistakes.
> What happens to the passkey when the origin changes,
The passkey won't work at all. You will just have to create a new one.