vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Brandneu! sevEingabe v3.0 - Das Eingabecontrol der Superlative!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Visual-Basic Einsteiger
Haschwert (MD5) - eine kleine Verständnisfrage.. 
Autor: Sophus
Datum: 23.09.13 01:04

Hallo Leute,

vorweg: Bevor einige jetzt komplizierte Gedankengänge entwickeln und sich jetzt fragen "Ouh Gott, will der mir jetzt mit solch einer komplexen und komplizierten Aufgabe in einem Anfänger-Forum kommen?" möchte ich erwähnen, dass es hier erst einmal um die Metaebene geht, sprich, es geht mir mehr um eine Verständnisfrage.

Mich beschäftigt das Thema MD5 (Hashwert) schon eine Weile. Damit wir mein Anliegen, bzw. meine Gedanken sehr gut nachvollziehen können, möchte ich ein Szenario konstruieren.

Wir stellen uns vor, in VB6 wurde ein Programm entwickelt, welches sich mit dem MySQL verbindet, Datensätze hinzufügt, bearbeitet, löscht und auch Datensätze suchen kann. Nun, mit dem Programm können sich Benutzer in der Datenbank registrieren, es werden also Benutzerkonten angelegt.

Beispiel:
Benutzer: Test
Passwort: test123 (Hashwert: ADhsdDf54545DdfdfSDf34) - den Wert habe ich mir mal ausgedacht.

Wenn sich jetzt ein Benutzer sich mit dem Passwort registiert, ermitteln das VB6 Programm per md5 den Hashwert des Passwort und speichert dann nur den Hashwert in die Datenbank. Wenn sich der Benutzer über das VB6 Programm im Anschluss einloggen möchte, gibt er sein Passwort ein, daraus ermittelt das VB6 Programm wieder den Hashwert, und wenn der Hashwert vom Login der gleiche ist wie der gespeicherte Wert, dann hat der Benutzer das richtige Passwort eingegeben, sonst nicht.

Was mich hierbei aber etwas verwirrt, ist, dass, wenn man den Hashwert des Passwortes (ADhsdDf54545DdfdfSDf34) kennt, dann ist das Benutzerkonto ja auch nicht mehr sicher, richtig? Man weiß vielleicht das Passwort nicht, weil man den Hashwert nicht "entschlüsseln" kann, aber man hätte jedoch einen Zugriff. Wie ich das meine?

Wieder ein Szenario:
Jemand kommt auf die Idee, und sagt sich "Cool, ich habe jetzt den Hashwert" und bastelt entweder per PHP oder VB6 ein kleines Programm, mit einem LogIn-Formular, worüber er dann eine Verbindung zur Datenbank aufbauen will, und mit dem Konto sich einloggen will. Er baut aber keinen MD5 ein, sondern nimmt den Hashwert als Passwort. Dies würde dann so aussehen:

Beispiel:
Benutzername Test
Passwort: ADhsdDf54545DdfdfSDf34

Und somit hätte er dann Zugang zum Konto, denn für die MySQL Datenbank ist unter dem Benutzer Test der Wert (hier der Hashwert) im Passwort-Feld das eigentliche Passwort. Die Datenbank verhält sich in diesem Punkt neutral, sie weiß ja nicht, was es sich mit dem Wert auch sich hat.

Fazit meinerseits wäre dann, man könnte das Passwort ja auch gleich im Klartext abspeichern. Denn so oder so, hätte man dann auch Zugang. Das wäre mein Gedanke.

Liege ich rein gedanklich total falsch oder habe ich damit Recht?
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
Haschwert (MD5) - eine kleine Verständnisfrage..1.632Sophus23.09.13 01:04
Re: Haschwert (MD5) - eine kleine Verständnisfrage..1.213Preisser23.09.13 01:44
Re: Haschwert (MD5) - eine kleine Verständnisfrage..1.190Sophus23.09.13 01:58
Re: Haschwert (MD5) - eine kleine Verständnisfrage..1.247Preisser23.09.13 14:21

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel