Speichern Sie Benutzer und übergeben Sie eine einzelne Tabelle oder eine separate Tabelle

Idealerweise:

• Speichern Sie keine Passwörter (auch nicht verschlüsselt). Speichern Sie Hashes , die von Passwörtern abgeleitet sind.
• Salt die Passwörter zu verhindern Regenbogenattacken .
• Put Hashes auf einem separaten Datenbankserver, hinter seiner eigenen Firewall und seiner eigenen gut definierten API ¹ . Diese API sollte nur drei Dinge tun:
  1. Ermitteln Sie für einen gegebenen Benutzernamen den entsprechenden Passwort-Hash.
  2. Geben Sie für einen bestimmten Benutzernamen den neuen Hash ein (um das Zurücksetzen des Passworts zu unterstützen).
  3. Entfernen Sie den angegebenen Benutzernamen und seinen Hash (um die Aufhebung der Benutzerregistrierung zu unterstützen).
• Machen Sie dasselbe für Salze: Legen Sie sie auf ihren eigenen Server und hinter ihre eigene Firewall und API. Diese API sollte nur drei Dinge tun:
  1. Für den angegebenen Benutzernamen, rufen Sie das entsprechende Salz ab.
  2. Geben Sie für den angegebenen Benutzernamen das neue Salz auf einen zufälligen Wert ein (um das Zurücksetzen des Kennworts zu unterstützen).
  3. Entfernen Sie den angegebenen Benutzernamen und sein Salt (um die Aufhebung der Benutzerregistrierung zu unterstützen).
• Sowohl Hash- als auch Salt-Server sollten von der Welt (und voneinander) abgeschnitten sein und nur von dem Server aus zugänglich sein, auf dem Ihre Web-Anwendung läuft (zB PHP oder ASP.NET oder was auch immer ...).

Wenn der Benutzer sich anzumelden versucht, indem er seinen Benutzernamen und sein Passwort eingibt:

• Stellen Sie sicher, dass dies über HTTPS erfolgt, damit die eingegebenen Daten den Code Ihrer Website sicher erreichen.
• Rufen Sie die API auf, die den Kennwort-Hash für den Benutzernamen abruft.
• Rufen Sie die API auf, die das Salz für den Benutzernamen abruft.
• Salt und hash das Passwort vom Benutzer eingegeben und vergleichen Sie es mit dem abgerufenen Hash.
• Wenn sie übereinstimmen, erhält der Benutzer den Zugriff.

Hashes sind von Natur aus irreversibel - anders als der Benutzer kennt niemand, nicht einmal Sie, das genaue Passwort. Wenn der Benutzer das Passwort vergisst, können Sie ihm das Passwort nicht senden, aber Sie können ihm erlauben, das Passwort zurückzusetzen, vorausgesetzt, dass es eine zusätzliche Überprüfung besteht (dh Zugriff auf eine bestimmte E-Mail-Adresse hat und / oder ein Geheimnis beantwortet) Frage).

BTW, Anmeldung ist eine relativ seltene Operation, es ist also unwahrscheinlich, dass es zu einem Leistungsengpass kommt, wenn Sie die ordnungsgemäße Indizierung nicht völlig ignorieren.

¹ z. Implementieren Sie einen Webdienst, und öffnen Sie dann nur den Port, der für diesen Webdienst erforderlich ist, und sonst nichts.

Ich werde mit Option 1 gehen.

Denken Sie, es gibt ein paar Nutzer. Um die Benutzerdaten zu erhalten, müssen Sie also mit n Tabellen statt mit 1 Tabelle arbeiten, was natürlich LOAD auf dem Server hinzufügt und Sie schließlich BAD PERFORMANCE haben werden.

Also würde ich mit Option 1 gehen.

Für tel. number, add field als Festnetznummer, handy_number, alternate_number als addierendes Feld in der Tabelle wird nicht so viel Unterschied machen als das Hinzufügen einer Tabelle für das Feld.

Und ja, nach Steve Kommentar, Passwort mit sicheren Hash-Mechanismus speichern.

Welche Option wählen Sie?

Es kommt darauf an. Wenn Sie die Passworthistorie behalten möchten und der Benutzer viele Telefonnummern haben kann, erstellen Sie zusätzliche Tabellen für Passwörter und Telefone. In anderen Fällen genügt eine Tabelle.

Erstens sollten Sie, wie @Steve sagt, Passwörter mit einem sicheren Hash-Mechanismus speichern - die Speicherung von Klartext-Passwörtern ist unverantwortlich - es bedeutet, dass jeder, der in Ihr System eindringen kann, Benutzerpasswörter kennt, die sie möglicherweise auf anderen Seiten wieder verwendet haben .

Zweitens gibt es in beiden Entwürfen keinen inhärenten Sicherheits- oder Leistungsvorteil - aus Sicherheitsgründen müssen Sie davon ausgehen, dass ein Angreifer, der Zugriff auf Ihre Datenbank erhält, Abfragen ausführen kann, und es wäre einfach zu finden Daten in beiden Systemen. Aus der Sicht der Leistung ist es unwahrscheinlich, dass die Kosten der Joins in Option 2 von Bedeutung sind, wenn Sie primäre / fremde Schlüsselindizes haben.

Wenn Sie nach einem bestimmten Zeitraum die Passwörter neu festlegen müssen und den Passwortverlauf speichern müssen, um zu verhindern, dass Benutzer Kennwörter erneut verwenden (dies ist ein Feature, das Windows beispielsweise unterstützt), müssen Sie einen " UserPassword "-Tabelle mit den Spalten valid_from und valid_until.