fix: encrypt saved FTP/SFTP credentials

[MYounas126]

Fixes #2561.

Saved FTP/SFTP servers are kept in localStorage.storageList, and the WebView writes localStorage to disk in plaintext — so the server passwords end up sitting unencrypted in app_webview/.../Local Storage/leveldb.

This PR moves that list into a native encrypted store (AES256-GCM via AndroidX Security-Crypto), which is the same mechanism the auth plugin already uses for the account token.

I started out planning to just pull the password out of the stored URL and keep it somewhere separate, but that doesn't work here: Url.parse(url).url keeps the password, and helpers.getVirtualPath matches active file URIs against that full URL to rewrite remote paths, so dropping the password breaks path display. So instead I left the in-memory data exactly as it was (the URL still has its credentials in memory, which is fine) and only changed where it's persisted — plaintext localStorage becomes an encrypted native store. That keeps the diff small and every existing reader behaves the same.

What's in here:

• A small system.secureSet / secureGet / secureRemove bridge (SecureStore.java, backed by EncryptedSharedPreferences).
• src/lib/secureStorageList.js — an in-memory cache loaded once at startup from the encrypted store, plus a one-time migration of any existing plaintext localStorage.storageList. The plaintext copy is only deleted after the encrypted write succeeds, so nobody loses their saved servers if something goes wrong mid-migration.
• The read/write sites in Uri.js, helpers.js, externalFs.js and fileBrowser.js now go through that module instead of touching localStorage.storageList directly.
• onDeviceReady awaits secureStorageList.hydrate() before anything reads the list.

Existing users' saved servers migrate automatically on the next launch — no re-entry.

I don't have the Cordova/Android build set up on my machine yet, so I haven't been able to run this on a device. Could you trigger a preview build, or tell me how you'd prefer it verified? The main things to check are: add an SFTP/FTP server, restart the app, and confirm it reconnects without asking for the password again — and that the credentials no longer appear in the localStorage leveldb.

[greptile-apps]

Greptile Summary

The PR moves saved FTP/SFTP configurations from plaintext WebView storage into an encrypted native store.

• Adds an AndroidX Security-Crypto-backed Cordova bridge.
• Migrates legacy data only after a synchronous encrypted write succeeds.
• Routes storage-list readers and writers through an in-memory hydrated cache.
• Includes the native source and crypto dependency in the Android plugin configuration.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the native source is now included in the Android plugin, and migration removes the plaintext copy only after commit succeeds and that success propagates through the Cordova promise.

Important Files Changed

Filename	Overview
src/lib/secureStorageList.js	Introduces startup hydration, guarded plaintext migration, and cached encrypted persistence for saved remote-storage configurations.
src/plugins/system/android/com/foxdebug/system/SecureStore.java	Implements encrypted SharedPreferences access with synchronous commit-based write acknowledgement.
src/plugins/system/android/com/foxdebug/system/System.java	Exposes secure set, get, and remove operations through the Cordova plugin bridge.
src/plugins/system/plugin.xml	Includes SecureStore.java and the AndroidX Security-Crypto dependency, resolving the previously reported Android source omission.
src/main.js	Hydrates the encrypted storage list before startup consumers initialize.
src/pages/fileBrowser/fileBrowser.js	Replaces plaintext storage-list reads and writes with the secure cached abstraction.

Sequence Diagram

sequenceDiagram
    participant App as WebView startup
    participant Legacy as localStorage
    participant Bridge as Cordova system bridge
    participant Secure as EncryptedSharedPreferences
    App->>Legacy: Read legacy storageList
    alt Legacy list exists
        App->>Bridge: secureSet(storageList)
        Bridge->>Secure: commit encrypted value
        Secure-->>Bridge: durable write result
        alt Write succeeds
            Bridge-->>App: Resolve
            App->>Legacy: Remove plaintext storageList
        else Write fails
            Bridge-->>App: Reject
            App->>Legacy: Preserve plaintext fallback
        end
    end
    App->>Bridge: secureGet(storageList)
    Bridge->>Secure: Read encrypted value
    Secure-->>App: Saved storage list
    App->>App: Populate in-memory cache

Loading

_{Reviews (3): Last reviewed commit: "fix(secure-store): remove plaintext fall..." | Re-trigger Greptile}

[MYounas126]

Thanks for the review! Pushed 57d8c16 addressing both points:

