Entering credentials in the app

[leafcutterant]

Would it be possible to enter an integration's credentials within the application? It feels very unsecure to enter one service's credentials on another's website. There's no simple way of being assured that the site is really what it looks like (could be the result of a MITM attack), or what code you're interacting with.

[moughxyz]

You enter your credentials on that service's website. This is the safest possible way to do it. This is what OAuth is designed to solve.

[leafcutterant]

Right, I didn't try all options. What you wrote applies to Dropbox and Google Drive. My issues are with WebDAV and AWS.

When I want to add one of these, a browser tab loads a page from filesafe.standardnotes.org and asks me to enter my login credentials. What website code is loaded (and thus what my credentials will be used for) is pretty much out of my control, so I think this is unsafe. Or am I missing something?

Maybe the integration type chooser should be within the app, and the whole flow should stay in the app for WebDAV and AWS, and should open a browser tab only for integrations that do the authentication on their own website (Dropbox and Google Drive).

[moughxyz]

Well the page that asks for your WebDAV/AWS credentials is our stateless relay server, which does not persist data. However, even if you avoid giving credentials on this page, you'll have to give credentials for each file upload/download request, otherwise the relay server won't know how to connect to your service.

[leafcutterant]

I think I get it how it's unavoidable to give credentials in those cases [1]. My problem is with the interface where I enter them. If it were baked into the app, I could trust it because of installer signatures or the availability of the source code. When it's on the website, all I can do is I crossing my fingers the website is genuine and there's no effective MITM.

[1] Although, for WebDAV, per-app authentication would be better than giving universal access. Last time I checked it was possible to generate app-specific passwords in Nextcloud.

[moughxyz]

When it's on the website, all I can do is I crossing my fingers the website is genuine and there's no effective MITM.

The point is that your credentials are given to our "website" (which is just the relay server) every time you perform a request. So in the course of downloading/viewing 100 files, our relay server will receive your service credentials 100 times. So this is inherent to the architecture.

With Dropbox/Google Drive, OAuth is used, and so those credentials are random tokens. But with WebDAV/AWS, the credentials are specific passwords. Although our AWS instructions center around creating a specific user for FileSafe, and you might be able to do the same with WebDAV.

[alexbakker]

@mobitar In the case of WebDAV, why does a relay server need to be involved at all? Wouldn't it be possible to store the credentials in the encrypted Standard File and have the client connect to the WebDAV server directly?

[moughxyz]

FileSafe is designed so that clients only have to speak 1 language: the relay server language. If we introduced client-side integrations we'd need to find client-side SDKs for each integration, which is not always possible (server-side SDKs are much more common).