Hacker News new | past | comments | ask | show | jobs | submit | aunlead's comments login

> This essentially erases their culture and robs the children of any freedom of identity. From single-digit ages they are being forced (under threat of discipline) to provide economic security for their parents. That is sickening.

What are you referring to here? Care to share some sources?


American children have the freedom to pursue their interests. Indian children are not afforded the same freedom.

Closest Notepad++ alternative I found on Mac was CotEditor - https://github.com/coteditor/CotEditor. Has all the basic features apart from plugin support.


Curious - did you write that article? The author of that article and your username seem to match. Or its just a coincidence.


> They're complaining that an evil maid attack can turn off `AppPolicy.Current.ExportNoKey` and set it up to export the document silently.

If an evil maid has access to make such a change, wouldn't it be easier to just replace keepass.exe with custom version? The source is already available. Just call this function after successful login - ignoring XML configuration, "KeePass Essentials" version, etc.


A user needs to enter their "master password" before database is unlocked - after which the silent export can be triggered. Just changing values inside the XML does not expose the passwords.


I'm banking on the emergency access feature [1] of Bitwarden (available in self-hosted version too [2]).

The "how it works" section has more information [3] but it essentially boils down to trusted individuals requesting access - which can be manually approved by account holder or they are automatically granted access after a pre-defined wait time.

Bitwarden (paid version) also claims this - "If your premium features are cancelled or lapses due to failed payment method, your trusted emergency contacts will still be able to request and obtain access to your Vault. You will, however, not be able to add new or edit existing trusted emergency contacts."

[1] - https://bitwarden.com/help/emergency-access/ [2] - https://github.com/dani-garcia/vaultwarden/wiki/ [3] - https://bitwarden.com/help/emergency-access/#how-it-works


FYI: Bitwarden premium costs 10$ a year!


Oh? Do we like it better than last pass?


I used KeePass with google drive sync before, so cant speak to LastPass.

What got me interested is that Bitwarden is open-source and empowers you to self-host, which for me goes a long way for establishing trust. It has a modern interface through desktop, browser extensions and CLI. You can choose to cloud-host your vault on bitwarden servers, for convenience, with a very generous free tier. Which is what i've been doing for years now, no complaints really.


If you have been taking exports as backup, be aware that any attachments you have were not exported - https://news.ycombinator.com/item?id=31702594


significantly better than lastpass. moved 3 years ago, got the 10 usd premium subscription just to support the project.


I can't speak for everyone, but I made the switch after there was some drama with LastPass not reporting security problems in a timely manner a while back (https://news.ycombinator.com/item?id=29737973)

I had used LastPass for a few years, and begrudgingly started paying when they went the "desktop or mobile only" option for free accounts - I need both for complicated reasons. The switch made me pretty bitter with them over the whole thing. It was like I was tricked into trusting them to deliver one thing, then they started to charge me for the "privilege", with no tangible improvement to the service they were providing.

