Forum

[Satyr]

Hallo an die Entwickler von Community Addon,
zuerst ein Lob für sehr gute Idee.
Es wurden sehr viele Aspekte der Benutzerverwaltung sinnvoll umgesetzt.
Ein Punkt, welches mich beunruhigt ist der Umgang mit Passwörter.
Ich denke, dass die "Speicherung" der Passwörter als "Klartext" sehr gefährlich ist.
optimal wäre nur md5 oder sha1 Hashes in DB zu speichern.
Da, so die Funktion "Passwort vergessen" nicht mehr wie bis jetzt arbeiten kann, habe ich mir eine andere Strategie ausgedacht.
1. Zuerst wird nach Benutzernamen gefragt und nach Erfolg eine Nachricht an den Benutzer gesendet.
2. In dieser Nachricht befindet sich ein Link zur Seite "Passwort ändern" (neusetzen), wobei das "Key" in diesem Link zeitlich beschrenkt ist (z.B. 1 Tag oder 1 Stunde).
3. Der Benutzer klickt auf den Link und landet auf der Seite "Passwort ändern", falls das "Key" nicht mehr gültig ist, erscheint entsprechende "Fehlermeldung" ansonnsten kann das neue Passwort gesetzt werden.

Ich kann probieren es umzusetzen.
Hat jemand noch ein Vorschlag?
Was denkt Ihr?

Gruß
Adam

[Markus.Lorch]

Ich sehe in plaintext Passwörtern kein direktes Sicherheitsproblem.
Dennoch geht die Entwicklung wahrscheinlich in diese Richtung und es wurde auch schon etwas daran gearbeitet.

("Passwort senden" würde es ich persönlich bevorzugen, wenn einfach ein neues, automatisch generiertes, Passwort zugestellt wird.)

[Ruediger.Nitzsche]

Ich seh da schon ein Problem, vor allem, weil viele Endanwender überall identische Passwörter verwenden, deshalb ist der genannte Ansatz die richtige Richtung.

Rüdiger

[Markus.Lorch]

Ja. Ich sehs ja im Prinzip auch so.

Aber sha1 und md5 (zwei längst geknackte Algorithmen) bringen nicht automatisch Sicherheit. Mathematisch gesehen verringern sie sogar die Passwort-Stärke. Solange die Datenbank sicher ist, sind plaintext Passwörter theoretisch sicherer als gehashed. Und wer trotzdem irgendwie an die Datenbank kommt dem trau ich auch zu, dass er mit md5 und sha1 keine Probleme hat.

Ich bin natürlich trotzdem für gehashte Passwörter. Jede Hürde ist ne Hürde und die Summe machts Und das massenhafte verarbeiten der Daten wäre damit mindestens verlangsamt. Aber es wär für mich jetzt kein Prio1 Thema. Und da ich ja nie weiß wie ein Webseiten-Betreiber mit seinen Daten umgeht wäre es mir persönlich auch lieber ein Betreiber hashed die Passwörter

Edit: ich hab vor paar Tagen schon eine hashvalue Klasse für die xform requested mit der man dann tatsächlich auch Passwörter hashen und auch sinnvoll ändern kann (neuer hash nur bei Änderung) - ich denke also, dass es auch kommen wird. Es fehlt aber noch einiges am Auth-Plugin damits dann auch wirklich funzt.

[Satyr]

Hallo,

Ich sehe in plaintext Passwörtern kein direktes Sicherheitsproblem.

Ich schon,
Das Argument von Rüdiger bestätigt noch meine Bedenken

es muss nicht gleich ein Server kompromitiert sein. Es reicht dass ein Serveradministrator, techniker oder andere Mitarbeiter der Firma ein Zugriff auf DB hat.
Liegen die Passwörter der Kunden im Klartext vor, steht dem Mißbrauch nichts im Wege.
Außerdem möchte ich sicher sein dass meine "Geheime Eselsbrücken" geheim bleiben und niemanden außer mir bekannt sind (ein intelligenter Mensch kann aus meinen Passwörter viel über meine "Techniken" zur generierung der Passwörter erfahren).

("Passwort senden" würde es ich persönlich bevorzugen, wenn einfach ein neues, automatisch generiertes, Passwort zugestellt wird.)

Genau! Diese Lösung ist sinnvoll und einfach.


Zu SHA1
Quelle:
http://www.heise.de/security/artikel/Ke ... 71334.html

Die SHA-1-Attacken haben auch keine Bedeutung für die Sicherheit von Passwörtern, die in vielen Systemen nur als Hash-Werte abgespeichert werden. Die Berechnung
eines Passworts zu einem vorgegebenem Hash-Wert bleibt vorerst aussichtslos, dort bleiben Wörterbuchattacken die größte Bedrohung.

Quelle 2:
http://de.wikipedia.org/wiki/Secure_Hash_Algorithm
Vom 8. August 2007 bis zu einer seit 12. Mai 2009 andauernden Pausierung versuchte eine Forschungsgruppe der
Technischen Universität Graz
– soweit erfolglos (Stand Juni 2011) –, mittels eines
Distributed-Computing
-Projektes Kollisionen im SHA-1-Algorithmus zu finden (
SHA-1 Collision Search Graz).

Dennoch geht die Entwicklung wahrscheinlich in diese Richtung und es wurde auch schon etwas daran gearbeitet.

Die Klasse class.xform.hashvalue.inc.php habe ich mir auf Github angeguckt.
https://github.com/markuslorch/redaxo4_ ... a7df55ba45
und werde demnächst testen.

Gruß
Adam

[Markus.Lorch]

Hi Adam,

