Sicherer Zugangsdatenspeicher 6.2.0 erschienen

1. offizieller Beitrag
    • Offizieller Beitrag

    Seit wenigen Minuten steht das Produkt "Sicherer Zugangsdatenspeicher" in der neuesten Version 6.2.0 (WSC 6.2) zur Verfügung. Das Update kann über den Kundenbereich bezogen werden. Wir bieten das Update auch über unseren Updateserver (Pakete über den Paketserver aktualisieren (WSC 3.x / WSC 5.x / WSC 6.x)) an. Ihre persönlichen Zugangsdaten finden Sie unter "Mein Konto".

    Es handelt sich hierbei um ein kostenpflichtiges Update.

    Neue Funktionen im Überblick

    Client-seitige Ver- und Entschlüsselung

    Deine sensiblen Zugangsdaten werden jetzt direkt in deinem Browser verschlüsselt und entschlüsselt – für maximale Sicherheit! Die Daten verlassen deinen Browser nur in verschlüsselter Form und werden auch nur in deinem Browser wieder entschlüsselt. Der Server sieht niemals deine Zugangsdaten im Klartext!

    Audit-Protokoll

    Volle Transparenz: Du siehst jetzt genau, wer wann auf welche Zugangsdaten zugegriffen hat. Alle Aktionen werden lückenlos protokolliert.

    Modernes BBCode-Design

    Die Zugangsdaten-Anfragen erscheinen jetzt in einem cleanen, professionellen Karten-Layout:

    • Klare Hierarchie – Wichtige Informationen fallen sofort ins Auge
    • Bessere Lesbarkeit – Optimierte Abstände und Schriftgrößen
    • Professionelle Optik – Dezente Schatten und abgerundete Ecken
    • Status-Hinweise mit farbigen Hintergründen (Info, Warnung, Erfolg)
    • Strukturierte Darstellung der Zugangsdaten mit Labels
    • Deutlich erkennbare Aktions-Buttons

    WSC 6.2 Kompatibilität

    Vollständig kompatibel mit der neuesten WoltLab Suite Core 6.2 – profitiere von allen neuen Features und Verbesserungen!

    • Form Builder – Alle Formulare nutzen jetzt den modernen Form Builder für ein einheitliches Look & Feel
    • Grid View – Konsistente Darstellung der Zugangsdaten-Listen über alle Seiten hinweg
    • Moderne UI-Komponenten – Nahtlose Integration in das WoltLab-Design

    Das Update macht die Verwaltung von Zugangsdaten-Anfragen deutlich sicherer, transparenter und übersichtlicher!

    Changelog (Version 6.2.0)

    Neue Funktionalität

  • Peter 8. März 2026 um 08:53

    Hat das Thema freigeschaltet.

    Hallo,

    Zitat von Peter

    Clientseitige Verschlüsselung der Zugangsdaten

    mich würde der konkrete Grund interessieren, weshalb die Verschlüsselung in diesem Fall auf clientseitig umgestellt wurde. Wirklich nur aus Interesse. Nach meinem Verständnis ergibt sich dabei nämlich ein mögliches gleiches Problem wie bei der Verschlüsselung auf dem Server:

    Wenn ein Angreifer den Server bereits kompromittiert hat, könnte er ebenso das Upload-Formular oder den ausgelieferten Client-Code manipulieren. In diesem Fall wäre die clientseitige Verschlüsselung doch ebenfalls angreifbar – im Grunde also ähnlich wie bei einer serverseitigen Verschlüsselung. Eventuell sogar noch stärker, da ein Angreifer zusätzlich das ausgelieferte JavaScript manipulieren und so direkt im Browser eingreifen könnte. Daher erschließt sich mir der sicherheitstechnische Vorteil der clientseitigen Verschlüsselung in diesem Szenario nicht ganz. 🤔

    Außerdem muss das Frontend die öffentlichen Schlüssel ja ebenfalls von irgendwo beziehen. Wenn der Server kompromittiert ist, könnte ein Angreifer auch diese einfach austauschen oder manipulieren.

    Gerade bei einer Webanwendung wie der WoltLab Suite sehe ich daher nicht unmittelbar den sicherheitstechnischen Mehrwert in Bezug auf den Schutz der Daten. Vielleicht übersehe ich hier aber auch einen wichtigen Aspekt, daher würde mich die konkrete Motivation für diese Änderung interessieren.

    • Offizieller Beitrag
    Zitat von itsmeJAY

    Wenn ein Angreifer den Server bereits kompromittiert hat, könnte er ebenso das Upload-Formular oder den ausgelieferten Client-Code manipulieren. In diesem Fall wäre die clientseitige Verschlüsselung doch ebenfalls angreifbar – im Grunde also ähnlich wie bei einer serverseitigen Verschlüsselung. Eventuell sogar noch stärker, da ein Angreifer zusätzlich das ausgelieferte JavaScript manipulieren und so direkt im Browser eingreifen könnte. Daher erschließt sich mir der sicherheitstechnische Vorteil der clientseitigen Verschlüsselung in diesem Szenario nicht ganz. 🤔

    Irgendwo hört die Sicherheit natürlich auf. Wenn du Daten auf den Server laden musst, hast du den Nachteil, dass der Schlüssel vom Client zum Server transportiert werden muss, d.h. theoretisch andere Personen mitlesen können (z.B. Proxies) oder Eingaben aus irgendeinem Grund geloggt werden. Das entfällt bei der clientseitigen Entschlüsselung. Wenn ein Angreifer natürlich den Code manipulieren kann, ist natürlich eine Komprimierung noch immer möglich, aber das Risiko ist geringer.

    Zitat von itsmeJAY

    Außerdem muss das Frontend die öffentlichen Schlüssel ja ebenfalls von irgendwo beziehen. Wenn der Server kompromittiert ist, könnte ein Angreifer auch diese einfach austauschen oder manipulieren.

    Ja, das Problem hast du theoretisch immer, greift aber nur bei neuen Schlüsseln. Dafür gibt es aber auch keine sinnvolle Lösung, die man mit WSC Mitteln umsetzen könnte.

    Hauptmotivation war, dass die Daten zu keinem Zeitpunkt unverschlüsselt übertragen werden, d.h. wenn jemand mitlesen kann, kann er trotzdem die Daten nicht lesen.