After I saw the thread and started to read up a bit on their past issues (https://en.wikipedia.org/wiki/LastPass#Security_issues), I was motivated enough to make the switch.

Personally, I've had nothing but great things to say about Bitwarden since moving over. The import from one to the other was pretty painless.

I still have to interact with LastPass for certain job-related things, and the difference is really very noticeable. Much easier to generate usernames and passwords in the web extensions on BW. Things are laid out a bit more logically, in my opinion. It also feels like BW signs in/loads significantly faster in the browser extension (I might just be imagining things). It just feels less cumbersome than LP is.

The only negative I can think of is that LP is a bit prettier to look at.


Yes please


yes x2


This means that the time delay could be theoretically bypassed by someone other than you (as time delay access is not a cryptographic construction), which means that someone else has access today (likely Bitwarden the company), which means the end-to-end encryption has been circumvented to enable this feature, which means they could be issued a search warrant to yield all of your passwords to law enforcement immediately, prior to your being convicted of a crime.

Self host with Vaultwarden and do not use this feature.


How did you come to this conclusion?

I would assume that only the "trusted individual(s)" - a spouse or whatever - has the "private key" of the vault, so only that person can access it (not Bitwarden, and nothing can be circumvented.)


That just circumvents the other part of the feature; the timeout. It also means you have to trust that individual's security.


Can't it be handled e.g by the spouse having "half" the key, bitwarden the other "half", which they only gives out after the timeout. Ok, bitwarden and your "trusted one" can collude to open it before, but they must both be in on it.


The link to the feature provided here explains how it works. Your Bitwarden client has a master key that opens your vault. This is your own private key. Bitwarden the server doesn't have a copy of it. If you choose to designate a trusted successor in the case of your incapacitation, you send a request to that person. If they accept the request, Bitwarden the client will generate a public/private key pair for them. They keep the private key in their client. Bitwarden the server gets a copy of their public key and sends it to you. Now your Bitwarden client encrypts your private key with their public key and Bitwarden the server gets a copy of that. In the event of your incapacitation, they send a request to get a copy of that encrypted key. After the timeout period, Bitwarden the server will send your encrypted master key to them. Then their copy of Bitwarden the client, which has their private key, can decrypt it, and now they have a copy of your private key as well.

At no point does Bitwarden the server have a copy of anyone's private key. And no splitting of keys is necessary. This is just the normal way asymmetric encryption works.

This, of course, all breaks down if you don't trust Bitwarden the company, since they provide you the client. As far as I understand, US law enforcement doesn't have the legal ability to force a company to modify their own software to make it malicious (as opposed to doing something much simpler like forcing them to turn on IP logging on a VPN server). But if your threat model includes the possibility of US covert intelligence services MITM-ing Bitwarden the company and sending you their own malicious client, then yeah, keep your secrets in a physical vault guarded by people willing to die in a shootout with the FBI before betraying you. Make sure they'll answer to your successor if you die.


Ok then, so one search warrant to Bitwarden to get the encrypted key and your encrypted passwords, and another to the authorized party to get their private key.

It still comprises a break in the end-to-end crypto, and can still bypass the time delay and decrypt your passwords today without your involvement.


I agree. Wondering if such a warrant has ever been issued. This is the classic accessibility vs. security tradeoff.


Better just not to encrypt anything like that.

If you have a house, which has windows, your locks do not provide security against someone smashing open the window. Key cutting schemes are a bit like this - no key offers security, only one of several access routes.

Having multiple access routes may be desirable and simultaneously a concern - a fireman smashing through your window to save your life is desirable, a burglar slitting your throat after smashing through your window is not.

Encryption is more like a lockbox or a safe room - having a burglar compromise your safe room is undesirable, and going into one during a fire is also undesirable. But you do want to use one in the event of a burglary.

A key cutting scheme may be useful in the case of mutli tenancy, but it is not a reasonable dead man switch - if your data needs to be re-encrypted either the keys themselves must be related (calling into question the security of the keys), or the encrypting party must multi encrypt the data, meaning whomever does the encrypting has full access to all the key data.

If e.g. you are yourself encrypting the data, you must multi encrypt - it would be faster just to share the key yourself, as you already have all the keys. If the third party is encrypting, this means they have side channeled your data such that they can decrypt at any point.

Again, even in the case there are e.g. two mathematically related keys, you cannot then enforce a timeout without first referencing and thus controlling the original key. You MUST distribute your keys yourself to your 3rd parties, or your data cannot be secure.


> A key cutting scheme may be useful in the case of mutli tenancy

No. Cutting a key in half doesn't halve its security, but it reduces it exponentially.

256 bits = 2^256 possibilities for bruteforcing

255 bits = 2^255 possibilities for bruteforcing, or half

128 bits = 2^128 possibilities, or 1/(2^128) the security


You can split up a key using something like https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing


1. Key is 256 bits K

2. Half of K is a random 256 bit X

3. Other half is (K xor X), still 256 bit

Having half of key is still 256 bit bruteforcing.


You could instead construct a key by appending two securely-long passphrases together (which will then go through a KDF in any good encryption software). Give each passphrase half to one person. Recombining them is as simple as typing both of them into the passphrase input in the decryption software.


Cutting a key in half doesn't halve its security, but it reduces it exponentially.

256 bits = 2^256 possibilities for bruteforcing

255 bits = 2^255 possibilities for bruteforcing, or half the security of 256 bits

128 bits = 2^128 possibilities, or 1/(2^128) the security

But you can have encryption schemes requiring N-of-M private keys to decrypt.


You can cut a key in half without literally cutting it in half. Like: generate random 256bit number, xor with the key, and hand the random number to one party, and the xor'd value to the other party.


This is the paradox. You want trusted parties to have access, only when you are unable to access it yourself, in cases such as your death, or Alzheimer.

But you _don't_ want trusted parties to be able to access this in case you are incapable due to being arrested, or choosing to simply elope.


Yup. If I were to use it I'd set it to something like 4 weeks, to be sure to cover most scenarios where I'm still alive.


But the wait time process only bypasses the manual approval step, not the private key step right? So you would still need a private key to initiate the time delay


That sounds like a lot of work when you can just write down your password somewhere safe?


Where? And how to stop your spouse from spying on you? I suppose notification of "Login from new device" would be a tell. But that would also be a shitty situation if you end up in a fight.

The Bitwarden access request seems cool since it has a "quarantine period" where the owner gets notified of the access request and can deny it, if still alive (against a malicious spouse request).

If you're sure you never face the "malicious spouse" scenario, then sure, but how many marriages end up in divorce again?


> And how to stop your spouse from spying on you?

I dunno about you, but I kind of got married to them because I trust them.


That's what everyone does. Did you read my last sentence?


Dicorcing a criminal CFAA violator may be to your advantage in the divorce.


Perhaps, but I still wouldn't want anyone prying into my private stuff (while I'm alive).

Also, tracking back, what I'd need to store somewhere (hence I asked "Where?" originally) is:

- password to password manager

- password to encrypted laptop

- password to email account (not stored in password manager)

- frequently used PIN codes (mobile screen lock and various apps)

I could store the PIN codes in the password manager to make things a bit easier, but I'd still be storing the two passwords somewhere that can unlock my online identity, plus the laptop password that unlocks some really private stuff. None of these would be acceptable to me to get into the hands of a nefarious spouse, whether or not I could sue for it later.

As to "Where?"... an alternative to the Bitwarden feature could be to store these passwords using some sort of 3/5 multi-sig encryption with friends and family members where they'd have to collude in order to get a hold of my stuff. But I wouldn't want to give them access either, my spouse only. But then again, what if we both die in a plane crash?

Perhaps there's no optimal solution. Maybe the good ol' lawyer would work. Give a lawyer the passwords, along with contacts to hand over the information in an order of precedence, like spouse->brother->mother->friend. If something happens, give first person alive in the list the information in X weeks.


Just went through our PI planning last week. For those who have experienced it - I feel your pain!


Because of this I find myself gravitate towards sports games like Fifa. Easy to get right back-in on offline career mode. I just stay away from FUT (Fifa Ultimate Team)


Care to share some more details? Is it USB or SATA based?


I thought the Shiori project was dead. Great to see it's got a new maintainer. A new release also dropped after 2 years. [1]: https://github.com/go-shiori/shiori/discussions/376


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: