Hallo allerseits, ich hab hier eine datenbank-basierte (Windows-)Applikation, die ihre eigene benutzer-Authentifizierung durchführt. Der Benutzerstamm selbst ist eine Datenbank-Tabelle, in der ich u.a. Login-Namen und verschlüsseltes Kennwort finde. Gleich hier: Nein, ich habe nicht vor, die Verschlüsselung zu "knacken", um Kennwörter rauszufinden! Ich möchte aber die Verschlüsselung nachbauen, aus zwei Gründen: Zum einen möchte ich Benutzer "von außen" (per SQL) anlegen, und auch deren Kennwort setzen, zum anderen für diverse Web-Abfragen die Authentifizierung "nachbilden": dazu müsste ich aus den Web-Anmelde-Informationen das verschlüsselte Kennwort selbst bauen können, und dann mit dem in der Datenbank gespeicherten vergleichen. In das verschlüsselte Kennwort geht auf jeden Fall neben dem Klartext-Kennwort auch der Benutzername selbst mit ein: Wenn ich zwei Benutzern mit der Applikation selbst ein identisches Kennwort gebe, ist das verschlüsselte Kennwort unterschiedlich. Wenn ich z.B. einen Benutzer "A" mit Kennwort "A" anlege, ist das resultierende verschlüsselte Kennwort ":363A9BBAFA37C2241DEF2F869001A726" die verschlüsselten Kennwörter sehen immer gleich aus: ein Doppelpunkt und danach 32 Zeichen, offensichtlich hexadezimal. Der Hersteller rückt die Info nicht raus, ist aber recht Windows-lastig, ich vermute er verwendet irgendeine einfache Standard-Funktion. Da ich selbst mit Windows und C# und der ganzen Umgebung nicht viel am Hut habe, hab ich keine Ahnung wo ich anfangen soll zu suchen.... Kann mir da jemand einen entscheidenden Tipp geben? Solche Benutzer-kennwort-Pärchen kann ich bei Bedarf gerne mehrere liefern, leider nicht unendlich viele, da ich das immer händisch in der Applikation machen müsste... Da das für mich beruflich wichtig ist, springt da (wenn nötig) auch entsprechende Bezahlung raus....
Michael Reinelt schrieb: > Solche Benutzer-kennwort-Pärchen kann ich bei Bedarf gerne mehrere > liefern, leider nicht unendlich viele, da ich das immer händisch in der > Applikation machen müsste... Und genau deshalb sind Verschlüsselungsverfahren sicher. Man kann nämlich NICHT aus dem Wert vor der Verschlüsselung und aus dem verschlüsselten Wert auf den Schlüssel schliessen. Das ist das Wesen einer guten Verschlüsselung.
Udo Schmitt schrieb: > Und genau deshalb sind Verschlüsselungsverfahren sicher. Man kann > nämlich NICHT aus dem Wert vor der Verschlüsselung und aus dem > verschlüsselten Wert auf den Schlüssel schliessen. > Das ist das Wesen einer guten Verschlüsselung. Ich bezweifel trotzdem ganz stark das da was "verschlüsselt" wird sondern nur simpel gehasht. Michael Reinelt schrieb: > Wenn ich z.B. einen Benutzer "A" mit Kennwort "A" anlege Bleibt es den gleich wenn du den User löscht und wieder mit gleichem Passwort anlegst?
Michael Reinelt schrieb: > ich hab hier eine datenbank-basierte (Windows-)Applikation Warum wird eigentlich geheimgehalten um welche Anwendung es genau geht?
foobar schrieb: > Warum wird eigentlich geheimgehalten um welche Anwendung es genau geht? Security by obscurity. ;-)
Läubi .. schrieb: > Ich bezweifel trotzdem ganz stark das da was "verschlüsselt" wird > sondern nur simpel gehasht. Davon gehe ich auch aus... Läubi .. schrieb: > Bleibt es den gleich wenn du den User löscht und wieder mit gleichem > Passwort anlegst? Guter Hinweis! Überraschenderweise: nein :-( jeweils Name "A" Kennwort "A": :363A9BBAFA37C2241DEF2F869001A726 :B1D5E078EBB83E7A7187B4BCA72AB0CA ABER: Jeder Benutzer bekommt eine eindeutige Id (ein integer), wenn ich einen User lösche und neu anlege, kriegt der eine andere Id. Offensichtlich geht diese Id mit in den hash ein. Wenn ich das Nummernverfahren überschreibe, und den User wirklich mit derselben Nummer anlege, krieg ich denselben Hash. foobar schrieb: > Warum wird eigentlich geheimgehalten um welche Anwendung es genau geht? Es ist nicht geheim, tut aber auch (meiner Meinung nach) nichts zur Sache. ich möchts nur nicht unbedingt ganz öffentlich hier hinschreiben. Wenns jemanden interessiert, gerne per PM.
Hi, ich habe ein Problem. Hier sind 8% der Information die ich darüber habe. Jetzt löst es doch bitte...
Hallo, zeig mal eine Kombination User-ID + User-Name + Passwort + "verschlüsseltes Passwort". Ich vermute, dass Passwort ist nicht verschlüsselt sondern ein MD5-Hash über Passwort, User-ID und ggf. Username.
Daniel H. schrieb: > Hallo, > > zeig mal eine Kombination User-ID + User-Name + Passwort + > "verschlüsseltes Passwort". Gerne: "1735" "A" ":B1D5E078EBB83E7A7187B4BCA72AB0CA" > Ich vermute, dass Passwort ist nicht verschlüsselt sondern ein MD5-Hash > über Passwort, User-ID und ggf. Username. Vermute ich auch: nachdem der hash (abgesehen vom führenden Doppelpunkt) immer 32 Hex-Zeichen lang ist, gehe ich von einem 128-Bit-Hash aus. Das lässt mich auf simples MD5 schließen, vielleicht noch "gesalzen". Alles "bessere" (SHA & Co) sind idR 256 Bit lang. Ist diese Annahme stichhaltig?
Michael Reinelt schrieb: > Vermute ich auch: nachdem der hash (abgesehen vom führenden Doppelpunkt) > immer 32 Hex-Zeichen lang ist, gehe ich von einem 128-Bit-Hash aus. Das > lässt mich auf simples MD5 schließen, vielleicht noch "gesalzen". Alles > "bessere" (SHA & Co) sind idR 256 Bit lang. Ist diese Annahme > stichhaltig? Soweit ja. Es kann natürlich auch sein, dass ein anderer Hash, z.B. SHA-256 zum Einsatz kommt und nach der Berechnung beschnitten wird. Würde aber wenig Sinn machen. Allerdings kann es eben auch sein, dass das Passwort doch verschlüsselt wird, z.B. mit AES.
Die ganzen Webseiten machen das doch auch so. Das Pw wird gehasht und nur der hash gelagert. Damit kann ein Angreifer selbst wenn er die Daten klaut nicht das PW extrahieren. Das ist btw. auch der Grund wieso die Passwort-wiederherstellung bei den Seiten nicht dein pw rausrückt sondern dir ein neues gibt. @to ich würde einfach rumprobieren: MD5 hashes aus allen Konstellationen (bei 3 elementen hast du 6 Möglichkeiten) ausprobieren evtl. dasselbe mit sha Dauert vlt. 10 Minuten und wenn du Glück hast, dann passt eine Version. Wenn nicht ist nicht viel verloren. €dit: Oder einfach mal die Applikation disassemblieren, die Leute wären nicht die ersten die Schlüssel hardcoded einbauen ^^
:
Bearbeitet durch User
Michael Reinelt schrieb: > Wenn ich das Nummernverfahren überschreibe, und den User wirklich mit > derselben Nummer anlege, krieg ich denselben Hash. Und jetzt noch mal einen anderen Usernamen, gleiches Passwort und gleiche ID wählen, dann weißt du schon mal welche Teile in den HASH eingehen. Und wenn es wirklich eine C# Anwendung ist, die kann man in der Regel doch mit einem Debugger ganz gut beobachten. Falls der Hash auf der DB berechnet wird (was auch möglich wäre) tun es die Datenbankanalysewerkzeuge ggf. auch schon. Oder halt mal ein paar Kombinationen aus Trennzeichen mittels Skript durchprobieren lassen.
Michael Reinelt schrieb: >> zeig mal eine Kombination User-ID + User-Name + Passwort + >> "verschlüsseltes Passwort". > > Gerne: > > "1735" "A" ":B1D5E078EBB83E7A7187B4BCA72AB0CA" Das ist unvollständig, das sind nur drei Dinge, gefragt waren aber vier. User-ID + User-Name + Passwort + "verschlüsseltes Passwort".
Rufus Τ. Firefly schrieb: > Michael Reinelt schrieb: >>> zeig mal eine Kombination User-ID + User-Name + Passwort + >>> "verschlüsseltes Passwort". >> >> Gerne: >> >> "1735" "A" ":B1D5E078EBB83E7A7187B4BCA72AB0CA" > > Das ist unvollständig, das sind nur drei Dinge, gefragt waren aber vier. > > User-ID > + User-Name > + Passwort > + "verschlüsseltes Passwort". Sorry, hab ein A vergessen :-( "1735" "A" "A" ":B1D5E078EBB83E7A7187B4BCA72AB0CA"
Läubi .. schrieb: > Und jetzt noch mal einen anderen Usernamen, gleiches Passwort und > gleiche ID wählen, dann weißt du schon mal welche Teile in den HASH > eingehen. Es gehen offensichtlich alle drei Teile ein. > Und wenn es wirklich eine C# Anwendung ist, die kann man in der Regel > doch mit einem Debugger ganz gut beobachten. Es ist C# bzw. Dot.net, aber ich bin da leider eher barfuß was Debuggen betrifft. > Falls der Hash auf der DB > berechnet wird (was auch möglich wäre) tun es die > Datenbankanalysewerkzeuge ggf. auch schon. Das ist mit ziemlicher Sicherheit nicht der Fall.
zwei A ist vielleicht nicht grad die idealste kombination - angenommen jemand findet den string, der den hash generiert: wie soll man dann benutzername und passwort unterscheiden? (ok, danach sind nur mehr maximal zwei versuche, aber trotzdem)
Ich erhöhe den Einsatz: Angenommen ich würde einen höheren dreistelligen €-Betrag springen lassen, dafür dass mir das Ding jemand "aufmacht". a) ist das hier legitim? Wenn nicht, bitte mich informieren und den Beitrag löschen b) was braucht ihr dafür? Denkbar wären so 10-20 (nötigenfalls auch mehr, aber das ist mühsam für mich; je weniger desto besser) Komibnationen Id - Username - Klartext-passwort - Hash; aber auch ein z.B. TeamViewer-Zugang auf eine virtuelle Maschine mit der Software und einem MS Visual Studio; falls sich jemand am Debugger versuchen will (ich kann das leider nicht)
:
Bearbeitet durch User
Wenn das Ding gesalzen ist geht gar nix (ausser ein debuggen im Betrieb) .frag den Hersteller.
Aber muss dann das Salz nicht auch zusammen mit dem Hash gespeichert werden. Wie soll man sonst den Hash reproduzieren können?
den salt-wert muss man bei der berechnung des hashs kennen, in die datenbank muss er aber nicht eingetragen werden (wenn immer der gleiche verwendet wird). z.b. in php (der teil nach dem kommentar ist frei erfunden und erfüllt hier keinen besonderen zweck):
1 | $password = ':' . md5($user . ':' . $pass . ':' . $userID . 'pinkpanties'); |
2 | // 'pinkpanties' ist hier das salz in der suppe... |
3 | |
4 | if($userObj->checkLogin($userID, $password)) {
|
5 | echo 'foobar'; |
6 | } |
:
Bearbeitet durch User
Daniel F. schrieb: > den salt-wert muss man bei der berechnung des hashs kennen, in die > datenbank muss er aber nicht eingetragen werden (wenn immer der gleiche > verwendet wird). Verwechselst du da nicht grad Pfeffer und Salz?
Daniel F. schrieb: > wenn immer der gleiche verwendet wird Ist ein Salt sinnlos! Der "Witz" ist doch gerade das gleiche Eingabewerte NICHT zu gleichen Ausgabewerten führen. Michael Reinelt schrieb: > a) ist das hier legitim? Ob das legal ist müsste vermutlich ein Rechtsanwalt beantworten, erst mal wäre es natürlich nicht verboten wenn du ein "Finde-Die-Regel-In-Der-Buchstabenfolge" Suchspiel veranstaltest. Ob du diese Erkenntnis dann (kommerziell) verwerten darfst hängt von diversen Faktoren ab die dir allgemein sicher keiner beantworten kann. Michael Reinelt schrieb: > Angenommen ich würde einen höheren dreistelligen €-Betrag springen > lassen Schon mal versucht das der Firma anzubieten dir gegen Gebühr die "Lizenz zum Hashen" zu verleihen?
Läubi .. schrieb: > Michael Reinelt schrieb: >> Angenommen ich würde einen höheren dreistelligen €-Betrag springen >> lassen > > Schon mal versucht das der Firma anzubieten dir gegen Gebühr die "Lizenz > zum Hashen" zu verleihen? So oder so, ich denke da fehlt eine Stelle. Georg
Läubi .. schrieb: > Daniel F. schrieb: >> wenn immer der gleiche verwendet wird > > Ist ein Salt sinnlos! Der "Witz" ist doch gerade das gleiche > Eingabewerte NICHT zu gleichen Ausgabewerten führen. Das ist korrekt, was aber an Daniels Beitrag wichtig ist: Du weisst nicht wie z.B. sehr kurze Passwörter oder Usernames ggf. gepadded werden, bzw. ob und welche Füllbytes/Trennzeichen verwendet werden um den finalen String zu erzeugen aus dem dann der Hash gebildet wird.
Läubi .. schrieb: > Daniel F. schrieb: >> wenn immer der gleiche verwendet wird > > Ist ein Salt sinnlos! Der "Witz" ist doch gerade das gleiche > Eingabewerte NICHT zu gleichen Ausgabewerten führen. ganz so sinnlos würde ich nicht sagen. gleiche eingabewerte fürhren zu gleichen ausgabewerte, das schon - und bei einer gegebenen hash-länge muss es irgendwann zwangsläufig kollisionen geben. trotzdem erschwert ein konstanter aber unbekannter hash z.b. einen chosen-plaintext angriff, da nur ein teil der eingabe bekannt ist...
Läubi .. schrieb: > Daniel F. schrieb: >> wenn immer der gleiche verwendet wird > > Ist ein Salt sinnlos! Der "Witz" ist doch gerade das gleiche > Eingabewerte NICHT zu gleichen Ausgabewerten führen. http://de.m.wikipedia.org/wiki/Salt_(Kryptologie)#Pepper
dann meinetwegen pfeffer - dann hatte ich was falsch im kopf. egal ob salz, pfeffer oder chiliöl - es ändert nichts am ursprünglichen problem. (und chosen plaintext funktioniert auch mit weder noch)
Anderer Ansatz: Hat die Anwendung, die diese Benuter anlegt/verwaltet ein ABI/API oder eine Skript-Funktion über die eine Anmeldung möglich ist? Dann könntest du auf der gleichen Maschine einen Webservice einrichten, der die Authentifizierung mit der original Anwendung erledigt. Selbst wenn nichts dergleichen vorhanden ist... zu Zeiten von win32 gabs noch Möglichkeiten, die Bedienung mit Maus+Tastatur aus einem anderen Programm heraus zu "faken". Geht bestimmt auch noch mit .net.. Bin da leider schon lange nicht mehr auf dem Laufenden. Wenn der Hersteller allerdings nichts über das Authentifizierungsverfahren rausrückt, ist es schwer abzuschätzen, ob das "Nachbauen" überhaupt zum Erfolg führt.
Guten Morgen allerseits, das Problem hat sich erledigt: "Reflector" heisst das zauberwort, damit war die Stelle schnell gefunden, es war (wie vermutet) eine Kombination aus drei Werten getrennt mit Doppelpunkt, und "gesalzen". Der Salt selber war "obfuscated" damit er nicht im Klartext in der DLL aufscheint. Jetzt habe ich aber alle Infos die ich brauche, und kann den Hash auch korrekt selbst erzeugen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.