2016-04-21 11 views
-8

Sichere Verbindung ist in diesem Fall keine Option, aber zum Glück müssen auch keine sensiblen Informationen gesendet werden. Ich dachte, so etwas wie dies könnte Wäre dies ein einigermaßen sicheres Passwort-System?

Registrierung

arbeiten:

  1. Benutzer gibt Benutzername/Passwort
  2. Sowohl mit einem Verschlüsselungsalgorithmus gehasht Client-Seite bekommen (ich denke bcrypt)
  3. Beide gesendete zum Server < - !!

Anmeldung:

  1. Server sendet dem Client eine zufällige Salz
  2. Benutzer Benutzername/Passwort eingibt
  3. Beide Client-Seite erhalten gehasht und das Passwort wieder mit zur Verfügung gestellt Salz
  4. Server gehasht wird Sucht den Hash des Benutzernamens und hasht auch den Hashwert des Passworts mit dem zu überprüfenden Salz
  5. Anmeldung erfolgreich/fehlgeschlagen

Es sollte solide genug sein, außer für den 3. Punkt der Registrierung, wo sie leicht abgeholt werden konnten, aber selbst wenn der Angreifer die Benutzer/Passwort Hashes hat, hat er nicht den Benutzer/Passwort und es gibt keine sensiblen Informationen für den Zugriff/volatile Aktionen durchzuführen, auch die Motivation, die Verbindung anzugreifen, sollte sehr gering sein.

Also abgesehen von Punkt 3 der Registrierung, gibt es noch andere Löcher, die Sie sehen können?

+8

"Sichere Verbindung ist in diesem Fall keine Option" Punkt. Nein, in diesem Fall ist das, was Sie haben, in keiner Weise sicher. – PeeHaa

+3

Ihr Plan wird den Hash-Schlüssel und den Hash-Algorithmus im Klartext senden. Es gibt keine Möglichkeit, das wäre sicher. – scrappedcola

+0

Nutzlose Kommentare beiseite, dieses System geht immer noch hoch und eine sichere Verbindung ist immer noch keine Option, daran kann ich nichts ändern. Ich weiß, dass es nicht sicher sein wird, solange jemand die Verbindung mithört, obwohl ich immer noch das Beste brauche, was ich kann. – user81993

Antwort

7

"Keine vertraulichen Informationen müssen gesendet werden", uh, das Passwort ist "sensible Informationen", vor allem, da die meisten Benutzer ihr einziges Passwort überall wiederverwenden.

Das Hashing auf der Client-Seite ist nicht optimal, Sie können nicht darauf vertrauen, dass der Client das Hashing korrekt ausführt, und Sie können nicht darauf vertrauen, dass niemand auf den Benutzer hört, der Ihnen den Hash sendet. Wenn ein Angreifer den Hash vom Client erhält, hat er Zugriff auf das Konto und Ihr System ist leicht zu besiegen.

Auch ohne den Hash des Benutzers tatsächlich zu lesen, kann ein Angreifer das Sitzungscookie des Benutzers trivialerweise stehlen und Ihr System auf diese Weise besiegen.

Sie sind über Engineering, gibt es absolut keinen Grund, warum eine sichere Verbindung nicht möglich wäre, vor allem, da Sie perfectly good, free, ways of generating TLS certificates haben, und im Falle des internen Netzwerks, selbstsignierte Zertifikate mit einer vertrauenswürdigen CA eines Unternehmens.

TL; DR - Wenn Sicherheit eine Voraussetzung ist, dann ist eine sichere Verbindung eine Voraussetzung, und es gibt überhaupt keine Möglichkeit.

Mit einer gesicherten Verbindung wird dieses komplizierte Schema verworfen, da Sie einfach den Benutzernamen und das Passwort ohne Bedenken eingeben können.