Yea, I wasn't seeing the "Send" feature on my Firefox extension either, but forcing an update did the trick. It looks like some of the other distribution channels are a bit behind still. The macOS App Store version has not updated and there doesn't seem to be a way to force it.
I like the feature, but if it requires somebody to creates an account, it's a hard sell.
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.
While that is true, it is unclear is the Send feature is available on the self hosted,
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
Just checked, should be available on the self-hosted version as well. [0] And the author of bitwarden_rs seems to be planning to tackle it over the weekend!
I don’t get why most people trust this unofficial clone. It’s neither audited for security issues (unlike official bitwarden) nor is it developed by bitwarden.
The promise of this is great and being a feature of Bitwarden, which is already fairly well trusted, is a plus in terms of peace of mind. But did anyone else find the demonstration a bit underwhelming?
I've used sites like One Time Secret[0] 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.
Well, most people use Bitwarden through apps, and this is present in their apps.
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.
Onionshare, to the best of my knowledge, requires you to have your computer running while the recipient downloads the file. It's a web server. It also requires you to download software.
In this way, it's less convenient than a hosted service which can run in any browser. But yeah, the security of onionshare is good and the fact that you don't need to create an account makes it even better.
I find it interesting how many business models and ideas are obsolete if there was a wider and easier adoption of gpg. It's over two decades old, but not aged in a bad way. I wonder why it isn't integrated better in OS-es, or part of education, as it's such a useful tool. I get why these products pop up, because they solve the initial inertia and make it accessible. Maybe it's OSS licensing, maybe US laws regarding crypto, hm. Does anyone have thoughts on this?
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"
I have thoughts. It's very similar to why dropbox is a thing. In the original Show HN for Dropbox, the top comment assured the founder that it could easily be replaced with sshfs and a version control system. For some reason, the average consumer found Dropbox easier to use.
I mean, I'm not asking why something easy to use is used more than something not easy to use. That would be silly. Maybe someone thought that, and that's why I got downvoted? What you've replied can be reduced to "because it's easier to use". These are not the thoughts I'm after, so let me clarify / reiterate.
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.
I think you're being obtuse, either intentional or not. The technology is useful because of what it does, and my ability to use it is irrelevant. In a "nuclear fusion is a useful technology" sense. Everything else I've explained twice now should have made that explicit and abundantly clear, so, I think I'm done here. Feel free to not continue this conversation.
I think many open source technologies drop the ball when it comes to integrating a nice application. Seems that the protocol and implementation is nice, but the user interface is lacking. Perhaps that is not an interesting part of development for the GPG team.
That was indeed a autocorrect issue, and if that was what caused the confusion, I apologize. I've also done nothing but reiterate the same point from the start, which you seemed quite opposed to consider. This has also devolved into name-calling, so, not sure why you bothered at all.
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.
That was a very interesting read, and covers all the issues I had with GPG/PGP broken down on a per-use-case basis, which is really neat. Fairly up-to-date too (aside from maybe WhatsApp mentioned alongside Signal). In any case, thanks for sharing! Nice to see simplified and somewhat modernized tools like (https://github.com/str4d/rage) and (https://github.com/FiloSottile/age)
The article that post mentions in the beginning also had some interesting perspectives, though a bit older.
Dropbox also has CLI. If that was the only way to access dropbox, average consumer would be out of luck too.
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.
As I understand that was sort of the thinking behind Keybase before they pivoted more into groupware and more proprietaryish stuff (and eventually got bought out)
Apart from the obvious usability thing, I think key management is the main problem. With a solution like this, the user does not even know keys or certificates exist. Anything involving GPG, no matter how easy you make it, will require some knowledge of those concepts.
.. 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.
> Anything involving GPG, no matter how easy you make it, will require some knowledge of those concepts.
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.
Seeing how many people lose their bitcoins or prefer to host them illustrated to me what the natural inhibitions to GPG were.
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.
For this to work it would have to be included in all major OSs and/or browsers. People just use what they know and what they can use, even if it sounds tautological.
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.
I'll mention this article I was directed to by jsmeaton that really highlighted a lot of the reason why there is inertia behind such UX friendly integrations of PGP backed solutions:
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.
Maybe I'm missing something, but how can this be end-to-end encrypted when the password is optional, and there is no fragment in the shared URL?
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.
As I understand it, a fragment is just read by the browser, a parameter is sent to the server.
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.
Now with web applications, thanks to javascript, you can retrieve and use it. So now instead of using it as a locator inside of a page filled with content, you can use it as a string that you know isn't shared with the server: it's perfect for a secret key. You can send the receiver a link with that key, they will put it in their browser, receive the javascript from the server and use that javascript to decode content thanks to the key.
There are number of open source projects that do the same thing such as https://privatebin.info
Adding some marketing on top seems like a good thing as pasting passwords in chat happens too often in many organisations.
I'm probably going to have to leave LastPass later this month. Bitwarden seems like it ticks all my boxes, especially around self hosting. There's a Rust server implementation made by the community that doesn't require much resources so I could stuff it on an existing crowded server I rent.
Too bad Bitwarden does not support sync to folder/iCloud/Dropbox/whatever. I prefer not to deal with self hosted environment but I also am worried about depending on someone else hosting for accessing my passwords.
I currently use Enpass which supports syncing via many services including those. I’ll probably switch to Bitwarden eventually because I’m a magpie but I haven’t so far because Enpass does everything I need.
AFAIK the bitwarden apps hold a local copy of your database. So if the servers go down you just use the local database, from which you can also export from to csv as well.
I have done exactly the same more than a year ago. Couldn't be happier. The bitwardenrs server is extremely lightweight so it runs with almost no resources.
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 [1], but the two things I'll miss most are Emergency Access and now this feature called Bitwarden Send.
bitwarden_rs works great for me and was easy to deploy. However, it doesn't support Bitwarden Send. Not a deal breaker for me, but worth pointing out in the context of this thread.
I just switched last week, so can confirm that as of very recently, it is still far superior to lastpass.
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.
I understand what you mean, though, to me, it read more along the lines of "you already trust Bitwarden, now you can use it to also send stuff" or something like that. Could be just be.
Perfect timing. Just used this to send personal information across email. I still included the password in the email, but the expiry date means my personal data won't be collected through passive email logging. Also added max 2 read attempts: one for me test it, and another for the accountant.
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.
It's such a battle. When my wife and I were buying our home, we needed to send our entire lives in paperwork form to the solicitors.
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.
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.
If the solicitors were acting on behalf of the bank, then they are bound by the contract with the bank. If the bank is a half-decent bank, they have a third-party security risk assessment & risk management team, that audits them regularly.
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.
Whoah plenty downvoting.. I assume that everyone is fully aware of Banks' Third-Party Security protocols/procedures and have good/working knowledge that they don't operate?
Anyway, not wishful thinking. Actual/reality. Feel free to ask your banks about their TPSM.
Eh, I am in both camps at the same time. I know what you are saying is true in theory, but in practice ability to make money efficiently trumps everything else. Even at bank bank you see people cutting corners for variety of reasons ( and when you see it you have to react ). I can't even imagine how bad it is in unregulated/less regulated industry.
Setting aside everything else, on what basis would they moved to protect you as opposed to protecting themselves? And even even if they are forced to by bad publicity or something, what can they possibly do for you anyway if there’s a leak, other than offer you a useless year of identity theft “protection”?
In other words, I still maintain this is wishful thinking.
Yeah because banks are notoriously good at protecting consumers. “1 year of free credit monitoring” is just to cover their asses but won’t save yours in case of a major leak.
The real estate agent we had replied with "but I don't understand why you won't email your documents, we've never had a problem using email to send sensitive documents before and we've done it hundreds of times"
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.
Access to small business mailboxes is used for a “neat” form of fraud; they intercept invoices and change the account details to theirs. It’s a bit of a long-ish targeted attack, but it makes the news now and then.
Agreed - there are entire industries that simply have not caught up with secure management of paperwork, PII and financial information. To be frank, I'm not sure how that's possible with all the regulation.
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 work in infosec consulting and reversing for 15 years. My identity has been compromised numerous times via OPM, Equifax, and Home Depot, just to name a few. I just don’t care about emailing sensitive docs anymore. I find an alternative if possible, which usually it works. I put in some effort. But realize emailed financial docs aren’t likely how you get owned. It doesn’t feel great, but it is what it is.
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 happened to me once from another person with my same name using my identity to run up credit. It's not that hard to fix, it just takes fighting bureaucracy. They got my info from some lender somehow getting my data and giving it to them. Someone's email spool getting compromised and that leading to identity theft is such a smaller concern compared to all these data warehouses just leaking your data.
Maybe if it goes unnoticed for several years... But even then indefinitely sounds like a stretch.
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.
You can also lock your credit down with the main agencies. I do this during normal times and only unlock when I know I need to secure a new line (such as a car loan or moving)
We don’t chnage credit cards hardly ever. But would need to do it for that too
You better believe I have my credit reports locked now and for anybody reading this I recommend you go do this now if you haven't already (it is free and easy).
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).
I’ll also add that it’s more convenient than I expected - the three credit bureaus all let you unlock your file temporarily up until a specified date, after which it will re-lock without you having to log back in.
I have freezes and fraud alerts on my credit reports so in reality they can't really do anything (unless they also had access to my email, physical address, phone, and the PIN I used to freeze them)
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.
This is the only thing I still use Dropbox for after moving my files away a long time ago. Set up a password protected folder, send the link over email and SMS them the password or tell them over the phone. Easy peasy.
Assuming that you have your email configured to require TLS on the receiver than I don't see what is wrong with email. Even if they downloaded the files from your server they probably just stuck them on some file share which at best is just as secure as their email inbox was. Many organizations have policies for email retention and similar that is less likely to be enabled for file storage.
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 know of a reasonably large travel agency that asks their customers to send a photo of their passport, driver's license, and credit card to a random employee's personal email account. I warned my brother against sending them his information and he saw me as the problem.
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.
In the past the risk with email was mostly network sniffing during the transfer, which is somewhat low risk given who has access to backbone networks, and many systems have opportunistic TLS enabled, which is at least better than nothing.
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.
So the basic package says you can share passwords with one other. But it also says core features and sharing are 100% free. But when you click on that box that mentions core features you (I mean me) expect to see what core features are. Instead I'm asked to create an account. For a thing that's supposedly free. So no sell. I'm really sorry because I want to like software like this, but not like this.
Bitwarden Send, the feature under discussion, could certainly work without an account. (It's nearly the same thing as Firefox Send, which didn't require one. Although using accounts probably helps prevent abuse, which I think is what forced Firefox Send to shut down.)
I'm using a desktop. And nowhere on the page are core features described. So you're ok creating an account when you don't fully understand the scope of the app?
Interesting project! Great to see new features coming out of BitWarden.
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.
I appreciate that it's always good to question how much data, of any kind, is exposed, but what's the scenario where you want to share a secret with a specific person, but it's really important that they don't have the email address you use for Bitwarden?
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.
What are some other secure ways to send varying file sizes from my computer to one/many others e.g. how would you securely send 1MB, 1GB, 1TB?
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
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.
It's decentralized. For example, the exact same service exists at https://skysend.hns.skyportal.xyz, which is operated by a completely unrelated party. Links created on one will work on the other.
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.
Resilio Sync. It's like a cloud but over p2p, so there are no size limits. You need both devices to be online at the same time (not necessarily connectable, their servers can handle that). It's free, pretty easy to set up and just works. It does encryption by default, but if you want a layer of extra security on top, just put your data in a Veracrypt container and send that instead.
Resilio is quite the head or two above - very polished commercial product, actually, with basic free license. From the authors of original bittorent protocol and client.
As far as I looked at Syncthing, it required n^2 config steps for n connected devices. Not really feasible unless every person with access to the folder knows every other person.
Looks really good. This seems like it would be a great alternative to AirDrop if support is added to enough platforms. One issue I have with it is, if it's p2p having a speed limit seems silly.
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.
I recently moved about 1TB of video files to S3, before moving it to another service that supported importing via HTTP. Not sure if there are any better alternatives for this, I would love to hear about an alternative.
This is a holy grail I've been looking for.
The use case is receiving MB to TB size files.
Requirements are a web interface, resuming transmissions, self hosting, open source, encryption and AD integration for users.
For now the best way I have found is to put the content on my website, in a folder protected by a password and served by TLS only. Anyone can receive it, I control expiration and access, even as a sender I'm using extremely simple, reliable software. It's not like I need to send a lot, it just works.
The hardest part is being able to have a domain name that links to my machine. After that Caddy makes everything extremely simple.
I use http://transfer.sh for sending large files between machines on different networks - you don't even need an account to use it. I presume there must be a maximum file size, but I haven't hit it (yet).
Still, nice to have another option incase transfer.sh goes away!
What’s the business model for transfer.sh? It looks like a free service that hosts your files on their servers temporarily. That sounds like a variant on the image hosting problem, where it’s unsustainable if it gets popular. You also have to trust them with your encrypted data.
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.
IIRC, Firefox Send shutdown because it was getting abused - I see you need an account to use Bitwarden Send, which I imagine helps mitigate against that, but it's also a barrier to use. Would be interesting to know what other anti-abuse mechanisms are in place.
Bitwarden Send is a feature add for existing users. It solves a very real problem of sharing passwords (and other sensitive information) with others.
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 recently (2 days ago) had an attempted login into one of my accounts. The password was randomly generated by bitwarden and not reused anywhere. Luckily I had 2fa which alerted me to the attempt. This is beyond puzzling to me as there is no possible way someone could have guessed or downloaded this password from a DB leak. Can anyone suggest what this could be? (The attempt came from a country that is not my own)
I love the fact that it's not just a seperate product, but it's also included in the existing bitwarden password safe. That's just awesome. I can't wait for v1.40 to be released on monday for self-hosted instances.
Roboform is not recognized in the industry, but gets the job done, plus, it has secure notes, identities, markers, etc... all encrypted, and hasnt fail to me for over 4 years
This claims to be end to end encrypted. One hard requirement for effective end to end encryption is that a user has a method to confirm that they are actually exchanging data with who they think they are exchanging data with (e.g. Signal's safety numbers).
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.
While you are correct that sender authentication is an important requirement, I think you are mixing two things. Having end-to-end encryption is one thing, sender authentication is another.
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 thing works by encrypting a file using a password derived key (if I understand correctly) which then gets uploaded to their infrastructure. You get the url, containing the password (used to derive the key). There's no point and no way tricking you into sending it to them, i.e. setting up a MITM attack.
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 it is just a "send the URL with a key in it" scheme? I totally missed that when rooting through the web site.
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.
I guess the distinction is that, as I said above, they don't see the content (unless, again, the clients leak the key). And it is an important distinction, because everyone will emphasize the importance of an encrypted connection (read: https). Which is not e2e.
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.
The password/key never hits the Bitwarden servers. Bitwarden servers are just storage buckets for encrypted payloads. The server is never involved in the encryption or decryption process; this is the case for Vault, and now Send. All encryption and decryption is handled exclusively by clients.
Note the URLs used; all the important bits are contained in the fragment (after the "#"). HTTP clients do NOT send the fragment to the server; a "#" and everything after it is stripped before being sent to the server. Bitwarden's Send URLs contain an identifier as well as the decryption key in the fragment. When you load the page, JavaScript is able to read the fragment; an async request is made to fetch the encrypted payload using the first half of the fragment (ie. the payload's unique ID). Then the client–in this case JavaScript–decrypts the contents using the second part of the fragment as the key.
Trying it, it says my email address in the message, and to get that I had to log into Bitwarden with my email and password so you know it's come from that account bar it being hacked etc.
I wrote this a while ago and full disclosure I am the maintainer of this repo and I run the service, but I wanted a way to do full end to end encryption that was easy for me to use
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.
As a self-hosted alternative if one already has Vault (or is OK with a provided single-node installation), this[0] is great. I use it when sharing private stuff over unsecured channels regularly.
267 comments
[ 11.7 ms ] story [ 4180 ms ] threadAlso 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.
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
[0] https://bitwarden.com/help/article/send-hosting/
I've used sites like One Time Secret[0] 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.
[0] https://onetimesecret.com/
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.
In this way, it's less convenient than a hosted service which can run in any browser. But yeah, the security of onionshare is good and the fact that you don't need to create an account makes it even better.
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"
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.
https://www.gnupg.org/software/frontends.html
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.
https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
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.
Many people do, and it usually boils down to usability (or more precisely, the lack thereof).
.. 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.
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.
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.
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
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.
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.
https://en.wikipedia.org/wiki/Donald_Trump#Books
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.
Now with web applications, thanks to javascript, you can retrieve and use it. So now instead of using it as a locator inside of a page filled with content, you can use it as a string that you know isn't shared with the server: it's perfect for a secret key. You can send the receiver a link with that key, they will put it in their browser, receive the javascript from the server and use that javascript to decode content thanks to the key.
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 [1], but the two things I'll miss most are Emergency Access and now this feature called Bitwarden Send.
[1]: https://github.com/dani-garcia/bitwarden_rs/issues/246
https://github.com/dani-garcia/bitwarden_rs/issues/246#issue...
> 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.
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.
It's just a marketing spin, rather than a meaningful technical description.
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.
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.
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.
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).
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 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 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.
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.
You don't click "Create Free Account" to see the list of features. Just scroll down.
(on mobile)
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.
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.
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
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)
https://github.com/schollz/croc
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.
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.
https://cryonet.io
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).
https://flathub.org/apps/details/com.sireliah.Dragit
It's relatively simple p2p app with host auto-discovery. Payload is encrypted and performance is pretty decent. Built using rust, libp2p and gtk.
Edit: 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.
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: https://github.com/dutchcoders/transfer.sh/
Oh, and there is also https://keep.sh, which is free for files less than 500MB - they have a commercial offering too.
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.
Because the person you're sharing with doesn't use Matrix?
Best 10 bucks I spend annually, tbh...
https://help.roboform.com/hc/en-us/articles/115005664827-Wha...
Roboform is not recognized in the industry, but gets the job done, plus, it has secure notes, identities, markers, etc... all encrypted, and hasnt fail to me for over 4 years
https://github.com/pglombardo/PasswordPusher/
Password Pusher - Open source secure password transfer
Review by Crosstalk Solutions here:
https://www.youtube.com/watch?v=0mpBLRaHtQo
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.
Note the URLs used; all the important bits are contained in the fragment (after the "#"). HTTP clients do NOT send the fragment to the server; a "#" and everything after it is stripped before being sent to the server. Bitwarden's Send URLs contain an identifier as well as the decryption key in the fragment. When you load the page, JavaScript is able to read the fragment; an async request is made to fetch the encrypted payload using the first half of the fragment (ie. the payload's unique ID). Then the client–in this case JavaScript–decrypts the contents using the second part of the fragment as the key.
https://github.com/abemassry/wsend-gpg
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.
I would be cool to see this feature incorporated into Bitwarden Send.
[1] - https://bitwarden.com/help/article/fingerprint-phrase/
[0] https://github.com/algolia/sup3rS3cretMes5age
https://bitwarden.com/help/hosting/