Welcher Algorithmus?

D

DarkGangster

0
Hallo,

ich habe ein Programm welches sich mit einer SQL-Datenbank verbindet und dort dann einige Werte ändert. Ich habe die ganze Prozedur dreimal gemacht und entsprechend (mit Ethereal) dreimal mitgesnifft. Dabei kamen folgende Werte für das Passwort herraus:
1.) ZXDIOXGN
2.) J\TMRYBN
3.) NHWDG]GW

Weiss jemand was für ein Verschlüsslungsalgorithmus das ist??? Also es muss ja einer sein, der für einen konstanten Wert unterschiedliche Hashes erzeugen kann. Dann stellt sich mir gleich auch noch die Frage ob so etwas knackbar ist.

THX 4 HELP & GREETZ
 
Ja, sollte knackbar sein...


Unterschiedliche Werte bekommst du auch wenn du die Passwörter salzt :-)

Salted passwords :-)
 
hmm ich hab das mal gegoogelt und so weit ich nun weiß ist "salten" wenn man einem Passwort bevor man es hasht einen beliebigen Wert dazu addiert. Daraus resultiert dann doch aber immer der gleiche Hash. Hier sind es aber unterschiedliche Hashs.
 
Wieso sollte da der gleiche Hash entstehen, wenn man einen _zufälligen_ Wert an das Passwort hängt?
http://de.wikipedia.org/wiki/Salted_Hash

Ich würde empfehlen, sich das Programm, was diese Werte erzeugt mit IDA(ein Disassembler) anzusehen, um herauszufinden, wie diese Werte erstellt werden, dann lässt sich auch mehr über die Sicherheit davon sagen.
 
Bei gesalzten Passwörtern muss man doch das Salz mitspeichern - wenn man nicht jedesmal dasselbe nimmt, funktioniert der Vergleich nicht mehr.
Wieso sollte es dann beim Login verschiedene Hashs geben, wenn man doch immer das selbe Salz nutzen muss? Bei der Generierung eines neuen Passwortes (inklusive neuem Salz) wäre das was anderes...aber wenn sich das Passwort nicht ändert und man sich nur einloggt, müsste doch immer derselbe Hash zu übertragen sein - oder habe ich das mit den salted Passwords nicht richtig verstanden?
 
Hallo,
evt. ist das Passwort in der DB als Klartext gespeichert, und wenn du dich mit der DB verbindest, sagt der Server: Du benutzt folgendes Salz (;)).
Der Client generiert dann den Hash mit der Salt und der Server überprüft dies.

Ein weiterer Vorteil wäre, dass wenn jmd. den Hash mitscheidet, sich nur dann mit dem Hash auch einloggen kann, wenn der Server ihm zufällig den gleichen Salt zuweist.
Bei einem anderen Salt wäre der Login nicht möglich.

Hab man eine außreichend große Vielfalt an Salts, so würde einem das Mitschneiden des Hash-Wertes nichts bringen.
 
Original von Elderan
evt. ist das Passwort in der DB als Klartext gespeichert, und wenn du dich mit der DB verbindest, sagt der Server: Du benutzt folgendes Salz (;)).
Der Client generiert dann den Hash mit der Salt und der Server überprüft dies.
Zum Vergrößern anklicken....
NEIN!!! :P

Passwort-hash und salt wird gespeichert.

Bei der Anmelung wird dann dieser salt und ein zufälliger salt geschickt.
Client hashet das Passwort mit dem Salt und der Hash wird dann mit dem zufälligensalt nochmal gehasht und dann an den Server geschickt. Der Rest düfte klar sein ;)

Wurde aber im zuvor geposteten Thread schon angeschnitten....
 
Hmm ich hab mir das jetzt nochmal genau im Sniffer angeschaut und es scheint tatsächlich so zu sein wie lagalopex meint:
Der Client sendet einen Request an den Server.
Der Server sendet einen Salt, z.B. "n^hs)le"
Daraus macht der Client dann "JTIHWPRJ" und loggt sich damit ein.

