* Password field for creating new sends should be named differently, as by default Firefox autocompletion puts there my account's password there. Potentially should be exposed from OPTIONS panel. Alternatively it can be generated by default, and then once the message is created, will be shared to the creator - or stored in options menu of my sends
* Missing an option to expire message after first opening. It's like a self destroyable notification that can be read only once. Why? For the instance if I share some confident information with someone that I know is going to open very soon, then once he/she opens the message it will be destroyed, so that if somebody accesses either my or my friend's machine, it will be impossible to read the secret message. Another aspect is that if my friend will try open the secret message, and it will show that message doesn't exist / was destoryed - then we know that message was compromised.
So Firefox put my account password there automatically, and color coded that, but also did this for Max Access Count. And to be frank I filtered out that field when I was looking for relative option to solve #2 problem.
So that if one forgets to save / make-use-of the secret thing, and accidentally reload the browser tab, or power off the computer -- it'll still be there, an hour later. But not a week later.
Or if you share the message with a tech illiterate person, who doesn't realize what "expires after first access" means. Then, instead, you can say to him/her: "After you've read my message, you need to use it within two days, thereafter it disappears automatically". And it won't matter if he or she accidentally reloads the browser tab (with the message in it -- trying to access it for a 2nd time), or leaves for lunch and powers off the computer and wants to continue handling your message, after lunch.
(Could be combined with expiring the message after Y days, without any access.)
If you don't trust a password manager to hold a master password for another password manager, can you trust it to hold your other passwords / whatever else you store in your password manager?
If someone gets access to my unlocked machine and can get into my web browser, they could potentially get into my other password manager to retrieve important information. That’s a very bad thing.
Sometimes you’re required to enter a password to retrieve/view saved passwords in a web browser, sometimes you aren’t — but it is very rare that the built-in password manager requires authentication for auto-fill. As a general rule, I don’t use Chrome's built-in password manager for anything sensitive because it didn’t require prior authentication to view stored passwords (it may have changed now, but I’m not sure), and the same is true for autofill of my 1Password master password and security key on ANY platform. I don’t want someone to be able to autofill and get access to all my data.
Plus it just adds extra, unnecessary attack vectors since there are now two attackable points of authentication for your first password manager and three attackable points for any accounts managed by that password manager.
At least the way I see it, good CySec is creating a chain of dependent constraints (e.g., password-protect a file, which uses a password stored in another file, encrypted with a password, etc.). Wherever that chain comes out is the "entry-point". A password you forgot is as bad as deleting one of the links in the chain.
Thus, there's no perfect solution, and cybersecurity professionals make a lot of money on the ensuing fear from that.
And of course, the accountant at my company still insists on passing personal information through email. Another example, Monese bank asking me to submit all sorts of pdf scans of personal documents to close an account with them.
I asked if they have a secure mechanism for file uploads and they responded "email is fine". No, email is not fine.
They _really_ struggled to understand why I wouldn't just email them every document they asked for (from birth certificates, marriage certificates, 6 months of financial data, 12 months of pay slips, and a host of other things).
In the end I hosted them myself and phoned them with a password, then deleted them once I'd seen they'd been accessed.
Unfortunately, I have no confidence that they have, did nor will handle all of that information appropriately once they receive it.
How is it not complete insanity to require _that much_ information on someone and _not_ have strict training and liability for managing it?
Between then and now, Firefox Send has come and gone, but fortunately it's open source, so I'll host that if I find myself in a similar situation in the future.
E: also, almost everyone I’ve asked will delete the documents after you try and fail to set up an expedient file share. Also, password protected zip files in Dropbox are usually good enough for most everyone and are a very simple system. Just make sure you use modern zip protection and not old crappy Zip crypto :)
Identity theft can fuck you indefinitely.
I've personally had my identity stolen last year and they got a car loan, insurance, and bought a couple iPhones and lines with two different providers. It happened in the month I was closing on my house and getting a mortgage. Yeah it was a bit of a pain but some phone calls, a police report, notarization, and snail mail later and it is off my record and my credit score went right back over 800. Also I was still able to get the mortgage even with it going on.
We don’t chnage credit cards hardly ever. But would need to do it for that too
I've had to unlock them a few times and I can unlock all three in under 5 minutes.
I also have a fraud alert on my reports now which was only slightly inconvenient when getting utilities because I had to go in person to verify myself (utility companies don't report to credit agencies afaik but they do some sort of identity check through them).
We hear about leaks of user databases all the time now so I'm surprised we don't hear more about mail boxes leaking out. All these small business mail boxes must be an identity thief's dream.
Wanna know if that attacker downloaded all of an inbox? You should've thought of that and paid $35.00 user/month (and that's the lower yearly commitment price) https://www.microsoft.com/en-us/microsoft-365/enterprise/off...
The mortgage industry is shockingly one of these. I just refinanced again after doing it 5 years ago. I was really curious to see if anything had changed in the 5 years. Any advances in basic tech? Was my experience going to be more secure?
Answer: Nope. Still the same old stuff, hard copies of everything, people asking me for stuff via email. Blatant disregard for privacy. Just absolutely terrible.
Multiple times the guy at the bank asked for my banking statements (which include full account number, balances, PII, etc.) and EVERY TIME I had to ask him to resend the link to their secure email portal. Worse - they never even offered secure transmission as an option...I had to ask about that option. It's clearly not the default behavior.
Interestingly, the closing company was lightyears ahead of the bank. They had contracted a SaaS vendor that provided a secure digital document management product focused on mortgage closing, and I was able to e-sign everything (even able to scan in my signature and apply to documents). I mean, this isn't earth-shattering tech, but it sure was one hell of an upgrade compared to the bank. That's what all banks should be providing today; overall it was a far better experience than the bank.
I would love to see more places just use email. Instead I get these messages with links to proprietary services to get the file. Now I need to download and store it out-of-line with my conversation.
I think the major issue with email is that encryption is optional with transparent downgrading. You can imagine that if it supported something like mailtos:me@example then it could be used as a secure medium, much like https can be trusted today.
I live in a country where sharing my entire life in paperwork is sadly normalized. Having a self-hosted one-time-secret service for file uploads is so nice.
I have a client that stores similar information in an external HDD in a shared office that a lot of people have access to. I convinced him to let me install BitLocker at a minimum and to allow me to have his computer lock automatically. He had another guy remove full disk encryption because it was a hassle when he moved the HDD around and remove the auto lock because he wanted his secretary to access the computer when he was away from keyboard.
I know an accountant who calls me paranoid when I talk to him about securing the devices that he uses to store tax information about all his clients.
We need regulations and fines because the only way in which people are going to listen about security is if it hurts their pockets.
Sending CC info through email violates the PCI DSS. The PCI is a private organization so noncompliance is not a violation of the law.
There is no unified law across the US that deals with data privacy. Several states are starting to address this problem but there's nothing like what the EU offers.
Its good you de-risked this somewhat by avoiding email thought, that's a good first step and I wish there was a standard for this.
This is why laws like the GDPR are needed.
A key justification for the fine (see the report eg. sections 6.3 through 6.7) is that "there were multiple failures by Ticketmaster to put in place appropriate technical or organisational measures to protect the personal data being processed on Ticketmaster's systems, as required by the GDPR."
Process data without taking appropriate steps to protect that data and you face being fined under the GDPR.
You are thus covered/protected, because if they (solicitors get hack, leak data, etc) the bank will (most likely) spot this, and move to protect you.
Anyway, not wishful thinking. Actual/reality. Feel free to ask your banks about their TPSM.
Good opportunity to see some info: I use BrightTalk (not affiliated) to collect CPEs for my certifications. They have plenty of webinars on Third Party Security: https://www.brighttalk.com/search/?q=%2Bthird+%2Bparty+%2Bse...
In other words, I still maintain this is wishful thinking.
However, after the Exchange hack, now we suddenly have to worry about all the stuff that’s stored in people’s mailboxes after delivery, which is likely a huge amount of data. I expect we’re going to see a huge wave of identity theft stemming from this.
Seems bitwarden_rs might get it too. https://github.com/dani-garcia/bitwarden_rs/issues/246#issue...
Two notes worth highlighting
- UX is much lighter and more reliable for Bitwarden on web
- iOS implementation of Bitwarden is faster, more reliable, and has better interaction with the keyboard than last pass. I find the Bitwarden experience on iOS a considerable upgrade.
Please consider bitwardenrs is a 3rd party implementation, indeed community led, so it lags several features which have been introduced by Bitwarden itself.
See the full list of feature requests in the Rust implementation here , but the two things I'll miss most are Emergency Access and now this feature called Bitwarden Send.
> Are there any plans to implement the new Bitwarden Send functionality?
> Yeah, this one's of personal interest to me, so I'll take a stab at implementing it over the weekend.
For communications in the other direction, such as when you want to make sure the other person sends you the content securely, there is https://github.com/whitesmith/hawkpost (disclaimer, this was an hackathon project I participated some years ago). Hawkpost doesn't even store the encrypted content.
I wonder if there is a solution that would correctly deal with both situations (never requiring the other end to sign up or know anything about encryption).
That said, I think a lot of the value of Firefox Send, which I used a bunch, was that it was maintained by a trusted brand in Mozilla. Indie groups won't have that reputation. And if I wanted to self-host, I would just use magic-wormhole.
Mozilla's instance was obviously associated with the big names 'Mozilla' and 'Firefox' which made it easy to abuse. That isn't an issue now. I guess that helps.
> I wonder if there is a solution that would correctly deal with both situations (never requiring the other end to sign up or know anything about encryption).
I'm actually in the midst of building out a tool for that exact scenario. You can send it to anyone so long as you know the email or username they use for a service that implements OAuth. If they successfully authenticate and the server sees their username / email match up, it sends back the encrypted data to the frontend, which then decrypts it with the key in the URI fragment. It's neither audited nor open source just yet, so I don't recommend using it for actual secret sharing until then.
There's also a nice go port (single binary) of it: https://github.com/schollz/croc
The way I handle this currently is to use https://onetimesecret.com without any added context, just the password string, and then send an email / message such as:
Here are the credentials that you requested:
Password: https://onetimesecret.com/secret/6usoxihjgv1d (this link only works one time within X days)
You could even setup a separate link for the username, etc.
Happy to hear feedback!
If they got a signal account, which is more likely than a bitwarden account, I'll ask them to use that. If they don't, then something like 0bin.net will likely be easier to use (no account necessary, just copy/paste).
Now, bitwarden allows you to send any type of file, which is better than 0bin, being very limited in size, and to text and pictures. But you need a pro account for this.
So I'm not sure how it's better than the competition. Although I'm posting this comment so that someone on HN can show be I'm missing something.
Though the documentation could use some work.
And the bitwarden trademark is also a selling point.
Although it still requires the other party to create an account if they want to send me something.
Maybe I should make a PR to add passwords to 0bin though.
Further most of the time people are using the opensource fork / rust rewrite of BitWarden (bitwarden-rs)which may not have all the features of the official bit warden
There's no way to undelete sent data in practice (as you've no way of knowing if the counterparty backed it up / screenshotted it etc).
Sure you can enable deleting messages, but you can't guarantee they've been deleted - which is what I'm assuming puts developers off implementing the feature.
Is there a circumstance where an app isn’t subject to the underlying OS security model?
Your other points are a great example of FUD.
edit: changed clients to backend
Stand corrected now, thanks.
So, it looks like it's pretty simple.
After the # you have two separate things, separated by /
One is an identifier, the other is likely an encoded key (that may or may not depend on a separate password, if specified).
Just a guess, I assume this is documented somewhere
What an awful decision made by the developer. It is entirely unnecessary to display any account-related info to recipient(s). Some of us use a unique email address per company/site/account, and I find it unacceptable that my account's login would be exposed like this. It's the first piece of information required to begin brute-forcing or social engineering access to the account. I also use two-factor, but that's beside the point.
Are you going to follow up with a company-mandated training seminar on not clicking random links on the internet? ;)
I'm thinking once you're past 1TB, you're better off mailing an (encrypted) physical drive but I'm curious about other solutions especially if you have gigabit internet at home
It's similar to magic wormhole if you've heard of that, but a bit more polished. I think for me it offers the best possible UX.
transfer.sh is also good if you can't install these for whatever reason.
We've transferred as much as 250 GB I believe using scp over the local network. But that was obviously between roommates.
You're probably right that once you're in the TB range, actually sending a drive is the way to go. Egress on Amazon is more expensive than buying and then shipping physical disks.
And you can run your own portal, code and instructions here: https://github.com/NebulousLabs/skynet-webportal (roughly a weekend of work to set one up at this point)
It's relatively simple p2p app with host auto-discovery. Payload is encrypted and performance is pretty decent. Built using rust, libp2p and gtk.
works on Linux and Windows;
repo is here: https://github.com/sireliah/dragit
https://filesender.org/ looks promising but I have not had the time to look into it yet.
The hardest part is being able to have a domain name that links to my machine. After that Caddy makes everything extremely simple.
- password protection
- number of days availability (1 day - 4 weeks)
- max number of downloads
- european datacenter
- max 4GB
Depends on if people you are send are online at the same time. If they are not online at the same time, you would need some in-between services. Or else you can just rsync the files between you guys.
Shameless plug I'm the dev and using it daily :)
Note: I'm obviously thinking from a user perspective, I'm sure others, especially non-technical people might find this reasonable. From a business perspective I suppose it does make sense.
In addition to sending files, I can request files from a third party. Includes document signing and payments (which I've not used).
I've used sites like One Time Secret before and one of the big benefits is that it's pretty fast to store the sensitive data, grab the link and send back to the colleague. Bitwarden Send looks as though you need to be logged in to the Bitwarden site, dig out the feature page among the rest of your password manager and fill out a whole form in order to get a link to send, which would add a barrier to entry for the whole process that wouldn't encourage its use.
Maybe it's just me. It certainly looks like a good feature either way.
I think it’s a mistake to think of Bitwarden send as a stand-alone product, but rather as a convenient feature add to their existing (free and open source) password manager.
I don't see anything like this here. So unless I have missed something, the E2EE claim is bogus and Bitwarden ends up being a trusted third party in this system. The identity management seems to work on the basis of an email address verification entirely under the control of Bitwarden.
It does matter what you trust BitWarden with. If you just rely on them for sender authentication it doesn't mean it's not encrypted E2E. They won't be able to look at your data, but are right, they could forge messages. However, even then you can do the authentication yourself, inside the message. E.g. send a hash through an alternate channel, or if it's too complicated (because you may argue that you could just use PGP with people who know how to verify a hash) then include an agreed upon password in the encrypted message. It's not ideal of course and their app could support these (like you say) but it doesn't mean you have to trust them or that the message is not encrypted end-to-end.
They totally could. All they have to do is trick you into sending a properly encrypted message to an endpoint under their control. Then they can decrypt the message, read it, properly reencrypt it for the entity you think you originally sent it to and then send it along.
Because they control the entire infrastructure and user experience this sort of thing would be trivial for them to do. An unsigned, anonymous PGP message (the equivalent) would actually be better.
The client could just leak the key, but as far as I can understand, it's open source so you can prevent it by building it yourself (and either trusting others or auditing the code yourself too).
As the password is in the URL and you'll send the url through another channel, there is no way to MITM it (decode and then recode for the recipient). And wouldn't make sense anyway, since there was no key exchange, the recipient does not provide the sender with a key to use.
So yeah, they can absolutely look into your files - if they steal your key. (They could do it on the receiving side too, BTW.) But you can't sidestep this with any encryption software: you have to trust at least the encoding and decoding app. (Also, I think you can self host this.)
So regular encryption with insecure key distribution. Dunno what distinction they were trying to make with the end to end claim unless they think all forms of encryption are somehow end to end.
As far as I could decode, the point here really is just to add this service to help their users who came for the password manager. But I also had to watch their video to confirm that the key was in the url.
I would be cool to see this feature incorporated into Bitwarden Send.
 - https://bitwarden.com/help/article/fingerprint-phrase/
The downsides are it's command line only, the upsides are you can audit the source and the encryption happens before it leaves your machine.
Just wanted to share it with you in case you were interested. I'm a Signal user as well and I like what they are doing too. I have some friends who only exchange messages with me on Signal.
Send is nice, we had a vendor use pwpush.com recently to send us a password. Was skeptical because I'd never heard of them before, but it seemed to work fine.
I've been using Bitwarden for around 18 months for my family and a year at work. I like it, but it does have some rough edges.
Was just discussing it a few days ago and one of my coworkers asserted: "It has UI issues that should probably be considered security problems." and I can't argue with that.
The primary one is that when adding a new entry via Mobile, the "who owns this" is down past the bottom of the screen, and the "save" button is at the top, so you can complete the password add without selecting the account/collection portion, it's just invisible down there. Leading to the password being in the wrong place. The default is a selected value, rather than "no choice", so it won't throw an error if you don't go down there and complete it.
Other than that, I'm fairly happy with Bitwarden. I do wish that there was a key to generate values into the custom fields, which I use for "security question" answers, so I have to generate them in another app and really can't use Bitwarden in mobile with sites that require setting up security questions.
My wife uses it, but says it's ugly. So, that might be the thing that causes me to change to another provider... :-) (combined with my coworkers not really liking BitWarden's UI)
I searched around but couldn't find this feature. How do you turn it on?
Update: Turns out fragments are used for key sharing after all. This (in my opinion crucial to anyone aware about the difference between query parameters and fragments) bit is left out from the promotional video.
A common fragment is when you click some section of a website oagr and it changes the link to include #section-x, and if you bookmark it you browser will scroll to the right place automatically.
the original use case (still used today) is to be able to jump to the first DOM element with such an ID; typically title elements, such as the "Books" above. It is only used by the client, so is never sent to the server.
However, FF Send was shut down because keeping up with nefarious users uploading illegal content was a full-time job in and of itself... I wonder what Bitwarden will be doing to solve the problem.
I pay for it myself, with the help of some awesome donators. It isn't too expensive to run, mostly because files have a maximum life time of a week. You might wonder, what is the catch? If it ever becomes to expensive for me personally, I'll take it down (disabling uploads, and taking the whole instance down a week later). But it should be fine for a while!
You're right. Mozilla's Send instance was abused. My instance doesn't have a big name such as 'Mozilla' or 'Firefox' attached, which probably makes it a lot harder to convince unknowing people to download random files uploaded on it. I haven't seen any real abuse yet.
About the 10GB upload limit. I try to balance it with usage and cost. I've set it to 1GB, 2GB and 5GB before. I'll keep it at 10GB now, but might change it if storage becomes an issue.
These links weren't just shared one-on-one in some private channels, but people posted the links in (semi-)public places as well. If it was something actually bad or at least "bad", a lot of times other users, law enforcement, or copyright owners would report these links back to mozilla, requesting the link be disabled and the content taken down.
Best 10 bucks I spend annually, tbh...
Still, nice to have another option incase transfer.sh goes away!
The nice thing about magic wormhole is that the hosted service only provides NAT busting / initial connection set up. Yes, this means you have to do direct, real time transfers, but it’s also much more secure and cheaper for the bridge host.
I should have also mentioned that it's an OSS project, so you can self-host if you want:
Oh, and there is also https://keep.sh, which is free for files less than 500MB - they have a commercial offering too.
Password Pusher - Open source secure password transfer
Review by Crosstalk Solutions here:
Also does anyone know what the difference between 'deletion date' and 'expiration date' is?
I had to update my chrome extension manually but there's now a new "Send" button in the extension. Should be similar with firefox.
For some reason GPG frontends (such as Keybase) aren't a trending thing, and therefore the average guy in IT doesn't even know how to deal with an encrypted gpg file - let alone creating one given my public key. Unfortunately it seems like emails are more straight forward, or encrypted e2e messages via Signal / Telegram / you name it.
I would very much appreciate if somebody created something like Keybase and made it popular - this is a security improvement I would love to see in everyone's life. Things like Bitwarden Send, unfortunately, are probably not going to be the best solution to this problen and not even strong enough (e.g: not E2E encrypted). I wouldn't feel safe in using it to be honest.
In any case, everything is definitely better than sharing credentials in plain text, so there is that :-)
Now, once you have the URL, you have direct access to the secret info, without any challenge.
Modulo this method making it possible to shorten the time the info is available, and to take the info away after the info has been accessed, what is secure about this?
Couldn't you have the same effect essentially by sending the secret through email and then mutually agreeing on both sides to delete the email message immediately after sending (by the sender) and receiving (by the receiver)?
You’d better use at least two. Nearly every email service in 2021 has anti-malware and anti-phishing which was inspects links as a security feature. This often breaks poorly designed “one time” links like password resets that incorrectly use non-idempotent GET requests.
Edit: my ability to communicate seems to be pretty bad today, so let me clarify. The question is about enhancement/integration in terms of usability, and not lack of adoption "as is". I'm well aware that the reason why it's not more adopted is because it isn't easy to use, otherwise these services wouldn't be popping up that makes it more user friendly. Hence the "... obsolete if there was a wider and easier adoption of gpg"
GnuPG has a ton of frontends. I can do three clicks in gajim and have chat secured by GnuPG. Or manage keys with some system keyring app like seahorse (https://wiki.debian.org/Seahorse), or whatever.
The problem is only education. Dropbox just pays a ton of money to put their solution in front of people's eyes via ads, and whatever.
GnuPG obviously does not do that on the same level.
Also securing your communication via asymmetric cryptography requires a bit more understanding and data hygiene than uploading a file somewhere. So it will be an uphill battle regardless of the UI.
I don't want to be educated to use something and I'm a developer for 20+ years.
I wouldn't consider to use any services unless anyone (as in company staff) wouldn't be bothered to use it.
I can't really recommend Bitwarden Send when pasting files in a self hosted Mattermost chat room would suffice for internal use.
I'm asking why a highly usable technology that has been in existence for two decades has not found its way into a accessible easy to use implementation. Seemed like an interesting thing to get an opinion on, but I also don't care enough to offend anyone.
I think the consensus is that GPG isn't easy to use. Perhaps it only seems easy to use for you because you're used to it? Kinda like git. Git's UX is objectively bad but it doesn't bother me because using it is second nature now. I don't think it would be easy for a non-programmer to pick up.
That's why people use document versioning provided by Google/Microsoft/Apple/Dropbox/Adobe rather than using git from the command line. It's the same with GPG.
Even if admittedly, the word "usable" (hard to misunderstand in the context, IMO) should have been "useful", the usable part of this could very much have been for other knowledgeable software developers/designers for it to be the backend of something user-friendly. As such, not even "usable" in that context would have been wrong. Regardless, this would require some modicum willingness for benefit of doubt, which, I do not expect at this point. My only advice to you, is that perhaps don't assume people are children, and perhaps you'll find it easier to see meaning in their arguments.
The article that post mentions in the beginning also had some interesting perspectives, though a bit older.
.. And if you say "but what if the app did it all for you behind the scenes" - at that point, it would look exactly like this and the fact it's gpg based or not would not matter to anyone, not even to you.
I don't think that's necessary. It would be sufficient to simply abandon the idea that keys must be relatively permanent and are useless without establishing out-of-band trust first.
Take WhatsApp for example. The client autogenerates the key, and then contacts are Trusted On First Use (TOFU). Rekeys aren't even notified to the user by default. Having users verify key fingerprints before they can even use the software was considered too difficult. So perfect security is compromised, but instead we get something that works, and can upgrade security if the user takes those additional steps.
The equivalent for GPG would involve an automatic request that a different party create a keypair and send back the public key, such that an encrypted message can then be sent. TOFU. Key management could then be automatic, and fingerprints still verifiable if users want to do that manually later.
E.g. it's pretty hard to convince even small groups to use a mailing list, to upload e.g. photos of shared interest to e.g. a google drive (instead of mailing them around or just sticking them into a FB group). It's doable but it's not the norm.
It's the best break down I've seen of PGP and it really took me out of my flawed notion of PGP, and that it is maybe not so 'pretty good' as I had thought.
Many people do, and it usually boils down to usability (or more precisely, the lack thereof).
I think the assumption it builds in that users fully own and have full control over their device never fully held and will become less and less valid over time also. With the "thin client" model and careless users, GPG breaks.
Also, the NSA clearly wanted to kill the project. I'm pretty sure they engaged in some smarter and more underhanded sabotage after the obvious failure of classifying math as munitions export.
One concern that is going to put me off using the feature though is that sharing my password manager account email with the person I've sent the file/text to seems unnecessary.
Not everyone we share data with (particularly in the world of messaging) should be privy to the sender's email address.
There are alternatives like https://onetimesecret.com which don't, but I can see the value in making it clear that this is a legitimate user to avoid phishing type scenarios.
I assume if abuse starts happening they will just start requiring a paid plan, which would allow some amount of additional protection.
Off-topic: For Rocket Chat users if you want temporary-encrypted messages exchange you could try OTR https://docs.rocket.chat/guides/user-guides/messaging/off-th...
We are using it in one-to-one chat context to exchange temporary data like passwords, keys, etc.
You don't click "Create Free Account" to see the list of features. Just scroll down.
There is more information on this page: https://bitwarden.com/products/#how-bitwarden-works
.NET core is open source these days, but not SQL Server from what I can tell. I wonder if making it portable (to other architectures/BSD) would be a complete rewrite, or if there’s some easy path forward.
Before Send, the way Bitwarden recommended sharing data was by creating a group account of some sort (family, business), and using a shared collection.
I've never been keen on cloud-hosted password safes, but this is a pretty nice addition for Bitwarden users.
I would love to see them increase the limit for paid accounts, though.
It's just a marketing spin, rather than a meaningful technical description.