2016-06-07 22 views
1

Wir haben eine Legacy-Anwendung, die die Kennwörter des Benutzers unverschlüsselt in der Datenbank speichert. Wir hatten schon einige Kunden, die jetzt an Bord sind. Die Verschlüsselung dieses Passworts ist eine große Sache für sie (fairerweise genug). Derzeit ist es nur ein Nvarchar (100) -Feld innerhalb einer SQL Server-Datenbanktabelle.Einfache Methode zum Verschlüsseln des Kennwortfelds in der Legacy-SQL Server-Datenbank

Die Situation ist, dass mehrere Client-Anwendungen auf diese Datenbank zugreifen und gegen dieses Kennwort validieren.

Möchten Sie nur Rat bekommen, wie wir Verschlüsselung in diesem Bereich in der Datenbank erreichen können, ohne alle Clientanwendungen neu schreiben zu müssen, die davon lesen? Es ist nicht ausgeschlossen, die Client-Anwendungen zu ändern, aber wir versuchen, mit so wenig Aufwand wie möglich davonzukommen.

Irgendwelche Ideen?

+0

OMG, Sie speichern Passwörter in-the-clear und sehen kein Problem außer Benutzerbeschwerden! Entschuldigung, aber ich bin erstaunt, dass jemand immer noch Passwörter speichert, verschlüsselt oder im Klartext. Haben Sie eine Vorstellung von der finanziellen Haftung, die Sie haben? Viel weniger ein R & D Manager bei einem Softwareunternehmen, das Enterprise-Software für Unternehmen auf der ganzen Welt entwickelt. – zaph

+0

Warnung: Ich bin kein Sicherheitsexperte, aber ich würde keine DB-Passwörter (verschlüsselt oder nicht) speichern. Stattdessen würde ich den Hash-Code speichern. Innerhalb von SQL Server kann die Funktion [HASHBYTES] (https://msdn.microsoft.com/ro-ro/library/ms174415.aspx) zum Generieren solcher Codes verwendet werden. Denken Sie an diese Hashes als Einwegverschlüsselung. Wenn ich ein Passwort überprüfen müsste, würde ich zuerst den Hash-Code generieren und dann würde ich diesen Code mit dem Wert aus der DB vergleichen. –

+0

Zu einem Punkt korrigieren. Nicht sicher was genau [SQL Server HASHBYTES] (https://msdn.microsoft.com/en-us/library/ms174415.aspx) tut, scheint es, Standardhashes nur zu unterstützen. Wenn es nicht gesalzen und iteriert wird, ist es nicht ausreichend. Einfaches Hashing ohne Salzen lässt die Hash-Passwörter für Rainbow-Table-Angriffe offen. – zaph

Antwort

0

Tun Sie das nicht, speichert gesalzene, iterierte HMACs der Passwörter. Verwenden Sie etwas wie Bcrypt, password_hash, PBKDF2 oder ähnliches.

Wenn der HMAC nicht gesalzen und iteriert wird, reicht dies nicht aus. Einfaches Hashing ohne Salzen lässt die Hash-Passwörter für Rainbow-Table-Angriffe offen.

Konvertieren Sie die vorhandenen Passwörter jetzt.

-1
  1. Fügen Sie Ihrer Datenbank eine Konfigurationstabelle hinzu, um anzugeben, ob das Kennwort verschlüsselt werden muss oder nicht. Die Standardeinstellung ist „nicht verschlüsseln“

  2. hinzufügen „insert/update-Trigger“ auf der Kennwort-Tabelle und basierend auf Konfiguration # 1, die Daten verschlüsseln, wenn das Einfügen/Aktualisieren von

  3. Ihre Anwendung ändern sich entsprechend.

In diesem Fall haben Sie immer noch den Verschlüsselungsalgorithmus in dem Trigger, und Sie müssen die Trigger zu sichern, um die Erlaubnis verwenden.

Diese Art von Fragen brauchen Brainstorming, hoffe ich habe nichts verpasst.

+2

Passwort nicht verschlüsseln! – zaph

+0

Ich verstehe nicht, was du meinst.Wenn Sie über den Standardwert sprechen, den ich in # 1 erwähnt habe, meinte ich, dass sie nicht für bestehende Kunden verschlüsseln, die eine Kunden-App haben und mit dem Passwort arbeiten. Offensichtlich kann das dann aufgrund ihrer Anforderungen entscheiden. – FLICKER

+0

Bitte kontrollieren Sie Ihre Einstellung. – FLICKER