Transparenz-Dokumentation für Kunden und Partner
Stand: April 2026
Der SOPHA NG Server schützt Ihre Daten mit bewährten, wissenschaftlich
validierten kryptographischen Verfahren. Wir setzen ausschließlich auf Algorithmen,
die international standardisiert und von Sicherheitsforscher:innen geprüft sind —
keine Eigenentwicklungen, keine "Security through Obscurity".
Dieses Dokument beschreibt transparent, welche Verfahren wir einsetzen und warum.
Es richtet sich an:
Wer es technisch noch detaillierter möchte, findet weiterführende Informationen
in unserem Entwickler-Handbuch (auf Anfrage verfügbar).
Transparenz. Wir dokumentieren öffentlich, welche Algorithmen wir einsetzen.
Unsere Sicherheit basiert auf der Stärke der Verfahren, nicht auf deren Geheimhaltung.
Defense-in-Depth. Mehrere Sicherheits-Schichten sichern sensible Daten.
Wenn eine Schicht versagt, sind die anderen noch intakt.
Standards statt Eigenentwicklung. Wir verwenden ausschließlich anerkannte,
von Kryptograph:innen geprüfte Verfahren (NIST-Standards, RFC-Spezifikationen,
OWASP-Empfehlungen).
Keine Kompromisse bei Zufallszahlen. Alle kryptographischen Zufallszahlen
stammen aus kryptographisch sicheren Zufallszahlengeneratoren (CSPRNG) des
Betriebssystems.
Zukunftssicher. Unsere Architektur erlaubt den Wechsel auf stärkere
Algorithmen, sobald diese verfügbar oder nötig werden — ohne Datenverlust.
Ihre Passwörter werden niemals im Klartext gespeichert — weder in der Datenbank,
noch in Log-Dateien, noch in Backups. Stattdessen speichern wir einen
kryptographischen Hash, der sich nicht rückrechnen lässt.
Verfahren: Argon2id
Argon2id ist der Gewinner der internationalen Password Hashing Competition
(2013–2015) und wird von OWASP als aktueller Best-Practice-Standard empfohlen.
Es ist speziell darauf ausgelegt, Brute-Force-Angriffe mit spezialisierter
Hardware (z. B. GPUs, FPGAs) zu erschweren.
Unsere Konfiguration (nach OWASP-Empfehlung):
Eine einzelne Hash-Berechnung dauert etwa 0,5–1 Sekunde auf einem modernen
Server. Für einen Angreifer, der Millionen von Passwörtern pro Sekunde testen
wollen würde, wäre das eine unüberwindbare Hürde.
Wir kombinieren drei Schutz-Schichten:
① Salt (individuell pro Benutzer)
Ein zufälliger, einzigartiger Wert pro Benutzer-Konto. Dies verhindert, dass
dieselben Passwörter den gleichen Hash erzeugen (Schutz gegen sogenannte
Rainbow-Table-Angriffe).
② Pepper (System-Geheimnis)
Ein zusätzliches Geheimnis, das nur im Server-Code und nicht in der Datenbank
liegt. Selbst wenn ein Angreifer die komplette Datenbank erbeuten würde, könnte
er ohne diesen Pepper keine Passwörter knacken.
③ Argon2id (Memory-Hard-Hashing)
Der eigentliche Hash-Algorithmus, der jeden Rateversuch extrem rechenintensiv
macht.
Konkrete Passwort-Richtlinien (Mindestlänge, Komplexität, Gültigkeitsdauer)
sind projektabhängig konfigurierbar und werden gemeinsam mit Ihnen im Rahmen
der Einrichtung festgelegt. Als Orientierung dienen die aktuellen BSI- und
OWASP-Empfehlungen.
Unser Zugangs-Konzept unterscheidet zwei Szenarien:
Für Benutzer:innen, die ausschließlich aus dem geschützten Firmennetz zugreifen
(z. B. Kassen-Arbeitsplätze, Backoffice-PCs), ist die Anmeldung per Benutzername
und Passwort ausreichend. Die starke Passwort-Härtung mit Argon2id schützt
gegen Offline-Angriffe, und der Netzwerk-Perimeter bietet zusätzlichen Schutz.
Für Zugriffe aus dem Internet (Remote-Arbeit, mobile Geräte, Support-Zugänge)
wird zusätzlich eine Zwei-Faktor-Authentifizierung (2FA) eingesetzt. Die
konkrete Ausprägung wird je nach Kundenanforderung gewählt. Gängige Optionen:
① TOTP — Authenticator-Apps (empfohlene Standard-Variante)
Zeitbasierte Einmal-Codes nach RFC 6238. Der Benutzer installiert eine App
auf dem Smartphone (z. B. Google Authenticator, Microsoft Authenticator,
Authy, 1Password) und gibt zusätzlich zum Passwort einen 6-stelligen Code
ein, der sich alle 30 Sekunden ändert.
② FIDO2 / WebAuthn — Hardware-Sicherheits-Token
Hardware-Schlüssel (z. B. YubiKey, Google Titan) oder plattform-integrierte
Authentifikatoren (Windows Hello, Touch ID, Face ID). Der zweite Faktor ist
ein kryptographischer Schlüssel, der sich nicht abgreifen oder phishen lässt.
③ Passkeys (moderne Alternative)
Passwortlose Anmeldung auf FIDO2-Basis. Das Gerät (Smartphone, Notebook)
speichert einen kryptographischen Schlüssel und authentifiziert den Benutzer
biometrisch (Fingerabdruck, Gesicht) oder per PIN. Passwort und zweiter Faktor
entfallen, bei identisch hoher Sicherheit.
④ SMS-TAN (nur bei fehlender Alternative)
Einmal-Code per SMS. Wird nur eingesetzt, wenn andere Verfahren für die
Zielgruppe nicht praktikabel sind.
⑤ E-Mail-Einmal-Code
Einmal-Code per E-Mail. Sinnvoll als Fallback oder für weniger sensible
Bereiche.
⑥ Push-Benachrichtigungen (bei entsprechender Infrastruktur)
Anmeldung per Bestätigung in einer Unternehmens-App auf dem Smartphone.
Benutzerfreundlich, erfordert aber zusätzliche App-Infrastruktur.
Wiederherstellung bei Verlust des zweiten Faktors
Für alle 2FA-Varianten werden Backup-Codes generiert, die der Benutzer
sicher aufbewahrt. Alternativ kann ein Admin über einen dokumentierten
Prozess (inkl. Identitätsprüfung) den zweiten Faktor zurücksetzen.
Unsere Empfehlung für die meisten Anwendungsfälle:
Für die Verschlüsselung vertraulicher Informationen setzen wir AES-256-CBC
ein, den De-facto-Standard für symmetrische Verschlüsselung, kombiniert mit
einer HMAC-SHA256-Integritätsprüfung.
Warum diese Kombination?
AES-256 allein schützt zwar gegen Lesen, aber nicht gegen Manipulation. Durch
den zusätzlichen HMAC-Schutz (Encrypt-then-MAC-Konstrukt) erkennen wir jede
nachträgliche Veränderung der verschlüsselten Daten. Dies ist ein seit
Jahrzehnten in Hochsicherheits-Umgebungen bewährtes Verfahren (u. a. in
IPsec-VPNs und SSH).
Konfigurations-Dateien
Passwörter und Zugangsdaten in Server-Konfigurationsdateien (z. B. SMTP-Credentials,
Datenbank-Passwörter) werden transparent verschlüsselt gespeichert. Der Klartext
ist niemals im Dateisystem zu sehen.
Einzelne Datenbank-Spalten (nach Bedarf / konfigurierbar)
Besonders sensible Felder können auf Spaltenebene verschlüsselt werden. Dies
geschieht transparent für die Anwendung und schützt selbst bei direktem
Datenbank-Zugriff.
Backups (in Vorbereitung)
Datenbank- und Konfigurations-Backups werden mit einem vom Kunden verwalteten
Schlüssel verschlüsselt, sodass selbst gestohlene Backup-Medien keinen Zugriff
auf Ihre Daten gewähren.
Wir setzen auf hierarchische Schlüssel-Ableitung nach dem HKDF-Verfahren
(HMAC-based Key Derivation Function, RFC 5869). Aus einem einzigen
hochentropen Master-Geheimnis werden kryptographisch unabhängige Schlüssel
für unterschiedliche Zwecke abgeleitet:
Vorteil: Ein Kompromiss eines abgeleiteten Schlüssels gefährdet die anderen
nicht.
Alle kryptographischen Zufallszahlen (Salt, IV, Session-Keys) stammen aus dem
kryptographisch sicheren Zufallszahlengenerator des Betriebssystems:
BCryptGenRandom (Windows CNG API) und RtlGenRandomgetrandom() Syscall bzw. /dev/urandomDiese APIs sind zertifiziert (FIPS 140-2 / Common Criteria) und werden vom
jeweiligen Betriebssystem-Kernel bereitgestellt.
Der SOPHA NG Server besteht aus mehreren kooperierenden Diensten (Modulen).
Diese authentifizieren sich untereinander mit zeitgebundenen HMAC-Token:
Dieses Verfahren schützt gegen unautorisierten Zugriff eines internen Services
und gegen Replay-Angriffe.
Angemeldete Benutzer:innen erhalten ein JSON Web Token (JWT) nach RFC 7519:
Die Signatur stellt sicher, dass das Token nicht manipuliert werden kann. Der
Signierungsschlüssel ist ausschließlich auf dem Server bekannt.
| Standard | Verfahren | Einsatz |
|---|---|---|
| RFC 9106 | Argon2 Password Hashing | Passwort-Schutz |
| NIST FIPS 197 | AES (Advanced Encryption Standard) | Daten-Verschlüsselung |
| NIST SP 800-38A | Block-Cipher-Betriebsmodi (CBC) | AES-Modus |
| RFC 2104 | HMAC (Keyed-Hash Message Authentication Code) | Integrität |
| NIST FIPS 180-4 | SHA-2 Hash-Funktionen | Hashing |
| RFC 5869 | HKDF (HMAC-based Key Derivation) | Schlüssel-Ableitung |
| RFC 7519 | JSON Web Token (JWT) | Session-Token |
| OWASP Password Storage Cheat Sheet | Best Practices | Passwort-Handhabung |
Unsere kryptographischen Maßnahmen unterstützen Ihre Compliance-Anforderungen
nach Art. 32 DSGVO (Sicherheit der Verarbeitung) durch:
Kassensicherungsverordnung (KassenSichV)
Für den Einsatz als POS-System arbeiten wir mit zertifizierten
Technischen Sicherheitseinrichtungen (TSE) zusammen, die unabhängige
ECDSA-Signaturen über alle Kassenvorgänge erzeugen.
Zahlungsverkehr (PCI DSS)
Bei Integration von Zahlungsdienstleistern (z. B. Payone) werden Karten-Daten
niemals auf unseren Systemen gespeichert — sie werden direkt an den
zertifizierten Zahlungsdienstleister weitergeleitet.
Alle Kommunikationsverbindungen zwischen Client und Server sollten über
TLS 1.2 oder höher abgesichert werden. Dies wird üblicherweise über einen
vorgelagerten Reverse-Proxy (z. B. nginx, Apache) oder Load-Balancer sichergestellt.
Empfohlene TLS-Konfiguration:
Wir unterstützen Sie gerne bei der Konfiguration.
Kryptographie entwickelt sich stetig weiter. Wir beobachten laufend neue
Entwicklungen und planen folgende Erweiterungen:
Wir setzen hier (Backend-Kryptografie) ausschließlich Open-Source-Bibliotheken mit einsehbarem Quellcode ein:
| Bibliothek | Zweck | Lizenz |
|---|---|---|
| HashLib4Pascal | Hash-Funktionen, Argon2id | MIT |
| CryptoLib4Pascal | AES, HKDF, RNG | MIT |
| SimpleBaseLib4Pascal | Base64/Hex-Kodierung | MIT |
Alle Bibliotheken sind nachvollziehbar auf GitHub dokumentiert und wurden von
uns auditiert.
Bei Fragen zu unseren Sicherheits-Maßnahmen wenden Sie sich gerne an uns.
Wir begrüßen verantwortungsvolle Schwachstellen-Meldungen (Responsible Disclosure).
AES (Advanced Encryption Standard)
Der seit 2001 international standardisierte Verschlüsselungs-Algorithmus. Wird
vom US-Militär für Daten bis "Top Secret" zugelassen (bei 256-Bit-Schlüsseln).
Argon2id
Moderner Passwort-Hashing-Algorithmus, Gewinner der Password Hashing Competition
2015. Kombiniert Memory-Hardness mit Side-Channel-Resistenz.
CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
Ein Zufallszahlengenerator, dessen Ausgabe nicht vorhersagbar ist und von echtem
Zufall praktisch nicht unterscheidbar ist.
Hash
Eine Einweg-Funktion, die aus beliebigen Daten einen Wert fester Länge erzeugt,
aus dem sich die Eingabe nicht rekonstruieren lässt.
HKDF (HMAC-based Key Derivation Function)
Ein Verfahren, um aus einem Master-Schlüssel mehrere unabhängige Unter-Schlüssel
abzuleiten.
HMAC (Hash-based Message Authentication Code)
Ein Verfahren, das kryptographisch garantiert, dass eine Nachricht nicht verändert
wurde und vom erwarteten Absender stammt.
JWT (JSON Web Token)
Ein kompaktes, signiertes Token-Format für Authentifizierungs- und
Autorisierungs-Zwecke.
Pepper
Ein zusätzliches systemseitiges Geheimnis beim Passwort-Hashing — ergänzt den
Salt und liegt nicht in der Datenbank.
Salt
Ein zufälliger Wert pro Passwort, der verhindert, dass zwei gleiche Passwörter
den gleichen Hash erzeugen.
TLS (Transport Layer Security)
Das Standard-Protokoll für verschlüsselte Kommunikation im Internet
(frühere Bezeichnung: SSL).
Änderungshistorie
© SOPHA Software