Hacker News Reader

Comment by stvnbn | Hacker News Reader

I love how the first comment is a complain having nothing to do with the actual subjec

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.

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.

The behavior of `bw list` is the serious breach of trust.

> I believe it was `bw list` that I ran, assuming it would list the names of all my passwords, but too my surprise, it listed everything, including passwords and current totp codes.

This issue is cleary bitwarden's issue, and is an insane design that's extremely unfriendly. I just searched again and apparently, yes, `bw list` just dumps all the plaintext passwords out to the terminal! Doing an `ls` on a directory doesn't dump all the file contents, doing `list` should not reveal the secrets everywhere, and a design that includes dumping all passwords in plaintext from a listing is frankly panic inducing. I always take care not to cat secret key material to the screen, and even try to avoid piping it places.

Whatever else happened after having your entire password vault dumped to a terminal screen is probably unconnected to `bw` in any way, and 1024kb doesn't blame bitwarden for that directly, and says "I have no idea how this happened, but it was quite terrifying." which doesn't blame `bw` for the copying. The sin was dumping everything to the terminal.

Data on a terminal screen should be easy to be slung around, that's the entire point of a terminal screen. So it should be very hard to dump all your secrets to the terminal, there shouldn't even be a "dump all plaintext passwords to stdout" without some serious `--yes-i-mean-it` flags, much less the most basic command one can imagine using when trying to look up the name of a secret.

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.

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.

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.

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).

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.

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.

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

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".

Probably terminal emulator is like iTerm2 and double click to select and copy to clipboard is feature.

Reply on news.ycombinator.com