Firefox Send gets password protection upgrade
Users of Mozilla Firefox's Send file sharing service and Firefox experiment may protect files with passwords in the latest iteration of the service.
The organization launched Firefox Send back in July of 2011 as one of three new Test Pilot experiments (the other two were Voice and Fill Notes).
What made Send special was the fact that it could be used without participation in the Test Pilot program. Anyone, Firefox users and users who use other web browsers, could open the Firefox Send website to send files to others.
Send works like any other file sharing service on the Internet. Drop files on the service's website to upload them to the service. It has a an upper limit of 1 Gigabyte per file, but no other restriction that I'm aware of (file types for instance).
Send creates a unique URL that you can copy to the Clipboard after the upload finishes. While the URL is unique, it is publicly accessible which means in theory that it is possible to brute force the service to download files that other users of the service have uploaded.
The new version of Send puts an end to this, at least for users who enable the optional password protection option.
The option is displayed after the file is uploaded to Send. You need to check the "Require a password to download this file" box on that page to enable it. Send displays a password field when you do. Type the desired password and select the "add password" button afterwards to apply it.
This password protects the file. Users who open the share link in a browser are prompted for the password when they do. There is no option to download the file anywhere unless the password is entered correctly.
The download link is displayed once you enter the password and hit the unlock button, provided that it is the correct one to decrypt the file.
All other parameters of Firefox Send remain the same: file download links expire after 24 hours, and uploaders may delete the file at any time.
Password protection improves the security of files uploaded to Firefox Send. While adding passwords adds another bit of information to the sharing process, as you need to share the download link and the password, it protects files from being stumbled upon by accident (as unlikely as this is).
Sounds pathetic as every Mozilla idea so far.
– upload to the cloud, (Where to? Is google involved? Sure.)
– they can brute force it like your firefox password database (Well encrypted (!) … again)
I would recommend FilePizza to do such things with AEScrypt or GPG encryption.
I hadn’t heard of file.pizza until you posted the link to it, but it appears that WebRTC is necessary in order to use it unfortunately. Here’s the error I got on the landing page: “400: No WebRTC Support. Please use Chrome or Firefox.”
WebRTC is disabled on my system (using Firefox ESR) since it causes IP leaks.
Can you please clarify a bit further the “firefox password brute force” part? Thanks.
The link also expires even if the recipient fails to download the file correctly. It *should* expire after a successful download but, no, the stupid Mozilla engineers screwed up yet again.
I think 24hr expiration regardless of download is the result of a thoughtful decision. Basically Mozilla can’t offer endless storage, which would be required if files had to be guaranteed to remain up indefinitely. Without this limit, there would be: 1) an ever growing amount of abandoned data that Mozilla is on the hook for storing just in case it gets downloaded some day, 2) No way for Mozilla to make quick changes if needed or even stop offering the service without breaking promises.
Just consider this password addition. Because of the limit, we can be certain that within 24hrs of change, 100% of files in storage will have had the option to be password-protected.
It’s too easy to call people stupid if you don’t understand them or if they don’t do things as you would.
Off topic – CCleaner has started adding Avast setup in installation wizard.
Here is a comment with Links to Archived, Pre-Avast owned versions – https://www.ghacks.net/2017/07/19/avast-acquires-piriform-makers-of-ccleaner/#comment-4217772
I think you may have missed the biggest impetus for the addition of a password. You write about how unlikely it is that an unprotected url would be stumbled upon, and how the url could be bruteforced. That’s true, but neither is the real danger.
Automated web crawling is the real threat in my opinion. Because most people likely share these urls (including the hash that stores the private key) in insecure channels (email, chat, sms), the urls will be visited by crawlers looking to index new pages, or assess links for malware. It defeats the purpose of having a private means of exchanging files.
With the change, a focused attacker will still get the file if the link and password are shared together insecurely, but automated indexing bots are much less likely to get the original file. An additional benefit is that people intuitively understand that a password should be kept secret; it’s a lot more difficult to explain that the hash part of a url should be kept secret when all our web experience has ingrained in us that a url is public
Usually I need to send way more. That is why I prefer MyAirBridge.com. This online service offers me up to 20 GB for free and without any registration. It also has the highest possible encryption during the transfer and the shared files could be also protected by the password.