* 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.
Oh! Right! I think this is a ripple effect of #1 for me, this is how I see the panel for creation a message:
https://i.imgur.com/IBVinx4.png
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.
What about an option to expire the message X hours or days after the first access?
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?
I don’t have an issue having a master password for one password manager stored inside another; I DO think having it in a web browser's built-in password manager is a bad idea, particularly because most browser password managers don’t require authentication to use (unless you’re logging into the browser for the first time).
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.
Isn't the point of a password manager that you only have to remember one password? If you put it in another password manager, then you have to remember that password instead, so have you really improved the situation?
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.
I'm still hashing out the details, but essentially cybersecurity has one major flaw: nothing is immaculate.
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.
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.
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 :)
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)
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.
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.
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 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 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.
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.
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.
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.
Interesting, it seems to work very similarly to Firefox Send.
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.
The Mozilla one was being used to deploy malware, so you should watch out for that in advance. Frankly, I don't know how though, and I think Mozilla couldn't figure it out either -that's why it was shut down instead of fixed
This is really clever. And looks like it's easy to self-host via Docker.
> 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[0]. 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 hopefully will be one soon! The backend was written haphazardly in a weekend, so once I clean it up to save myself some embarrassment, I'll open up the source on Github. I'll send you an email if that happens (using the one in your HN profile).
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.
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.
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.
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 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.
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.
A very interesting addition indeed to Bitwarden. I still personally prefer my own setup as I'm guaranteed not to run any risks of being siloed but I've started pointing others towards Bitwarden because of this and their strong commitment so far towards Open Source [0]
I've been using bitwarden_rs [0] because it's lighter, a bit faster, and a lot easier to set up (it's a single docker image with bitwarden in it, rather than having to reverse engineer their docker-compose "we choose where there data goes" forced deployment docker script.
Being a 3rd party implementation, Bitwarden Send doesn't work. So there are pro's and cons, but you can absolutely control your own data here without needing to use their official services.
For sure. bitwarden implements the Bitwarden API so they tend to get around to all these features. It's just worth noting that they tend to trail upstream.
Same. I use keepassxc and just sftp the database around, but I have my mom using bitwarden. Hopefully I' ll convince my sister to start using it soon too (she is not a believer in password managers, yet).
It's funny to me that I basically had the same setup, family included. My sister finally set up Bitwarden after someone logged into her Facebook account and started sending her friends a picture of Itachi. Keep hoping, security is often just a disaster away :)
You'd think such a thing should have been directly implemented in Chat apps and related communication channels long ago considering how much demand there is in the industry, but nope. Signal is the only one among popular texting apps that implements disappearing messages correctly.
Wasn't this what got people into so much bother with Snapchat though?
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.
The point isn't to protect against malicious receivers -- as you say, there's really no way to do that -- but for cases where you trust the receiver but want to make it as difficult for a third-party to access the message as possible.
But the receiver having access to the message for eternity isn't the only issue to address. If a phone is subpoenaed and the messages of interest are no longer on the phone nor on a server, that's a powerful feature.
Even with proper end to end encryption and the deleted messages problem solved, an app like Signal is still relying on the rest of the OS for its security model.
Keyboard input comes to mind as a potential weakness.
Things like third party keyboard apps for example.
> Even with proper end to end encryption and the deleted messages problem solved, an app like Signal is still relying on the rest of the OS for its security model
Is there a circumstance where an app isn’t subject to the underlying OS security model?
Fair point... The real core issue might be a simple one. All current power structures have great fear over any kind of real end to end encryption and would never allow it to happen. So if there ever is a weakness, like the keyboard example, it will likely be exploited to the fullest extent.
I'm not saying there aren't many more points of weakness. I'm just saying there is value in data being proactively removed from places that the company has control of.
Telegram deleting messages appear to work for me. Likely this guy is just buying into Signal FUD that Telegram is somehow worse encryption, despite Signal's encryption being used by Facebook and funded by the US Govt.
For all practical purposes, Signal's backend is also closed source. The public repository for the server code hasn't been updated since April 2020 (nearing a year now) though Signal has, in the meantime, come up with features like new groups that necessitate storing more metadata on its servers.
What does using the same encryption algorithms of a government or business have to do with the conversation? Are you implying that the algorithm is unknowingly back-doored, with the evidence being that Facebook uses the same algorithm? Or am I misunderstanding your point?
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 idea of the other party needing to setup an account is off-putting to me.
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:
WireDoc [1] is a service I've used a few times that has an interesting mechanism where a party with an account on the system can send or request to receive files from another party that doesn't have an account.
I'm a former wiredoc customer. Their service is otherwise nice, but the file size limits have not kept up with the times. I switched to Hightail for requests and delivery about a year ago and have been a pretty happy camper.
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
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.
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.
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 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.
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.
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.
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.
Running a public service like this is a genuine commitment to fight spam, malware, phishing, cp, and various other oogy boogies simply because if you don't people will take advantage and your links will start getting flagged as sketchier and sketchier. It's a hard laborious problem to solve when you have to prevent and suss out bad content while also not being able to see it. Bitwarden is gonna be leaning hard into the account requirement and the reputation of the sender.
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.
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.
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.
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.
It's been nice to see the recent additions to Bitwarden (share my passwords if I die, Send, ability to copy TOTP to clipboard from search list).
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)
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.
This is very exciting news for the Bitwarden team, if only beacuse Firefox Send went away and there's not really been a suitable replacement since. There was onetimesecret, but I never really trusted it...
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've seen your site's link in this conversation at least a couple of times, and am curious as to how you manage the costs of running the service. Is it not as well known that the costs are quite low or the cost doesn't matter to you because of your chosen provider? Since Firefox Send was shutdown due to abuse related issues, what are your thoughts on offering this alternative for free (more so with a 10GB limit, which is much higher than what the Firefox Send limit was)?
Cool, yeah maybe you've seen me linking it before as well.
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.
Why would these services have to care about illegal data? The data is end-to-end encrypted, they don't know what is being sent. There is no reason to even store it on their servers.
If the service is being used to distribute malware, then they do need to care. It causes reputation issues, could get the site added to block lists, and may carry legal liability. This is why Firefox Send was shut down.
It gave you a link to be shared, that essentially embedded the cryptographic key to decrypt. It's basically the same scheme that e.g. mega.nz uses too (their "share link" feature), and similar encrypted services.
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.
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.
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.
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.
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 love Bitwarden, but this move is something that I don't like that much because it fragments more the way we have to share passwords between people / companies.
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 :-)
The only time I, and probably many others, have used GPG is to install R on linux. So I guess you can thank the problematic installation procedure for R on linux for some exposure to GPG.
I not NOT get why the demo'd and encouraged way of sending is considered secure. The email is not encrypted. It contains a link in plain text. It's not stipulated that secure email servers (TLS) are used, and if non-secure, the plain text of the link could potentially be sniffed out by anyone with access to one of the nodes along the chain of transmission of the email data. Further, if the email server on either end is gotten to, the URL is sitting there in plain text, so the attacker has it.
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)?
Probably the best thing to do is set the access count limit to one. That way, no one else will be able to access it after the intended recipient does. And if a 3rd party accesses it before the intended recipient, then the intended recipient will not be able to access it and at least you'll have an indication that it was intercepted.
> Probably the best thing to do is set the access count limit to one.
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.
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.
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.
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.
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.
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.
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.
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)
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.
Anyone knows how does it different from Firefox Send. What is the features will restrict users from abusing it.
FYI, Firefox Send was discontinued due to security reason.
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?
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)
Regarding the self-hosted version: ARM support would be nice. I dug in a bit more, and bitwarden is written in .NET core and SQL Server T-SQL.
.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.
Thanks. It looks like .NET core works (but is unsupported) on FreeBSD. That’s future proof enough. I have a gripping day of LastPass migrations ahead of me. :-)
You could also consider bitwarden_rs, an open source Rust based implementation of the BitWarden server that supports SQLite and MySQL (Postgres support is also coming). [1]
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.
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 don't know about anyone else, but I'm leery of apps that say "proven security and compliance" and then don't offer any obvious details, or proof, about what that "compliance" is. ISO 27001, SOC2, what?
Clicking through on the link under that section explains that they're compliant with GDPR, Privacy Shield, CCPA, and HIPAA on the privacy side. In addition, they've completed SOC 2 Type 2 and SOC 3 compliance, have a link to security assessments/penetration tests/cryptographic analysis done in 2020 and 2018 by third party pentesting firms. For each of their claims, they've got links explaining details, and if none of that is enough, it's completely open source, so you can go code spelunking yourself to verify their claims.
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.
Nice way for browser plugins and script to access sensible information via dom! Even with a title suggestion the applications it is for! No more context sensitive chats i have to spy on
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
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.
* 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.