Also mit so einer Technik ist sicher schonmal ausgeschlossen, dass man das Passwort im Klartext herausbekommen kann.
Ist es denn möglich nach der Anmeldung des Clients beim Server dem Server SQL Abfragen von externen Quellen (also nicht vom Client) zu schicken???
 
Hallo,
Ist es denn möglich nach der Anmeldung des Clients beim Server dem Server SQL Abfragen von externen Quellen (also nicht vom Client) zu schicken???
Zum Vergrößern anklicken....
Möglich wären 'Man in the Middle' oder IP-Spoofing.

Stellt sich die Frage, wie der Client auf den Server zugreift. Geschieht dies über einen lokalen Sockel, so wie es bei MySQL fast immer ist, wird es bestimmt recht schwer.

Geschieht der Datenaustausch per Netzwerk, könnte ein Angreifer z.B. ein Packet mit der SQL Anweisung an den Server senden.
Bei diesem Packet müsste er die Absender-IP so fälschen, das es die von dem eingewählten Client ist.
Da aber der Datenaustausch über TCP läuft, müsste er noch die Sequenz-Nummer erraten, was zwischen relativ einfach (Netzwerk mit Hub) bis relativ schwer (Router) ist.

Des Weiteren würde der Angreifer keine Antwort auf seine Anfrage bekommen, denn die sendet der Server zu dem eingelogten Client.

Man kann also nicht sagen, ob solch eine Attacke schwer oder leicht zu realisieren ist. In einem Netzwerk mit einem Hub könnte man relativ leicht manipulierte Packete sende, oder sich gar in die Mitte von Server & Client stellen.

Ist aber zwischen dem Angreifer und dem Client z.B. ein Router (z.B. Internet), dann wird der Angriff schon deutlich schwerer.
Des Weiteren bieten die meisten SQL Server noch eine Verbindung per SSL, dort wären solche Angriffe nicht möglich.
 
Geschieht der Datenaustausch per Netzwerk, könnte ein Angreifer z.B. ein Packet mit der SQL Anweisung an den Server senden.
Bei diesem Packet müsste er die Absender-IP so fälschen, das es die von dem eingewählten Client ist.
Zum Vergrößern anklicken....
Der Client läuft doch auf dem PC des Angreifers, deshalb verstehe ich nicht weshalb dieser seine IP fälschen sollte, da diese ja mit der des Clients übereinstimmt.
Somit ist doch auch eine Mitm bzw. IP Spoofing Attacke ausgeschlossen, da diese einen dritten Host vorraussetzen. Denn ein Client ist ja kein Host. Aber vor diesem Hintergrund, dass Client und Angreifer den gleichen Host benutzen, müsste es doch eigentlich trotzdem möglich sein, wie du beschrieben hast, ein Packet mit einer SQL Anweisung an den Server zu senden, oder??? Sogar ja eigentlich noch viel einfacher, da man z.B. die Sequenz Nummer im Sniffer angezeigt bekommt.
 
Hallo,
wenn der Angreifer auf dem gleichen Computer ist, dann kann er doch einfach einen Keylogger starten und das Passwort mitschneiden.
Es macht doch eigentlich eher weniger Sinn, das Angreifer und Opfer am gleichen Computer sind, denn dagegen hilft kaum eine Sicherheitsmaßnahme.
 
Nabend,
ich glaub du hast da was falsch verstanden :D

Der Angreifer startet auf seinem PC den Clienten, der sich wiederrum mit dem SQL Server verbindet. Das Passwort (bzw. dessen Hash) ist in der kompillierten .exe des Clients enthalten.
 
Hallo,
dann könnte man ja die .exe decompilieren und das PW auslesen ;)
Aber sonst kann man natürlich auch entsprechende SQL Packete senden, sobald sich das Prog. eingelogt hat.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben