SQL Passwort Umwandeln.

[Cool Master]

Ich hätte mal eine Frage ob sowas möglich ist:

Ich habe ein Datenbank mit User und Passwort aus Moodle. Moodle speichert das PW wie folgt:

$2y$10$UB6vKrpw227eqVXj2PiPou9c0eRtxsdU02fo9.wc3VtsA2FI.gS6a

$2y$ = the id of the hashing algorithm used (crypt_blowfish), enclosed in dollar signs.
10$ = the cost of using that algorithm (two digits) followed by a dollar sign.
UB6vKrpw227eqVXj2PiPou = randomly generated secure salt (22 characters).
9c0eRtxsdU02fo9.wc3VtsA2FI.gS6a = the hash (31 characters).

Das ganze möchte ich nun "umwandeln" für Django das wie folgt aufgebaut ist:

pbkdf2_sha256$10000$SALT$HASH

Gibt es eine Möglichkeit aus dem Moodle PW bzw. dem User ein Django PW bzw. User zu machen? Da die Datenbanken auf den gleichen Server laufen könnte man so alle 24 Stunden ein Cron Job ausfürhen, welcher den Usern aus Moodle erlaubt sich mit ihrem User und PW in Django anzumelden.

 

[mambokurt]

Umwandeln ist nicht, _wenn_ du das umwandeln könntest bräuchtest du die Daten gar nicht erst verschlüsseln.

Du kannst aber einfach beim Einloggen der User mit Ihrem Passwort das Passwort abfangen und im Djangoformat in die Datenbank schieben, sprich wenn sich wer bei Moodle anmeldet legst du einen neuen Eintrag in der Datenbank vom Django an und verschlüsselts das Passwort entsprechend der Djangoeinstellungen.

 

[TheCadillacMan]

Wenn beide System den gleichen Hashing-Algorithmus verwenden würden, wäre es eine einfache String-Zerteilung und -Verkettung. In deinem Fall mit zwei unterschiedlichen Algorithmen geht das aber nicht. Password-Hashing betreibt man ja genau aus diesem Grund.

Alternativ zu @mambokurts Vorschlag könnte man sowohl bei Moodle als auch die Django-Anwendung gegen ein gemeinsames LDAP-Verzeichnis authentifizieren. Das wäre eleganter aber eben aufwändiger. Dafür müsstest du dir aber auch über Dinge wie die Synchronisation von Passwortänderungen keine Gedanken machen.

 

[mambokurt]

Mit LDAP könnte man schon arbeiten, nur setzt man sich dann im Endeffekt hin und fängt auch wieder die Logins von Moodle ab und biegt die halt auf LDAP um um da die Accounts anzulegen, ist vom Arbeitsaufwand also ersteinmal vergleichbar oder höher. Dafür hat man seine Ruhe falls noch einmal eine Anwendung dazu kommt.

