Zuerst danke für 4.0.x — das Update lief hier sauber durch, und dass ihr euch
die Zugangsdaten überhaupt vorgenommen habt, finde ich gut. Beim Nacheintragen
der Token sind mir zwei Dinge aufgefallen, die ich gern zurückspiele. Beides
ist keine Fehlfunktion des Backups, eher eine Frage, wie weit die Zusage aus
der Release-Notiz reicht:
„Mit dieser Version wurde der Datensicherheit noch mehr Aufmerksamkeit
gewidmet, und die Werte für das Dropbox-Zugriffstoken, den Grafana-API-Schlüssel
und das InfluxDB-Token wurden verschlüsselt. Nach dem Update müssen diese Token
in der Backitup-Konfiguration erneut eingegeben werden!"
1. Im InfluxDB-Multi-Modus greift die Verschlüsselung nicht
encryptedNative in der io-package.json listet influxDBToken, also das
Einzelfeld. Bei aktiviertem „Backup mehrerer Systeme" nutzt der Adapter aber
influxDBEvents[].token — und Array-Elemente kann encryptedNative
prinzipbedingt nicht erfassen. Der Token bleibt dort im Klartext stehen:
$ iobroker object get system.adapter.backitup.0
...
"influxDBEvents": [
{ "dbName": "iobroker_14d", "nameSuffix": "14d", "token": "<88 Zeichen im Klartext>", ... },
...
]
"influxDBToken": "" <- im Multi-Modus ungenutzt
Zum Vergleich steht cifsPassword daneben als $/aes-192-cbc:….
Für die anderen Multi-Tabellen gibt es den Entschlüsselungspfad ja schon —
decryptEvents() in src/main.ts behandelt ccuEvents[].pass,
mySqlEvents[].pass und pgSqlEvents[].pass. influxDBEvents[].token ist die
einzige Multi-Tabelle ohne Gegenstück, was für mich eher nach einer Lücke beim
Nachziehen aussieht als nach Absicht.
Von außen ist das schwer zu erkennen: die Spalte ist type: 'password' wie
überall sonst, wird also maskiert eingegeben. Wer die Release-Notiz liest und
den Token neu einträgt, geht verständlicherweise davon aus, dass er nun
verschlüsselt liegt.
2. Für gesicherte Daten trägt die Verschlüsselung nicht weit
Der Schlüssel wandert mit ins Backup. system.config.native.secret steht
unverschlüsselt in objects.jsonl, und genau diese Datei landet in
iobroker_<datum>_backupiobroker.tar.gz und damit bei Dropbox, Google Drive,
OneDrive, WebDAV oder FTP. An einem frischen Archiv nachgesehen:
$ tar -xzOf iobroker_2026_09_05-10_00_02_backupiobroker.tar.gz | grep -c -F "<Wert von system.config.native.secret>"
1
Wer das Archiv hat, hat also die verschlüsselten Werte und den Schlüssel dazu.
Das betrifft alle $/aes-…-Felder aller Adapter, nicht nur backitup — für die
adaptereigene decrypt() (XOR mit demselben Systemschlüssel) gilt es
entsprechend.
Der Nutzen bleibt damit: Schutz vor Blicken in die Admin-Oberfläche und vor
Werten in Logdateien. Das ist real und keine Kleinigkeit. Nur beim Szenario
„Archiv liegt in der Cloud" ändert sich nichts — und weil die Release-Notiz von
Datensicherheit spricht, könnte man das leicht mitlesen.
Randnotiz: der Dropbox-TokenRefresher liegt im Backup
Das Gleiche trifft die Dropbox-Zugangsdaten, und zwar an
encryptedNative vorbei. native.dropboxAccessToken ist nach dem Update
verschlüsselt; das tatsächlich genutzte Credential liegt aber im State
backitup.0.info.dropboxTokens, den der TokenRefresher gegen
https://oauth2.iobroker.in/dropbox pflegt (src/main.ts, instanceObjects
in der io-package.json). Dieser State ist unverschlüsselt und enthält neben
dem kurzlebigen access_token auch den nicht ablaufenden refresh_token.
States sichert backitup mit, in backup/states.jsonl:
$ tar -xzf iobroker_2026_09_05-10_00_02_backupiobroker.tar.gz
$ grep -rl "<Wert von refresh_token>" .
backup/states.jsonl
Der TokenRefresher kommt aus adapter-core, das Speichermuster ist also nichts
backitup-Eigenes — backitup ist nur die Stelle, an der der State das Haus
verlässt. Ich erwähne es, weil es für Dropbox genau den Punkt betrifft, den die
Verschlüsselung von native.dropboxAccessToken adressieren wollte.
Ideen, falls hilfreich
influxDBEvents[].token analog zu den anderen Multi-Tabellen behandeln —
dann ist das Verhalten wenigstens in sich stimmig. Falls das aus anderen
Gründen nicht gewollt ist, wäre auch ein Hinweis in der Oberfläche bei
aktiviertem Multi-Modus schon viel wert.- Vielleicht ein Satz in der Doku oder Release-Notiz dazu, wogegen die
Verschlüsselung schützt und wogegen nicht. Das nimmt Erwartungen raus, ohne
dass sich am Code etwas ändern muss.
- Ob der Refresh-Token wirklich in einem normalen State liegen muss, ist wohl
eher eine Frage an adapter-core als an euch — wollte es aber nicht
unerwähnt lassen.
- Wirklich zu lösen wäre der Cloud-Fall nur über eine Verschlüsselung des
Archivs selbst mit einer Passphrase, die nicht in ioBroker liegt. Mir ist
klar, dass das eine deutlich größere Sache ist und vermutlich weit über
diese Meldung hinausgeht — ich nenne es nur der Vollständigkeit halber.
Wenn etwas davon schon bekannt oder bewusst so entschieden ist, ignoriert es
einfach. Falls ihr Details oder Tests aus meinem Setup braucht, liefere ich
gern nach.
Umgebung
- Backitup 4.0.3, js-controller 7.2, Node 22
- InfluxDB 2.9.1, InfluxDB-Backup im Multi-Modus mit vier Buckets
- Dropbox als Ziel aktiv
Zuerst danke für 4.0.x — das Update lief hier sauber durch, und dass ihr euch
die Zugangsdaten überhaupt vorgenommen habt, finde ich gut. Beim Nacheintragen
der Token sind mir zwei Dinge aufgefallen, die ich gern zurückspiele. Beides
ist keine Fehlfunktion des Backups, eher eine Frage, wie weit die Zusage aus
der Release-Notiz reicht:
1. Im InfluxDB-Multi-Modus greift die Verschlüsselung nicht
encryptedNativein derio-package.jsonlistetinfluxDBToken, also dasEinzelfeld. Bei aktiviertem „Backup mehrerer Systeme" nutzt der Adapter aber
influxDBEvents[].token— und Array-Elemente kannencryptedNativeprinzipbedingt nicht erfassen. Der Token bleibt dort im Klartext stehen:
Zum Vergleich steht
cifsPassworddaneben als$/aes-192-cbc:….Für die anderen Multi-Tabellen gibt es den Entschlüsselungspfad ja schon —
decryptEvents()insrc/main.tsbehandeltccuEvents[].pass,mySqlEvents[].passundpgSqlEvents[].pass.influxDBEvents[].tokenist dieeinzige Multi-Tabelle ohne Gegenstück, was für mich eher nach einer Lücke beim
Nachziehen aussieht als nach Absicht.
Von außen ist das schwer zu erkennen: die Spalte ist
type: 'password'wieüberall sonst, wird also maskiert eingegeben. Wer die Release-Notiz liest und
den Token neu einträgt, geht verständlicherweise davon aus, dass er nun
verschlüsselt liegt.
2. Für gesicherte Daten trägt die Verschlüsselung nicht weit
Der Schlüssel wandert mit ins Backup.
system.config.native.secretstehtunverschlüsselt in
objects.jsonl, und genau diese Datei landet iniobroker_<datum>_backupiobroker.tar.gzund damit bei Dropbox, Google Drive,OneDrive, WebDAV oder FTP. An einem frischen Archiv nachgesehen:
Wer das Archiv hat, hat also die verschlüsselten Werte und den Schlüssel dazu.
Das betrifft alle
$/aes-…-Felder aller Adapter, nicht nur backitup — für dieadaptereigene
decrypt()(XOR mit demselben Systemschlüssel) gilt esentsprechend.
Der Nutzen bleibt damit: Schutz vor Blicken in die Admin-Oberfläche und vor
Werten in Logdateien. Das ist real und keine Kleinigkeit. Nur beim Szenario
„Archiv liegt in der Cloud" ändert sich nichts — und weil die Release-Notiz von
Datensicherheit spricht, könnte man das leicht mitlesen.
Randnotiz: der Dropbox-TokenRefresher liegt im Backup
Das Gleiche trifft die Dropbox-Zugangsdaten, und zwar an
encryptedNativevorbei.native.dropboxAccessTokenist nach dem Updateverschlüsselt; das tatsächlich genutzte Credential liegt aber im State
backitup.0.info.dropboxTokens, den derTokenRefreshergegenhttps://oauth2.iobroker.in/dropboxpflegt (src/main.ts,instanceObjectsin der
io-package.json). Dieser State ist unverschlüsselt und enthält nebendem kurzlebigen
access_tokenauch den nicht ablaufendenrefresh_token.States sichert backitup mit, in
backup/states.jsonl:Der
TokenRefresherkommt aus adapter-core, das Speichermuster ist also nichtsbackitup-Eigenes — backitup ist nur die Stelle, an der der State das Haus
verlässt. Ich erwähne es, weil es für Dropbox genau den Punkt betrifft, den die
Verschlüsselung von
native.dropboxAccessTokenadressieren wollte.Ideen, falls hilfreich
influxDBEvents[].tokenanalog zu den anderen Multi-Tabellen behandeln —dann ist das Verhalten wenigstens in sich stimmig. Falls das aus anderen
Gründen nicht gewollt ist, wäre auch ein Hinweis in der Oberfläche bei
aktiviertem Multi-Modus schon viel wert.
Verschlüsselung schützt und wogegen nicht. Das nimmt Erwartungen raus, ohne
dass sich am Code etwas ändern muss.
eher eine Frage an adapter-core als an euch — wollte es aber nicht
unerwähnt lassen.
Archivs selbst mit einer Passphrase, die nicht in ioBroker liegt. Mir ist
klar, dass das eine deutlich größere Sache ist und vermutlich weit über
diese Meldung hinausgeht — ich nenne es nur der Vollständigkeit halber.
Wenn etwas davon schon bekannt oder bewusst so entschieden ist, ignoriert es
einfach. Falls ihr Details oder Tests aus meinem Setup braucht, liefere ich
gern nach.
Umgebung