GUI Based Authentication

[AliMickey]

Implement built in authentication for uploading.

A simple password check should be enough i think, account based is overkill for this project.

[ahrenstein]

I agree. I originally tired using htaccess to protect the main page, but on the mobile site after the download succeeds, /download offers to let you try the service and upload without auth.

[colans]

I'm speculating here, but wouldn't authentication have fixed the original problem with malware on Mozilla's hosted version? If users are authenticated, that fixes the security hole. So with this in place, this tool becomes secure (or just running it behind a VPN).

[AliMickey]

I'm speculating here, but wouldn't authentication have fixed the original problem with malware on Mozilla's hosted version? If users are authenticated, that fixes the security hole. So with this in place, this tool becomes secure (or just running it behind a VPN).

Mozilla has been trying to cut costs recently, that could just be an excuse for shutting down this free service. Wouldn't have been cheap to run all that storage and traffic.

[colans]

Well, sure, but I mean it could have solved the malware problems.

[timvisee]

Implement built in authentication for uploading.

That would indeed be great for private instances.

I'm speculating here, but wouldn't authentication have fixed the original problem with malware on Mozilla's hosted version? If users are authenticated, that fixes the security hole.

Mozilla did implement this with Firefox Accounts, but Send was shut down before it reached the public due to other reasons.

---

I currently don't have the bandwidth to implement this, sadly. If there's someone that would like to give it a go, please do.

On a technical level, the password must be validated on the websocket before uploading. It doesn't affect end-to-end encryption on uploads so it shouldn't requite too significant changes. A password check on the upload page itself would probably be desirable as well.

[AliMickey]

I currently don't have the bandwidth to implement this, sadly. If there's someone that would like to give it a go, please do.

I'm happy to try, but i have never done anything with a project this 'big'. Is it possible if you could point towards the main files where uploading is done.

[pirate]

From reading through the code just now, it looks like a pretty decent auth system is actually already implemented in Send.
It's designed to use Mozilla's open-source FXA (Firefox Accounts) service (which speaks OAuth 2.0 among other auth protocols):

• https://github.com/mozilla/fxa
• https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md
• https://mozilla.github.io/ecosystem-platform/docs/features/firefox-accounts/fxa-overview
• https://mozilla-services.readthedocs.io/en/latest/howtos/run-fxa.html
• https://github.com/michielbdejong/fxa-self-hosting (old instructions)
• https://github.com/jackyzy823/fxa-selfhosting (more recent instructions as of 2020)

To set up auth with Send + FXA, you should first run an FXA server in Docker, then point Send to it by configuring FXA_URL=https://url-of-fxa.example.com and the other FXA options here: https://github.com/timvisee/send/blob/master/server/config.js#L143.

I'm not sure if Send uses plain OAuth 2.0, or if it uses one of FXA's other hand-rolled auth protocols, that's something you'd have to dig into. The login() method here looks like plain OAuth 2.0 but I cant tell if there is more beyond that. If it just uses OAuth 2.0, then with some small tweaks you could point FXA_URL to any other OAuth 2.0 provider and use that instead (e.g. Auth0, CloudFlare Access, etc., many companies already have a compatible SAML provider).

You can find the existing auth flow and user account code in Send here:

• https://github.com/timvisee/send/blob/master/app/user.js
• https://github.com/timvisee/send/blob/master/app/fxa.js
• https://github.com/timvisee/send/blob/master/app/ui/account.js

If you want to re-implement auth to be simpler (e.g. password only instead of user accounts), I'd try to do so by reusing as much of the https://github.com/timvisee/send/blob/master/app/ui/account.js and https://github.com/timvisee/send/blob/master/app/user.js code as possible and just swapping out the API calls that Send makes to FXA methods https://github.com/timvisee/send/blob/master/app/fxa.js, instead of writing it completely from scratch.

Proposed implementation for simple hardcoded password re-using most of the existing Auth code:

1. Add a hard-codable config var UI_PASSWORD to https://github.com/timvisee/send/blob/master/server/config.js (default is empty/null)
2. Create a simple password entry form page ui/login.js that saves the password in a cookie on the frontend (no POST request needed)
3. stub out the FXA/OAuth methods in https://github.com/timvisee/send/blob/master/app/ui/account.js used to cryptographically verify the OAuth 2.0 Bearer header in the old implementation, and have them check the cookie value against the static UI_PASSWORD config val instead
4. Re-use the existing https://github.com/timvisee/send/blob/master/app/user.js User object and initialize it with dummy values for all authed users, that way the existing frontend https://github.com/timvisee/send/blob/master/app/ui/account.js UI shows them as a logged in user and provides a logout button
5. Direct users to configure ANON_MAX_FILE_SIZE=0 if they want non-authed users to not be able to upload at all, otherwise they can keep it and have separate upload limits for anon users and users that have put the correct UI_PASSWORD on the /login page first

I don't have time to implement this myself, but maybe you or someone else can take a crack at it @AliMickey.

[timvisee]

CC @pirate

Thanks for taking a look into it. I do have some comments though.

From reading through the code just now, it looks like a pretty decent auth system is actually already implemented in Send.

Mozilla did indeed implement this. I am not sure if it was ever fully finished, and we're actually in the progress of fully removing it (see https://gitlab.com/timvisee/send/-/issues/3).

I'm not sure if Send uses plain OAuth 2.0, or if it uses one of FXA's other hand-rolled auth protocols, that's something you'd have to dig into.

It has been a while since I inspected their implementation, but I believe it was OAuth 2.0 with some hand rolled additions.

Direct users to configure ANON_MAX_FILE_SIZE=0 if they want non-authed users to not be able to upload at all, (...)

The ANON_MAX_FILE_SIZE variable has actually been removed.

---

Your proposed implementation seems like a valid approach. Thanks for writing it down!

[pirate]

Ah cool, didn't realize there was existing work to remove the old system. My proposed approach definitely wont work if the ANON_ values are totally removed, so scratch that path.

I think a minimalist login page -> cookie set -> header passed to unlock websocket as you originally suggested makes sense. We can tiptoe around the old auth code and leave the task of removing it for later.

[dylangerdaly]

Feel free to use my commit -> https://github.com/dylangerdaly/send/tree/password_protect

I've re-jigged the 'password' prompt to be used for authentication, it's super hacky and shouldn't be considered 'good'

[timvisee]

Feel free to use my commit -> https://github.com/dylangerdaly/send/tree/password_protect

I've re-jigged the 'password' prompt to be used for authentication, it's super hacky and shouldn't be considered 'good'

Nice work. At this moment your changes assume there always is a password to authenticate with, right? Meaning, this implementation doesn't make it optional.

[dylangerdaly]

Currently it's shoved in there, I'll try add a new UI element based on a config conditional time permitting.