Zu LDAP sollte man allerdings vorher gründlich recherchieren, Thema Sonderezeichen(<># usw) wäre da ein Stichwort mit dem man sich dringend auseinandersetzen sollte, nicht jede Bibliothek filtert da korrekt...

 

[Cool Master]

Danke schon mal für eure Antworten

Ich habe eben heraus gefunden, dass ich bei Django den Algorithmus ändern kann.

https://docs.djangoproject.com/en/1.5/topics/auth/passwords/

Ich bin mir nicht 100% sicher, aber ist bcrypt nicht gleich zu crypt_blowfish?

Ich kann wohl einstellen das Django nach diesen PW's überprüft:

PBKDF2, PBKDF2SHA1, BCrypt, SHA1, MD5, Crypt

Nunstellt sich die frage ob bcrypt = crypt_blowfish oder Crypt = crypt_blowfish ist.

 

[ice-breaker]

bcrypt ist ein Algorithmus. crypt_blowfish ist eine Implementierung davon, die genau den Passworthash erzeugt, wie du ihn oben gepostet hast.

Wenn man in der webentwicklung von bcrypt spricht, nimmt man crypt_blowfish. Es funktioniert also

 

[Cool Master]

Wunderbar merci

 

[Cool Master]

ok ich habe noch mal eine Frage in Moodle sieht das ganze, wie ja im 1. Post schon zu sehen so aus:

$2y$10$UB6vKrpw227eqVXj2PiPou9c0eRtxsdU02fo9.wc3VtsA2FI.gS6a

und Django sieht das ganze aber so aus:

bcrypt$$2a$12$VZgJa8rBZ5TTtAAN12oFU.abIo1zVsVWzZpuP0jZI94zlCnxm6syy

Was muss ich einstellen, dass die Passwörter "gleich" sind?

 

[asdfman]

2y und 2a sind für mich unterschiedliche IDs, also sind es auch unterschiedliche Algorithmen.

Erklärung hier: http://www.php.net/security/crypt_blowfish.php

 

[Daaron]

Dein bester Ansatz wäre: Schreib den Login von Django so um, dass es als erstes mal auf das Moodle-Format prüft.
Wenn kein Moodle gefunden -> nimm das reguläre Django-Crypto-Zeugs und prüf dagegen das eingegebene Klartext-PW

Wenn Moodle gefunden (also $2y$10$), dann...
-> prüfe eingegebenes Klartext-PW gegen den in Moodle verwendeten Crypt (also BCrypt mit Aufwand 10)
-> wenn Prüfung korrekt -> erzeuge Django-Format und überschreibe PW-Hash in der Datenbank
-> logge den User ein

 

[mambokurt]

2y und 2a sind für mich unterschiedliche IDs, also sind es auch unterschiedliche Algorithmen.

Erklärung hier: http://www.php.net/security/crypt_blowfish.php

"For practical purposes, it does not really matter if you use $2a$ or $2y$ for newly set passwords, as the countermeasure is only triggered on some obscure passwords (not even valid UTF-8) that are unlikely to be seen outside of a deliberate attack (trying to match hashes produced by buggy pre-5.3.7 code). "

Dass die beiden Passwörter unterschiedlich aussehen ist auch logo, du hast ja 2 unterschiedliche Salts und unterschiedliche Costs (10 u. 12). Sprich _theoretisch_ brauchst du nur mit einem substring die letzten 53 Zeichen vom String von Moodle kopieren und hängst 'bcrypt$$2a$10$' davor(die 10 muss glaube bei beiden gleich sein), dann müßte Django damit umgehen können.

 

[Cool Master]

@mambokurt

Ok, das teste ich mal.

Ok der Cost gefällt ihm glaube ich nicht.... Ich muss mal schauen ob ich Moodle auf 12 hochdrehen kann.

 

[Daaron]

Wie willst du das tun?
Da müsstest du alle Passwörter in Moodle neu hashen um den Cost zu erhöhen -> du bräuchtest alle Klartexte -> du hättest das Problem nicht.

 

[Cool Master]

Das passiert nach einem neuen Login automatisch. Liegt an der Version 2.5. Da haben die Entwickler eine Funktion eingebaut welche es möglich macht. Zumindest so die Theorie Zur not wird das PW einfach bei jedem User zurückgesetzt. Oder ich veringer den Cost in Django wäre auch eine alternative... Evtl. sogar die bessere da noch keine echten User drauf sind.

 

[Daaron]

Ah,a lso macht Moodle genau das, was ich oben bereits beschrieben hab (und was du in Django sicher nachpflegen könntest).

Wieso liest Django die Cost eigentlich nicht aus dem Hash aus? Dafür steht die doch da drin... Da hat wohl jemand kräftig gepfuscht, hm?

 

[Cool Master]

Im Admin Bereich wird mir der User mit dem korrekten Cost angezeigt. Ich nehme aber an, dass er genau 12 benötigt und dies wohl hardcoded ist. Ich muss mal schauen evtl. klappt auch die LTI anbindung aber das konnte ich bis jetzt nicht testen.

Wenn LTI klappen würde wäre das ein Traum da hätte ich 0 Probleme da Django alles selber machen würde. Sprich User logt sich ein und ifnot in Django-DB User anlegen

Edit:

Wie ich dachte war dies tatsächlich mit rounds = 12 hardgecoded. Ich konnte es erfolgreich auf 10 runter bringen. Nun habe ich aber ein anderes Problem.

2a und 2y. Stelle ich ein 2y PW auf 2a um geht gar nichts. Ich bekomme sofort ein Fehler, dass entweder mein PW oder User falsch ist. Lasse ich das ganze auf 2y bekomme ich auch einen Fehler - aber einen etwas sinvolleren und zwar "Invalid salt"