Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitwarden SDK relicensed from proprietary to GPLv3

github.com

Post reply on HN
Print view View original

261–270 of 381 posts

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#261

Post by KPGv2 »

kcmastrpc wrote: post #251
SkiFire13 wrote: post #222

Earlier quoted context omitted.

Instructions unclear, I have no password vault.

Right, doesn't everybody just use the same password everywhere? I don't see the point of these things.

You laugh, but that's apparently what I did a decade and a half ago.

I recently mounted a HDD that was at my parents' house. Most files are from 2009-2012ish. I was there one summer between undergrad and grad school and used it for a couple months.

I found an Opera password list that I'd exported, presumably to copy over to my new laptop. It was fun last night skimming the list, seeing which websites I'd completely forgotten about that I used to have accounts for. Almost none of them even exist anymore besides the big players (Slashdot, Apple, etc.), but the point is *almost all of them had the same password*. o.O

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#262

Post by kevincox »

ferbivore wrote: post #164
hnbad wrote: post #150

Earlier quoted context omitted.

After reading through the issue thread and the final reply by Bitwarden, I think the only context this provides is that the headline should rather be something like "Bitwarden SDK fixes dependency licensing issue". The opening comment and the final reply are the only valuable contributions in that issue. Everything in between is random people jumping in to feign outrage or telling people to use Vaultwarden (which btw…

This wasn't an "issue", it was working as intended. The GPLv3 client intentionally depended on proprietary code. The CTO's comments on bitwarden/clients#11611, bitwarden/sdk#898 and fdroid/fdroiddata!15353 make it clear this was deliberate. They've now changed their stance because of the backlash. It looks to me like people expressed genuine concerns about being lied to by a company, one they'd trusted with their pas…

Real links for easy clicking:

https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15353

https://github.com/bitwarden/clients/issues/11611

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#264

Post by KPGv2 »

dcow wrote: post #73
freedomben wrote: post #32

Earlier quoted context omitted.

There will always be different opinions, but my opinion is that storing your TOTPs in your password manager is at best a reduction in security because you're reducing your 2 factors down to 1 factor. If the password manager gets compromised (even phished! It needn't involve the password manager's servers getting hacked), then you gain nothing by having 2FA enabled. I would strongly advise using something like Aegis o…

The only true 2nd factor is a setup where your totp codes live on a separate piece of physical hardware. If your totp codes are in an app on your phone, and your password is in a different app on your phone, you're not pure 2nd factor despite convincing yourself that you are. Anything that is convenient is not real 2FA. Real 2FA needs to be pick two of: a password in your head, a verifiable biometric signature, a cod…

> Real 2FA needs to be pick two of: a password in your head, a verifiable biometric signature, a code/key on your phone or separate physical hardware yubikey.

My thumbprint isn't stored on my phone, so I have two factors.

From the PCI Security Standards supplement on MFA,

> The issue with authentication credentials embedded into the device is a potential loss of independence between factors—i.e., physical possession of the device can grant access to a secret (something you know) as well as a token (something you have) such as the device itself, or a certificate or software token stored or generated on the device. As such, independence of authentication factors is often accomplished through physical separation of the factors; however, highly robust and isolated execution environments (such as a Trusted Execution Environment [TEE], Secure Element [SE], and Trusted Platform Module [TPM]) may also be able to meet the independence requirements.

So your phone can constitute a token, while the biometric constitutes the second factor. I don't know about Apple phones, but Google's requirements for biometrics are:

> Capturing and recognizing your fingerprint must happen in a secure part of the hardware known as a Trusted Execution Environment (TEE).

> Hardware access must be limited to the TEE and protected by an SELinux policy.

> Fingerprint data must be secured within sensor hardware or trusted memory so that images of your fingerprint aren't accessible.

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#265

Post by KPGv2 »

guerby wrote: post #154
czarit wrote: post #130

Earlier quoted context omitted.

This depends on the threat model. Having 2FA in the PW manager defends against someone phishing the password and database leaks on the server side, which are the most common in my threat model. But note that if they can phish your pw, they can probably phish your 2FA as well. It does obviously not protect against the scenario where someone is breaking into your password vault. I tend to enable 2FA but conveniently sa…

Same here. TOTP is trivially phishable via evil nginx just like your password, and via social engineering. FIDO2 is not phishable and you have no secret to give out to social engineering attacks.

> TOTP is trivially phishable . . . via social engineering

Is it? I've been on the Internet since the 80s and haven't been phished a single time (despite being the recipient of many obvious attempts). Maybe I could be phished, but I think that's evidence it's not trivial.

I have to wonder how many people sophisticated enough to use and pay for a password manager like Bitwarden could be "trivially" phished.

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#266

Post by KPGv2 »

akho wrote: post #201
AStonesThrow wrote: post #102

Earlier quoted context omitted.

No, factors are supposed to have different qualities, such as: "Something you know"; "something you have"; "something you do"; "something you are [biometrics]"; "somewhere you are [geolocation]". Passwords are in your head - "something you know". TOTP codes are generated by a hardware token - "something you have". If the TOTP codes are crammed into your password manager, then the factors are no longer distinguished b…

2FA via TOTP implies two things: 1) you know a password; 2) you know the seed. This is why people criticize that approach. In practice, knowing a password and having a file (seed) seem different enough, and work against some phishing threats. Logging in through a password manager requires that you know a password (your master password), and have a file (your vault).

