Ich stelle mich gerade beim googlen wahrscheinlich ein bisschen blöd an, denn es geht mir um die Verschlüsselung von Zugangsdaten. Ich suche einen geeigneten Algorithmus, der insbesondere für die Verschlüsselung von vielen, kurzen Klartexten geeignet ist und bin leider nicht in der Lage, Ergebnisse zu finden, in denen verschiedene Algorithmen miteinander verglichen werden*.
Ich habe im Kopf, dass blowfish dafür wohl ganz gut geeignet ist. Ich kann aber nicht mehr nachvollziehen, wie ich darauf komme. Natürlich könnte ich auch AES oder Twofish (welchem von Bruce Schneier gegenüber blowfish der Vorzug gegeben wird) verwenden, finde aber keine Informationen, die die Vor- und Nachteile der verschiedenen Algorithmen (und verschiedenen Betriebsmodi für dieses Einsatzszenario) gegeneinander abwiegt.
Kann mir vielleicht jemand passende Suchbegriffe oder gar Papers geben?
Viele Grüße
Christian
die Ergebnisse beziehen sich alle auf Passworthashes, obwohl ich nach “encryption” gesucht habe…
Doch, die werden entschlüsselt.
Ich hatte ja auch geschrieben, dass ich Zugangsdaten verschlüsseln möchte. Und die kann ich nicht mehr verwenden, wenn ich eine Einweg-Hashfunktion benutze.
Die Verschlüsselung deshalb, damit die Zugangsdaten nicht klar in der Datenbank gespeichert sind. Den Schlüssel speichere ich dann in einer Datei.
Es geht mir nicht um Benutzerauthentifizierung, sondern um die Anmeldung an einer Datenbank mit verschiedenen Zugangsdaten (Berechtigung auf unterschiedliche, mandantenabhängige Schemata).
*** Edit ***
P. S.: Passworte, die nicht entschlüsselt werden müssen, hashe ich mit bcrypt.
um es mal zu erwähnen, auch wenn es vielleicht zu viel Kleinklein wird und du eher Links zu großen Vergleichen suchst:
wenn du als Schlüssel eine ganze Datei verwenden kannst statt nur Master-Passwort einzutippen (was ja sicherer wäre),
dann beziehe als Möglichkeit One-Time-Pad – Wikipedia ein,
bei einem zufälligen Schlüssel ohne diesen wohl kaum knackbar,
kleine Datenmengen machen die Verwendung praktikabel, eine mittlere Datei reicht für gesamte Passwort-Datei,
auch vor genormten Leerzeichen, Zeilenumbrüchen, sonstigen erratbaren Klartext zwischen den Passwörtern für Angriffe keine Angst zu haben, es muss nicht drauf verzichtet werden,
aber nicht verschiedene Klardaten, nicht nach Löschen nach vorne verschobene Daten mit demselben Schlüssel verschlüsseln,
hinten angefügte neue Klardaten für bisher nicht verwendete Bereiche des Schlüssels aber ok
(alles nur Vermutung ohne jede Umsetzungserfahrung)
Du suchst einen symmetrischen Verschlüsselungsalgorithmus. Die Symmetrischen sind sowieso alle sehr schnell. Denke nicht, dass Du da einen suchen musst, der speziell für viele kurze Texte geeignet ist.
Mir geht es nicht um die Performance, sondern vielmehr um Probleme, die entstehen, wenn man viele Blöcke mit demselben Schlüssel verschlüsselt. Ich kann mir vorstellen, dass bei AES im CBC-Modus Patterns entstehen, wie beim ECB-Modus, zumindest, wenn man für alle Nutzernamen / Passworte den selben IV nutzt.
Da ich kein Kryptologe bin, suche ich nach fundierten Informationen zum Thema Verschlüsselung von Zugangsdaten / kurzen Textblöcken und einem dafür geeigneten Algorithmus.
@SlaterB ein OTP könnte man tatsächlich zur Verschlüsselung der Zugangsdaten verwenden. Dabei gäbe es aber einige Probleme bei der Umsetzung zu beachten (wie das von Dir bereits angesprochene Löschen von Datensätzen, aber auch die Beachtung der Reihenfolge (die Datensätze liegen in einer Datenbank) und ein Mapping auf eine bestimmte „Schlüsselzone“). Das ganze würde wohl zu einer „Frickellösung“ führen, die mit Kryptographie nicht mehr allzu viel zu tun hätte.
*** Edit ***
Wahrscheinlich tut es ein beliebiger moderner Verschlüsselungsalgorithmus (AES, Blowfish, Twofish, …) gleichermaßen. Aber wenn es da einen gibt, der besser als andere geeignet ist, dann spricht wahrscheinlich nichts dagegen, eben diesen den anderen vorzuziehen.
Naja, dann könnte ich aber auch gleich AES verwenden und zusätzlich mittels [japi]SecureRandom[/japi] generierte Initialisierungsvektoren abspeichern. Die Umsetzung in Java wird dabei nahezu trivial.
Ich hatte auch nicht vor, AES oder was auch immer selbst zu implementieren. AES kommt mit Java mit (zumindest in der von mir verwendeten JVM) und nicht mitgelieferte Algorithmen lassen sich z. B. per JCE und bouncycastle einbinden. Aber GnuPG und Java, das passt mMn nicht so gut zusammen.
Trotzdem irgendwie komisch - normalerweise werden Passwörter eben NIE entschlüsselt, jedes Security-Audit wird dir das um die Ohren hauen.
Diese Datei ist natürlich sicher?!
Wenn du so was wie: Benutzer meldet sich in Middleware an, dann wählt er eine Datenbank aus und die Zugangsdaten für den DB-Zugriff auf diese gewählte DB kommen dann…woher eigentlich? Du hast die irgendwo „verschlüsselt gespeichert“ und holst sie dir dann, wozu du sie entschlüsseln musst, wozu der Schlüssel nötig ist…handgestrickt programmiert…usw.
Verwende etablierte Mechanismen (z.B. via JNDI erreichbare Datenbanken, so dass du nur den jndi-Namen kennen musst), oder Windows-Domänen-Gruppenrichtlinien oder oder oder…
Ich denke, dass das besser ist, als die Zugangsdaten zur Datenbank klar in der Datenbank zu speichern.
Nein, die Datei ist natürlich auch nicht unbedingt sicher. Allerdings dient sie als zweiter Faktor. Die Datenbank, in der die Zugangsdaten gespeichert sind, bringen einem alleine nichts. Dasselbe gilt für die Schlüsseldatei. Erst wenn beides zusammenkommt, dann hat man die Zugangsdaten. Die Zugangsdaten liegen sowieso unverschlüsselt im Speicher, wenn die Anwendung läuft, weil zur Laufzeit durch den Connectionpool natürlich Datenbankverbindungen aufgebaut werden müssen. Eine Kompromittierung des Servers auf dem der Tomcat läuft würde also dazu führen, dass die Zugangsdaten bekannt würden.
Das ganze sieht etwa so aus: es ist eine mehrmandantenfähige Anwendung, die mit hibernate als JPA-Implementierung läuft. Hibernate unterstützt mehrere Mandanten. Dazu habe ich das Interface MultiTenantConnectionProvider implementiert.
Natürlich könnte ich die Datasources auch mittels JNDI abholen. Mit dem selbst implementierten ConnectionProvider bin ich aber flexibler, da auch während der Laufzeit ohne Manipulation des JNDI neue Mandanten hinzu kommen oder gelöscht werden können.
In einer eigenen PersistenceUnit für mandantenübergreifende Entities sind unter anderem auch die Datenbankeinstellungen der verschiedenen Mandanten gespeichert (maximale Anzahl gleichzeitiger Verbindungen, Schemaname, … und eben auch die Zugangsdaten). Denn jeder Mandant hat ein eigenes Schema, welches mit eigenen Zugangsdaten geschützt ist.
*** Edit ***
Ich habe jetzt vorerst einmal AES verwendet, das funktioniert auch alles so, wie ich es mir vorstelle. Falls doch noch jemand einen guten Hinweis hat, welcher Algorithmus besser geeignet ist, nehme ich den Hinweis gerne an und setze das entsprechend um. Viel Aufwand ist das nicht, da die Verschlüsselung in einem BytesEncryptor gekapselt ist, der als Bean im Anwendungskontext publiziert wird.