upvote

points

by stvnbn22 hours ago |
comments
upvoteby epistasis22 hours ago|
next
[-]
Password managers are all about trust, the main link is about a compromise, so it's not surprising that the first comment is also about trust too, even if it's not directly about this particular compromise.

I found the default bwcli clunky and unacceptable, and it's why I don't use it, even though I still have a BitWarden subscription.

reply
upvoteby harshreality20 hours ago|
parent|
next
[-]
Where's the evidence that 1024kb's issue had anything to do with bw? How is that vaguely recalled anecdote a trust issue with bw? It was probably caused by accidentally copying something to the clipboard or some other buffer which was then transferred via ssh and imported into weechat, possibly with the help of custom terminal, ssh, tmux, or weechat settings making it too easy for data to be slung around like that.

I can't think of a plausible explanation for how bw is at fault for its terminal output ending up, across a ssh session and tmux invocation, in the chat history of weechat. Even if bw auto-copied its output to the clipboard (which as far as I could tell by glancing at the cli options, it doesn't and can't), and the clipboard is auto-copied to remote hosts, clipboard contents shouldn't appear in an irc client's history without explicit hacking to do that.

The claim is just noise, particularly because it doesn't seem to have ever been investigated.

It seems prudent, if someone wants to use a cli, to use rbw rather than bw, or even just pass or keypassxc-cli (and self-managed cloud backup or syncing). However, that's based on bw being a javascript mess, not based on the unlikely event of bw injecting its output through ssh into irc clients.

reply
upvoteby 20 hours ago|
parent|
prev|
[-]
deleted
reply
upvoteby cobolcomesback22 hours ago|
prev|
[-]
Not to mention utter nonsense. There’s no possible way that BW CLI somehow injected command history into a remote server. That was 100% something the GP did, a bug in their terminal, or a config they have with ssh/tmux, not Bitwarden.
reply
upvoteby reactordev22 hours ago|
parent|
next
[-]
that's our future... with AI. Engineers that don't know the difference between client-side convenience and server-side injection, how to configure `php.ini`, or that no synchronized password manager is safe. While the OAuth scope is `*`, and CORS is what you drink on the weekend.
reply
upvoteby Sohcahtoa8221 hours ago|
parent|
next
[-]
Can someone explain why people struggle with CORS?

The full strength of the SOP applies by default. CORS is an insecurity feature that relaxes the SOP. Unless you need to relax the SOP, you shouldn't be enabling CORS, meaning you shouldn't be sending an Access-Control-Allow-Origin header at all.

If your front-end at www.example.com makes calls to api.example.com, then it's simple enough to just add www.example.com to CORS.

reply
upvoteby 12_throw_away18 hours ago|
parent|
next
[-]
IME, CORS is pretty straightforward in prod but can be a huge pain in dev environments, so you end up with lots of little hacks to get your dev environments working (and then one of those hacks leaks back into prod and now you have CORS problems in prod).
reply
upvoteby reactordev17 hours ago|
parent|
[-]
This. This is a result of not having proper environments and engineering practices in place and so the team or engineer is free to just wing it and add hacks around security best practices because the Security Team (tm) is elsewhere and they never understand the ask. They know PKI and certificates, access card identity, maybe Cisco for their "cyber security" but that's usually where it ends. Yet somehow, they are in charge of CORS and TLS and Sast/Dast scans and everything else that should be baked into the pipelines and process. Resulting in an engineer saying f'it and adding an `if localhost` hack or something. CORS is one example but there are many others in pretty much every area of security. OAuth, CORS, LDAP, Secrets, Hashing, TOTP, you name it. Each has a plethora of packages and libraries that can "do" the thing but it always becomes a hairball mess to the dev because they never understood it to begin with.
reply
upvoteby fragmede16 hours ago|
parent|
prev|
[-]
That simple prod example isn't where people struggle with CORS. It's during development and I've got assets on Cloudflare and AWS and GCP and localhost:3000 and localhost:8000, and localhost:3001 and then a VM in Hetner at API.example.com because why not, that shit gets complicated and people get confused and lost. I mean, yeah, don't do that, but CORS gets complicated once the project gets enough teams involved.
reply
upvoteby tcoff917 hours ago|
parent|
[-]
I’ve found that the best way to deal with this is to add an entry to /etc/hosts for my local machine that fits the pattern for QA environment. Then I run a local reverse proxy with a self signed certificate.

So I do local dev on https://local.qa.yourappnamehere.com

reply
upvoteby lxgr19 hours ago|
parent|
prev|
[-]
We've had all those well before AI.

> no synchronized password manager is safe

Care to elaborate? I'd agree that the security/availability tradeoff is different, but "not safe" is as nonsensical a blanket statement as "all/only offline/paper-based/... password managers are safe".

reply
upvoteby renewiltord17 hours ago|
parent|
prev|
[-]
Probably terminal emulator is like iTerm2 and double click to select and copy to clipboard is feature.
reply