• Added the missing <source-file> declaration for SecureStore.java in plugin.xml so Cordova compiles it (System.java references it).
• Switched SecureStore from apply() to commit() and made secure-set report failure, so the migration only removes the plaintext storageList after the encrypted write is durably on disk — no data loss if the process is killed mid-migration.

[UnschooledGamer]

I don't have the Cordova/Android build set up on my machine yet, so I haven't been able to run this on a device. Could you trigger a preview build, or tell me how you'd prefer it verified? The main things to check are: add an SFTP/FTP server, restart the app, and confirm it reconnects without asking for the password again — and that the credentials no longer appear in the localStorage leveldb.

No problem. Changes look safe for a possible preview trigger.

[github-actions]

Preview Release for this, has been built.

Click here to view that github actions build

[UnschooledGamer]

A side note: this can break any plugins that use storageList from localStorage!

[MYounas126]

Good point, thanks for flagging it. A couple of thoughts:

storageList isn't part of the public acode plugin API (it's not in acode.define(...)), so any plugin reading it is going through localStorage directly — an internal detail rather than a supported surface.

And there's a security angle to that same access: right now any installed plugin can read localStorage.storageList and pull every saved SFTP/FTP password in cleartext. Moving it into the encrypted store removes that, which is really part of the point here — untrusted plugin code shouldn't have free read access to the user's server credentials.

That said, if there are plugins that legitimately need the saved-server list, I'm happy to add a proper accessor to the acode API that returns just the non-secret fields (alias/host/type, no password) so those keep working while credentials stay protected. Do you know of any plugins relying on it, or an API shape you'd prefer?

[bajrangCoder]

Good point, thanks for flagging it. A couple of thoughts:

storageList isn't part of the public acode plugin API (it's not in acode.define(...)), so any plugin reading it is going through localStorage directly — an internal detail rather than a supported surface.

And there's a security angle to that same access: right now any installed plugin can read localStorage.storageList and pull every saved SFTP/FTP password in cleartext. Moving it into the encrypted store removes that, which is really part of the point here — untrusted plugin code shouldn't have free read access to the user's server credentials.

That said, if there are plugins that legitimately need the saved-server list, I'm happy to add a proper accessor to the acode API that returns just the non-secret fields (alias/host/type, no password) so those keep working while credentials stay protected. Do you know of any plugins relying on it, or an API shape you'd prefer?

Yeah, there is no need for a plugin to read.

[UnschooledGamer]

@MYounas126 Well, yeah. That's the usage for these types things comes from edgey cases. Security is first, While I cannot link any plugins code related it as I'm not in a state to do so currently. It might be fine to move forward; As it was just a side note.

[UnschooledGamer]

The legitimate plugin I found other than deprecated ones due to our CM 6 Migration:

https://github.com/overskul/acode-better-filebrowser/blob/a83aaf8b4d50c12b6130141faef04b58fc6e5f81/src/BetterFileBroswer.js#L1-L98

Also, With the proposed implementation the plugins can still access them just like Acode can as long as the Java bridge provides a decoded, decrypted to the Javascript side.

[UnschooledGamer]

Yeah, there is no need for a plugin to read.

@bajrangCoder Well, no. As a Plugin needs know which folders the App has access to, which helps for URI restructuring, addedFolder doesn't provide that completely as far as I know.

[MYounas126]

Thanks, went and looked at better-filebrowser — fair point, it's a real case. It reads and writes storageList but only touches uuid/name/uri (no creds, it's just registering a local folder), so my change would break it since I'm pulling storageList out of localStorage entirely.

And you're right about the bridge as well. secureGet is reachable from any JS in the origin, so a plugin can still read the encrypted list, passwords included, the same way Acode does. So realistically all this PR buys is getting the cleartext copy off disk, which was the original #2561 concern (backups, forensics, other apps reading the webview data dir). It doesn't keep the list away from plugins, and I don't think that's really doable in a single-origin webview anyway.

So maybe a cleaner approach: keep the non-secret list in localStorage so those plugins keep working (uuid/name/uri/type), and only move the passwords into the encrypted store, keyed per entry and put back at connect time. That still fixes the at-rest issue, doesn't break the plugins, and actually keeps passwords out of the plugin-visible list. It's more work than what's here now — I avoided it at first because the password-in-url matching in getVirtualPath gets in the way, but that's fixable by stripping creds off both sides before comparing.

I'm happy to redo it that way, or keep this one as the at-rest fix and do the split as a follow-up. Whatever you two think is best.