Or alternatively something you are (fingerprint) alongside something you have.

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#267

Post by freedomben »

dcow wrote: post #73
freedomben wrote: post #32

Earlier quoted context omitted.

There will always be different opinions, but my opinion is that storing your TOTPs in your password manager is at best a reduction in security because you're reducing your 2 factors down to 1 factor. If the password manager gets compromised (even phished! It needn't involve the password manager's servers getting hacked), then you gain nothing by having 2FA enabled. I would strongly advise using something like Aegis o…

The only true 2nd factor is a setup where your totp codes live on a separate piece of physical hardware. If your totp codes are in an app on your phone, and your password is in a different app on your phone, you're not pure 2nd factor despite convincing yourself that you are. Anything that is convenient is not real 2FA. Real 2FA needs to be pick two of: a password in your head, a verifiable biometric signature, a cod…

I think you're letting perfect be the enemy of good. It doesn't have to be pure 2FA to be better than 1FA. Being in separate apps does give some benefits. It's always going to be harder to compromise two apps than it is to compromise just one of them (even if the difficulty increase is marginal, it's non-zero). Often simply not being low-hanging fruit is enough to save you from an attack.

There are plenty of things for which a 2FA in PW manager is fine, but the most important things I think it's an unnecesary and regretful reduction in security. For example, email account. Email is the "forgot password" way to get access to almost everything, so it's worth a trifling inconvenience in having to load your 2FA into a different app. Same with things like AWS, Cloudflare, and other high-value targets. For the vast majority of people, keeping your Twitter seeds in your PW manager is fine, but it's foolish to do that with your email and other high-value targets, and IMHO if you're already going to have to have two apps, you might as well just standardize and keep the seeds in your authenticator app, and your passwords in your vault. YMMV

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#268

Post by KPGv2 »

afavour wrote: post #238
odo1242 wrote: post #13

Earlier quoted context omitted.

I mean, it still is. It’s honestly gotten better too - for evidence, it’s the one password manager that never gets recommended by sponsored YouTubers but always gets recommended by non-sponsored YouTubers.

It depresses me that Bitwarden has also taken VC funding, just like 1Password. It’s still a great product but as with any VC product I’m just waiting for the other shoe to drop when it’s revenue generation time.

I honestly don't think the password manager market could bear more than $3–5/mo for an individual user or family.

I used 1Password for years until they went from one-time payment to monthly sub and removed local sync so you could only use multiple devices by paying them. I think a big decision there was that they wanted $10/mo or something. I can't remember, but at the time it seemed ludicrous.

Years later, when my new laptop couldn't run the final local-sync version of 1Password, I finally decide to look into password managers again, and lo and behold $3/mo. I signed up immediately.

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#269

Post by freedomben »

AyyEye wrote: post #42
freedomben wrote: post #32

Earlier quoted context omitted.

There will always be different opinions, but my opinion is that storing your TOTPs in your password manager is at best a reduction in security because you're reducing your 2 factors down to 1 factor. If the password manager gets compromised (even phished! It needn't involve the password manager's servers getting hacked), then you gain nothing by having 2FA enabled. I would strongly advise using something like Aegis o…

Sometimes the TOTP is forced on me for a service I really don't care about. That's most of mine, actually.

Indeed, when that's the case I think the PW manager is fine.

Though, if you already have to have an app for the important stuff like your email, then IMHO it's actually simpler to just keep them all in one place even if you don't care too much about some of the tokens. Just one less thing you have to remember (i.e. where did I put service X's token again? was that in bitwarden or Aegis? etc).

Re: Bitwarden SDK relicensed from proprietary to GPLv3

#270

Post by hiatus »

MisterKent wrote: post #15

People here are incredibly hard to please. Very clearly a packaging issue that got blown out of proportion. They've done largely the right things for _years_ in terms of security. They've operated pretty transparently in terms of open sourcing. They've allowed vaultwarden to exist, and eventually created a self hostable version as well. But one bad release with a license screw up and nobody is willing to give them an…

> Very clearly a packaging issue that got blown out of proportion.

CTO: > There are no plans to adjust the SDK license at this time. We will continue to publish to our own F-Droid repo at https://mobileapp.bitwarden.com/fdroid/repo/

https://github.com/bitwarden/sdk/issues/898

Doesn't seem like a mistake or unintentional action.

Post reply on HN