(Anmerkung:Ich bin kein Sicherheitsexperte. Ich interessiere mich für das Gebiet, aber das war's. Denken Sie daran.)
Passwörter möglichst gar nicht speichern
Es hängt sehr davon ab, was Ihre Bedürfnisse sind. Die beste Option ist, überhaupt keine Zwei-Wege-Verschlüsselung zu verwenden; wenn Sie nur gesalzen speichern können und einweg-gehasht Passwort-Digests, das ist ideal. Sie können sie immer noch testen, um zu sehen, ob sie mit einem vom Benutzer bereitgestellten Passwort übereinstimmen, aber Sie speichern es nie.
Besser noch, wenn Ihre Clients ein vernünftiges Protokoll verwenden (dh nicht HTTP wie allgemein implementiert), können Sie einen Challenge-Response-Authentifizierungsmechanismus das bedeutet, dass Ihre App niemals nie verwendet wird muss das Passwort des Benutzers sehen, auch nicht bei der Authentifizierung. Leider ist dies im öffentlichen Web selten möglich, da es eine Sicherheit bietet, die Programmierer der 80er Jahre in den Schatten stellen würde.
Wenn Sie das Passwort speichern müssen, trennen Sie die Schlüssel von der App
Wenn Sie in der Lage sein müssen, die Passwörter zu entschlüsseln, sollten Sie idealerweise nicht alle Details dazu an einem Ort haben, und schon gar nicht an einem kopierbaren, leicht zugänglichen Ort.
Aus diesem Grund würde ich es persönlich vorziehen, PgCrypto (wie Sie es tun) für diesen Zweck nicht zu verwenden, da Sie dadurch gezwungen sind, den privaten Schlüssel und (falls vorhanden) die Passphrase dem Server preiszugeben, wo sie in PostgreSQL verfügbar gemacht werden könnten Log-Dateien oder anderweitig potenziell erschnüffelt. Ich möchte meine Krypto-Client-Seite machen, wo ich PKCS#11, einen Schlüsselagenten oder andere Tools verwenden könnte, mit denen ich die Daten entschlüsseln kann, ohne dass mein Code jemals auf den Schlüssel zugreifen kann.
Das Problem der sicheren Schlüsselspeicherung ist Teil von PKCS#11 wurde für erfunden. Es bietet eine generische Schnittstelle für Anwendungen und Kryptoanbieter, um mit allem zu kommunizieren, das bestimmte Signatur- und Entschlüsselungsdienste bereitstellen kann, ohne jemals seinen Schlüssel preiszugeben . Die übliche, aber nicht ausschließliche Verwendung erfolgt mit hardwarebasierter Kryptographie wie Smartcards und Hardware-Kryptomodulen. Solche Geräte können angewiesen werden, an sie übergebene Daten zu signieren oder zu entschlüsseln, und zwar ohne den Schlüssel jemals preiszugeben. Erwägen Sie nach Möglichkeit die Verwendung einer Smartcard oder eines HSM. Soweit ich weiß, kann PgCrypto PKCS#11 oder andere HSMs/Smartcards nicht verwenden.
Wenn Sie das nicht können, können Sie wahrscheinlich immer noch einen Schlüsselverwaltungsagenten verwenden, bei dem Sie Ihren Schlüssel manuell in ein Schlüsselverwaltungsprogramm laden, wenn der Server startet, und das Schlüsselverwaltungsprogramm eine PKCS#11- (oder eine andere) Schnittstelle bereitstellt zum Signieren und Entschlüsseln über einen Socket. Auf diese Weise muss Ihre Webanwendung den Schlüssel überhaupt nicht kennen. gpg-agent können sich für diesen Zweck qualifizieren. Auch hier gilt, soweit ich weiß, kann PgCrypto keinen Schlüsselverwaltungsagenten verwenden, obwohl es eine großartige Funktion wäre, sie hinzuzufügen.
Schon eine kleine Verbesserung kann helfen. Es ist am besten, wenn die Passphrase für Ihren Schlüssel nicht auf der Festplatte gespeichert ist, sodass Sie sie möglicherweise beim Start der App eingeben müssen, damit der Schlüssel entschlüsselt werden kann. Sie speichern den entschlüsselten Schlüssel immer noch im Speicher, aber alle Details zum Entschlüsseln befinden sich nicht mehr auf der Festplatte und sind leicht zugänglich. Für einen Angreifer ist es viel schwieriger, den entschlüsselten Schlüssel aus dem Speicher zu stehlen, als eine "password.txt" von der Festplatte zu stehlen.
Was Sie tun, hängt stark von den Details Ihrer Sicherheitsanforderungen und den Daten ab, mit denen Sie arbeiten. An Ihrer Stelle würde ich die Passwörter nach Möglichkeit einfach nicht speichern, und wenn es sein müsste, würde ich ein PKCS#11-kompatibles Hardwaregerät verwenden wollen.
