upvote

points

by 1024kb22 hours ago |
comments
upvoteby stvnbn22 hours ago|
next
[-]
I love how the first comment is a complain having nothing to do with the actual subjec
reply
upvoteby epistasis22 hours ago|
parent|
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|
parent|
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 reactordev16 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
upvoteby nicce22 hours ago|
prev|
next
[-]
I thought that CLI would be efficent when I looked for using it and then I figured it is JavaScript
reply
upvoteby rvz22 hours ago|
parent|
[-]
Exactly. That is the problem.

There is a time and place for where it makes sense and a password manager CLI written in TypeScript importing hundreds of third-party packages is a direct red flag. It is a frequent occurrence.

We have seen it happen with Axios which is one of the biggest supply chain attacks on the Javascript / Typescript ecosystem and it makes no sense to build sensitive tools with that.

reply
upvoteby lxgr19 hours ago|
parent|
next
[-]
> importing hundreds of third-party packages

But how else are you going to check if a number is even or odd? Remember, the ONLY design goal is not repeating yourself (or in fact anything anyone has ever thought of implementing).

reply
upvoteby dannyw17 hours ago|
parent|
prev|
[-]
That’s a serious red flag. I’m concerned and I don’t think it shows a security first culture.
reply
upvoteby 22 hours ago|
prev|
next
[-]
deleted
reply
upvoteby trinsic222 hours ago|
prev|
next
[-]
Wow. Thats crazy. Is there an extension for bwcli in weechat? BTW I didnt even know BW had a cli until now. I use keepass locally.
reply
upvoteby harshreality21 hours ago|
parent|
next
[-]
It's crazy because it's not default bw behavior, or even any bw behavior... I don't use the cli, but I don't see any built-in capacity to copy bw output to the clipboard. (In the UNIX way, you'd normally pipe it to a clipboard utility if you wanted it copied, and then the security consequences are on you.)

They probably caused it themselves, somehow, and then blamed bitwarden. Note in the original comment they aren't even entirely sure what the command was, and they weren't familiar with it or they wouldn't have been surprised by its output... so how can they be sure what else they did between that command and the weechat thing?

If the terminal or tmux fed terminal history into weechat, that's also not bw's problem.

reply
upvoteby pprotas19 hours ago|
parent|
[-]
`bw list` shows plaintext credentials in the CLI https://bitwarden.com/help/cli/#list

I know this because I had the same surprised reaction

reply
upvoteby 1024kb22 hours ago|
parent|
prev|
[-]
I don't know, I use a vanilla weechat setup
reply
upvoteby 22 hours ago|
prev|
[-]
deleted
reply