der Heise Artikel ist fast 7 Jahre alt ... Aber ich sehe eigentlich den Sinn der Diskussion überhaupt nicht weil ich schon gesagt hab, dass ichs auch haben wöllte^^ Wir sind doch im Grunde der selben Meinung. Und wenn manns übertreiben will kann man ja auch sha512 verwenden (das geht auch mit der hashvalue klasse) was ja derzeit als sicher gillt

Für mich wär die größere Frage wie weit man mit der Sicherheit beim Community-AddOn überhaupt gehen will.

[Ruediger.Nitzsche]

Egal ob Community oder auch normal CMS, das Thema ist extrem wichtig. Hash + Salt sollte einfach Standard werden, schau Dir alleine mal an, wieviele erfolgreiche Hacks per FTP momentan laufen (unabhängig vom CMS) -> in den Configs liegen Zugangsdaten zur DB im Klartext (müssen sie ja auch) -> Rest kann man sich selbst ausmalen und davor sind auch die Großen nicht sicher, hat man ja jetzt erst wieder bei Hetzner und 1blu gesehen.

Rüdiger

[Markus.Lorch]

Ja ok Du hast recht. Das hatte ich außer Acht gelassen.

Aber wie gesagt hab ich ja auch schon etwas Arbeit für diese Sache investiert, und ich vermute einfach mal Jan wird es dann auch im Auth Plugin berücksichtigen

[Markus.Lorch]

Mit der aktuellen Version auf Github sind verschlüsselte Passwörter nun möglich. Allerdings bedeutet das noch etwas Handarbeit beim Anpassen der xForm Formulare für "Passwort Ändern","Registrieren" und "Passwort vergessen" - und auch beim Table Manager.

In der aktuellen xForm Version auf Github ist die hashvalue Klasse enthalten. Diese kann sowohl im TableManager als auch bei den Formularen zum hashen der Passwörter verwendet werden.

Im Beispiel des Passwort ändern Formulars könnte das wie folgt aussehen und lässt sich auf die andern Formulare vom Prinzip übertragen:

Code: Alles auswählen

password|password_1|Neues Passwort:||no_db
password|password_2|Passwort wiederholen:||no_db
hashvalue|password||password_1|sha1

Bereits vorhandene Plaintext Passwörter müssen selbstverständlich vor der Umstellung in sha1 umgerechnet werden.

[Satyr]

Hallo Markus,

Mit der aktuellen Version auf Github sind verschlüsselte Passwörter nun möglich. Allerdings bedeutet das noch etwas Handarbeit beim Anpassen der xForm Formulare für "Passwort Ändern","Registrieren" und "Passwort vergessen" - und auch beim Table Manager.

Die Klasse hashvalues verschlüsselt die Passwörter, was ist dann mit Login?
In der Redaxo-Community sieht das Login-Formular wie folgt aus:

com_auth_form_info|label|Bitte einloggen|Benutzer wurde ausgeloggt|Login ist fehlgeschlagen|Benutze wurde erfolgreich eingeloggt|
com_auth_form_login|label|Benutzername / E-Mail:
com_auth_form_password|label|Passwort:
com_auth_form_stayactive|auth|eingeloggt bleiben:|0

Ich sehe hier keine Möglichkeit die Klasse hashvalue einzusetzen.
Die Value Felder:
com_auth_form_*
sind im Plugin auth definiert.
Ich habe mir auth und alle Klassen angesehen aber blicke nicht durch wie genau wird die Datenbankabfrage realisiert und wo läßt sich das angegebene Passwort noch verschlüsseln damit es mit Login klappt.

Gruß
Adam

[Markus.Lorch]

im Backend unter Authentifzierung den Haken rein machen Mit dem Loginformular hat das nichts zu tun.

[Satyr]

Hallo Markus,

im Backend unter Authentifzierung den Haken rein machen ;) Mit dem Loginformular hat das nichts zu tun.

Die Authentifizierung war schon aktiviert.
Ich habe 2 Benutzer angelegt:
1. klartext@bsp.com mit Passwort 'testtest' (Klartext)
2. hashed@bsp.com mit passwort 'testtest' (sha1 hash 51abb9636078defbf888d8457a7c76f85c8f114c)
Versuche ich mich als klartext@bsp.com einzulogen gibt es kein Problem.
Verständlicherweise kann dann Login als hashed@bsp.com nicht funktionieren.

Jetzt die Frage:
An welche Stelle kann ich im Plugin auth die Datenbankabfrage manipulieren?
Gruß
Adam

[Markus.Lorch]

Hast Du alle Files des auth-plugins ersetzt? Wichtig ist auch die neue config.inc.php

Die Verschlüsselung passiert in Zeile 44-45 der inc/auth.php. Das ist eine minimale Änderung und würde mich schon sehr wundern, wenn das bei Dir nicht gehen sollte^^

[Satyr]

Hallo Markus,

Hast Du alle Files des auth-plugins ersetzt? Wichtig ist auch die neue config.inc.php

jetzt habe ich mein "Fehler" entdeckt.
Ich habe das Repository:
http://github.com/dergel/redaxo_community benutzt.
Jetzt habe ich das:
http://github.com/dergel/redaxo4_community genommen und wie du geschrieben hast klappt es.
Ist auch gut gemacht mit dem Checkbox Verschlüsselte Passwörter damit jeder kann entscheiden was er benutzen will.
Danke
..Und Gruß
Adam

[Cheffchen]

Hallo,

ich lese schon die ganze zeit fleissig mit, da ich auch ein relativ aktuelles Community Addon nutze, wohl leider kurz vor dieser umstellung mit den PW.

Also meine Frage wie mach ich das genau bei einem bestehenden system.
1. nur das auth plugins Dateien vom Community Addon Version 2.8.1 überschreiben und Formular ändern?
2. xForm das gleiche, muss ich das nur überschreiben oder ist Version 2.8 OK?

Cheffchen