Wie wäre es denn, wenn das EF-Passwort im Script und nicht in der DB gespeichert wird?
Wie wäre es denn, wenn das EF-Passwort im Script und nicht in der DB gespeichert wird?
Gegendenkanstoss:
Wie bei den Usern wird das EF Passwort nur verschlüsselt gespeichert.
Dann kommt eine neue Funktion welche das Passwort dann wenn Klamm es benötigt halt entschlüsselt und dann an Klamm sendet.
Wenn dies bei den Usern klappt warum nicht auch bei dem EF ?
Und Adminforce Login halt wie bei den Usern, wenn der Admin dann doch sein passwort vergisst, kann man es in der DB ja immernoch mit einem bekannten Hash ersetzten.
Wenn sich nun jemand ins Adminforce einhackt, wie auch immer, der EF aber auch geschützt ist per Hash, guckt der Hacker blöde da er nicht ans EF Passwort kommt, und dieses zu ändern würde ihm nichts bringen.
MfG
Wenn ich dich richtig verstanden habe, meinst du dass man das EF Pw als hash speichern sollte wie bei den usern ?Zitat von Masterphil
Nein, dass geht nicht, da wenn sich der user einloggt und "12345" eingibt wird es in ein hash gewandelt und mit dem hash in der DB verglichen, die user hashes werden NICHT!!! entschlüsselt, das geht nicht.
Nutzt man ein zurückverfolgbaren hash/ zuentschlüsselbaren hash:
.....ist es in einem zurückverfolgbaren hash gespeichert d.h. man kann ihn wieder ins klare umwandeln, bringt es eigentlich auch nichts da, wenn sich ein hacker die mühe macht eine seite zu hacken stören die 5 min für das pw knacken auch nicht.
Das Problem ist ja meist, dass die Hacker sich Zugang verschaffen z.B über die Scripte und vms bietet da enorm viele Möglichkeiten. Was ich in den letzten Monaten noch an Möglichkeiten gefunden habe im Script selbst und vor allen Dingen auch in den unterschiedlichsten Addons, ist schon der Hammer. Die Lösung die EF daten nicht in der db zu speichern wäre an sich schon nen guter Ansatz denke ich mal. Ob es aber wirklich Sinn macht es in eine txt zu setzen bezweifle ich irgendwo, da da der Zugriff ja für nen Hacker an sich noch einfacher wird.
Besser wäre denke ich mal die Lücken weiter zu schliessen und vor Einbau eines neuen Addons wirklich zu schauen dass gerade wo User was übertragen wirklich auf Sicherheit geschaut wird. Es gibt da sooooo einfach einzubauende Sachen wie über Addslashes oder htmlspecialchar und ähnliches.
Klar, jeder Tresor ist nur so sicher bis er geknackt wird, aber wir können doch alle schauen dass wir es den Leuten so schwer wie möglich machen an unsere Daten zu gelangen
Im Grund-Skript selbst? Bitte hier mitteilen oder einem Admin/Mod als PN schicken, danke.(EDIT: achso, VMS 1.1, na dann ;-)
Das Problem ist tatsächlich, dass man das EF Passwort nicht zu 100% absichern kann, es wird für die Schnittstellentranssaktionen in einer verwendbaren Form benötigt, die auch der Angreifer verwenden kann.
KLamm könnte da aufwändigere Dinge anbieten, die will aber dann eh kein Webbi benutzen
Da von vielen Webbis EMailadressen bekannt sind (hoffentlich mind. die im Impressum!) kann man diesen auch einfach massig Trojaner schicken, iwann werden sie schon schwach
Aber, man kann das Ganze natürlich schon weiter absichern:
- Passwort wird im Adminforce nicht angezeigt (auch nicht als type="password", was nur Punkte im Browser anzeigt, aber das Passwort trotzdem im Klartext vorhanden ist
)
- Passwort verschlüsseln
Ob man es nun in der Datenbank speichert oder in einer Datei, ist relativ egal, man weis ja vorher nicht, ob der Angreifer nun Zugriff auf die DB oder FTP bekommt
Zum Verschlüsseln gibt es diverse Methoden, allerdings muss dazu immer ein Schlüssel gespeichert werden, außer der Webbi soll diesen bei jeder Transaktion von Hand eingeben. Damit dieser Schlüssel nicht dem selben Problem wie das EF Passwort unterliegt, muss dieser nicht in der SQL Datenbank und auch nicht über den FTP erreichbar gespeichert werden.
Also nur eine Lösung für Webbis mit root-Zugriff auf ihren Server, und selbst dann ist es noch denkbar, dass der Angreifer einfach die Schnittstellen Datei via gehacktem FTP manipuliert, und dadurch an das Passwort kommt.
Ergo den Großteil der Lose in EF-Tresor, Auszahlungssumme auf der Seite begrenzen und tägl. die EF Transaktionen kontrollieren....
Kill one man, and you are a murderer.
Kill millions of men, and you are a conqueror.
Kill them all, and you are a god. - Jean Rostand, Thoughts of a Biologist (1939)
Jo jpwfour, vms1.1 aber bitte glaube mal nicht das die erhöhten Versionen besser sind, es beginnt mit der Userprofil und endet im Grunde genommen im Admin ................ Wenn ich Dir jeden gefundenen bug oder Fehler senden sollte, sorry, da bin ich länger als nur nen paar Tage beschäftigt mit. Warum? weil ich mittlerweile so ziemlich alles komplett durch gehe und die einzelnen Variablen weitgehend absichere. Die verschiedenen Zusatzmöglichkeiten kennst Du ja.
Was ich festgestellt habe ganz grob ist an sich dass die 1.2 und höheren Versionen zwar das Design auf css umgestellt haben aber an sich am ursprünglichen Grundscript nur wenig verändert und auch wenig gesichert wurde. Einzelne Hauptfunktionen in der functions.lib.php o.k. jo, das gemacht worden, aber ansonsten und das das ausreichend ist kann ich nicht bestätigen.
Nehmen wir die Schnittstelle ............ ist klamm platt wird ......... Du weisst was ich meine denke ich mal und da hast an sich schon den ersten simpel ausnutzbaren "Bug"
Einfach zu beseiten durch @ noch besser zu beseitigen durch display error Off ........
Schau einfach mal durch und ich denke Du findest dann noch viel viel mehr extrem simpel ausnutzbare Geschichten
Ok, sowas wird bei "solchen" Skripten dann iwie vorausgesetzt. Also dass serverseitig PHP schon ausreichend sicher vorkonfiguriert ist. Da aber viele VMS noch auf PHP4betrieben werden, Fehlermeldungen an den Aufrufer ausgegeben etc., kann manden Leuten halt auch schlecht helfen.
.htaccess Passwortschutz fürs Adminforce wird an vielen Stellen empfohlen, machen aber auch nur wenige. Sicherheit kommt zum Großteil durch den Webbi selber.
Wenn ich dran denke, wie viele PNs ich der Art bekomme:
"Du, kannst du mir nicht Addon XY einbauen? Addon & FTP Daten im Anhang"...
Das jeder "Progger" mit den FTP Daten automatisch Komplettzugriff erlangt, ist Vielen wohl nicht bewusst oder es stört sie nicht (solang bis dann doch was passiert).
Ein paar Webbis konnte ich immerhin von der Nutzung einer Versionsverwaltung (bspw. SVN) überzeugen, das schützt nicht nur vor Angreifern, sondern hauptsächlich vor unsachgemäßem Verhalten des Webbis und der sg. "Progger"
Kill one man, and you are a murderer.
Kill millions of men, and you are a conqueror.
Kill them all, and you are a god. - Jean Rostand, Thoughts of a Biologist (1939)
Ok,das leuchtet natürlich ein, habe ichs mir wohl doch etwas einfach vorgestellt.
In eine Datei würde ich die EF Daten auch nicht tun wollen, reicht ja das in einer Datei schon alle Daten für die Datenbank stehen.
Gibt also mehr als eine Stelle wo man ansetzten könnte, wenn der Hacker die functions hat, hat er die DB und damit auch den EF.
MfG
Mehrere Stellen ist gut *lol*
Ich habe ein vms1.1 und bin immer noch damit zugange einzelne Dateien zu sichern, wobei das Grundscript gar nicht mal mehr das Problem ist sondern vielmehr die ganzen Addons, auch die welche in letzter Zeit geschrieben wurden oder Erweiterungen und haste nicht gesehn. Zu wenig coder achten wirklich drauf was sie da tun
Berechtigungen
Zitieren
