Admin Passwort ungeschützt

[Masterphil]

Nabend an euch alle, zur Zeit werden wieder massiv Leute und Seiten gehackt, auch ich war betroffen, jemand war mal eben auf meinem EF drauf obwohl dieser ein absolut sicheres Passwort hatte. (Schaden für mich war diesmal 0 zum Glück und andere Geschädigte haben ihr Lose zurückbekommen die der Hacker über meinen EF transferieren wollte)

Habe lange überlegt, der Hacker musste mein EF Passwort wissen.

Keylogger ausgeschlossen da ich davor 1-2 Monate nicht im EF war.

Nun schaue ich mal interessehalber in meine DB, Userdaten alle userfreundlich als Hashs gespeichert, , denke ich mir mal nach dem Admin Passwort schauen, im Klartext gespeichert, schaue zur EF anbindung auch Klartext.

Ich denke mal dies ist nicht Sinn der Sache das diese sensiblen Daten im Klartext dastehn.

Wir sollten hier also an einer Lösung arbeiten.

MfG

[Xenon]

So als denkanstoß:
EF Password muss im klartext sein sonst könnte sich das script ja nicht mit deinem pw im ef einloggen und die lose der user transferieren.

Ist das Passwort im md5 hash (o.ä.) ist es für das script unbrauchbar, 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.
---------------
Die frage bei dir ist nun, wie kommt er den an die PW's, ist er direkt in die DB reingekommen (wenn ja, wei kommt er an das pw, keylogger?) oder hat eine lücke ausgenutzt wodurch er dies auslesen konnte ?

[Parl]

Ich glaube er meint die Eingabefelder im Adminforce, dort stehen diese in normalen input text Feldern drin. Ich habs bei mir auf input type="password" geändert, funktioniert ja genauso. :-)

Mit den in der db gespeicherten PW's hat Xenon recht, die müssen im Klartext an klamm.de gesendet werden, da müsste notfalls Klamm ne Änderung vornehmen.

[dersepp33]

Wie wäre es denn, wenn das EF-Passwort im Script und nicht in der DB gespeichert wird?

[Masterphil]

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

[Xenon]

G
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 ?

Wenn ich dich richtig verstanden habe, meinst du dass man das EF Pw als hash speichern sollte wie bei den usern ?
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.

[Jenny]

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

[Masterphil]

Wenn ich dich richtig verstanden habe, meinst du dass man das EF Pw als hash speichern sollte wie bei den usern ?
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:

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

[Jenny]

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

[jpwfour]

... Was ich in den letzten Monaten noch an Möglichkeiten gefunden habe im Script selbst ...

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....