The user and all related content has been deleted.
Hallo, das im Backend könnte man theoretisch ändern. Dafür kannst du gerne ein Ticket aufmachen. So hat das natürlich auch den Vorteil, dass du die Daten direkt prüfen kannst. Im Backend kannst du generell die Zugriffsbedingungen ändern, z.B. dass nur du dort reinsehen darfst. Bei der config.php geht das so nicht. Dann kann man nicht mehr auf die Datenbank zugreifen Da muss das also schon so drin stehen. Das ist aber nichts besonderes und auch bei anderer Software so Sebastian
The user and all related content has been deleted.
[quote=„AllenSmithee“]bitte alle Zugangsdaten/Passwörter im Backend und ggf. in der Datenbank NICHT im KLARTEXT speichern![/quote] Und wie genau stellst du dir das vor? Wie soll sich Shopware dann zb bei Paypal authentifizieren?! Passwörter werden und müssen im Klartext gespeichert werden, wenn diese an Dritt-Systeme weiter gereicht werden müssen. [quote=„AllenSmithee“]Denn stellen Sie sich einmal vor, ein Entwickler einer Plugins programmiert unsauber und öffnet somit fremden Dritten Zugang zum Backend[/quote] Das sollte kein Problem von Shopware sein. Wenn du dir einen Trojaner runterlädst, dann ist es auch nicht die Schuld von Windows. Wenn du sicher gehen willst, dann installiere nur Plugins aus sicherer Quelle oder die von Shopware zertifiziert wurden. [quote=„AllenSmithee“]Auch in den CONFIG.PHP-Dateien der jeweiligen Websoftware werden die Passwörter codiert dargestellt, dass diese zumindest auf den ersten Blick nicht leicht auszulesen wären.[/quote] Auch das ist Quatsch. Wenn sich jmd Zugang zu deinem FTP verschaffen kann, um an die nicht kodierte config.php zu kommen - dann hast du 1.) ganz andere Probleme und 2.) an ganz anderer Stelle. Viele Grüße
The user and all related content has been deleted.
Hallo AllenSmithee, hier sollte jetzt nicht alles durcheinander geworfen werden. Es ging ursprünglich nur darum, dass man Passwörter/Zugangsdaten in den Plugin/Einstellungen oder der config.php sieht. Und darauf bezogen kann ich der Aussage von Aquatuning nur zustimmen. Da wir heute Sonntag haben fand ich auch die schnelle Antwort gut und daher auch das Danke! Wenn du was absichern möchtest oder große Bendenken hast, so gibt es andere Wege etwas abzusichern. Oft ist es einfach anders gar nicht technisch realisierbar. Sebastian
The user and all related content has been deleted.
Du vermischst / verwechselst hier zwei vollkommen unterschiedliche Themen. Aber das ist meist das Ergebnis, wenn Hetze und Quotengeilheit von schlechtem Journalismus auf die Naivität von themenfremden und nicht selbst denkenden BILD-Lesern trifft. Die in der Presse angesprochene Sicherheits-Problematik und den veröffentlichten Email Konten hat nicht einmal im Ansatz etwas mit verschleierten Passwörtern zu tun. Nichts desto trotz könnte man Passwörter durch Sternchen ersetzen, um den Nutzer eines System zumindest ein trügerisch “sicheres” Gefühl zu geben. Aber wie immer gilt in einem Mehr-Benutzer-System: nicht jedem Zugang gewähren, Rechte entsprechend vergeben und eigene Passwörter / den eigenen Zugang sicher verwahren. An alle stillen Mitleser: solange ihr nicht Plugins aus dubiosen Quellen installiert, fremde Personen mit vollen Rechten in euer backend lasst oder euch eure Zugangsdaten klauen lasst - so lange braucht ihr euch keine Gedanken zu machen. Viele Grüße
[quote=“AllenSmithee”] Wir setzen noch weitere webbasierende Software ein und in keiner dieser Software sind die Passwörter im Klartext im Backend oder in der Datenbank zu sehen. Auch in den CONFIG.PHP-Dateien der jeweiligen Websoftware werden die Passwörter codiert dargestellt, dass diese zumindest auf den ersten Blick nicht leicht auszulesen wären. [/quote] Hi, ich wollte mich hier eigentlich nicht einmischen aber an dieser Stelle würde mich mal interessieren um welche webbasierte Software es sich hier handelt. Ich habe noch keine gesehen bei der die Zugänge in configdateien verschlüsselt hinterlegt werden. Gesendet von meinem iPhone mit Tapatalk
The user and all related content has been deleted.
The user and all related content has been deleted.
Ok, mein letzter Beitrag zu diesem Thema - aber das will ich nicht so stehen lassen. Das sollte kein persönlicher Angriff gewesen sein - ich entschuldige mich dafür, wenn du das so aufgefasst hast. Es war lediglich eine Feststellung, das bestimmte Medien mit Panikmache Geld verdienen und die gezielte Verdummung dafür sorgt, dass viele gerne einfach unüberlegt laut mitschreien. Ich bin auch ursprünglich nur darauf eingegangen, da du Eingangs den “gegebenem Anlass aus der Presse mit dem Datenklau von sehr vielen E-Mailpasswörtern” erwähnt hast. Es war mir einfach nur wichtig, dass ich für die stillen Mitleser, die sich nun unbegründet Gedanken über die Sicherheit von Shopware machen, ein paar Dinge klar stelle. Hier hast du nun zwei, grundlegend verschiedene Themen angesprochen: 1.) Zugangsdaten werden unverschlüsselt gespeichert 2.) Zugangsdaten werden unverschleiert ausgegeben Das Speichern von unverschlüsselten Passwörtern ist nicht nur unbedenklich, sondern auch zwingend notwendig. Jede Form der Verschlüsselung bei quelloffener Software (wie zb Shopware) ist überflüssig. Die von dir angesprochene base64 Kodierung ist nichts weiter als Verschönigung und zur Beruhigung der Nutzer. Sobald ein Dritter Zugang zur config.php hat, dann gibt es nichts einfacheres, als die base64 Daten wieder zu dekodieren. Und sollte es tatsächlich jemand auf deinen FTP geschafft haben, dann (wie bereits erwähnt) hast du ganz andere Probleme. Das ist kein Schritt in die richtige Richtung, sondern eine (grob gesagt) Verarsche des unwissenden Nutzers. Dieser wägt sich in trügerischer Sicherheit und hat evtl. ein besseres Gewissen - nicht mehr und nicht weniger. Fazit: totaler Quatsch. Das Verschleiern von Passwörtern im backend ist zwar nett gemeint - aber bietet auch nur bedingt Schutz. In einem Mehr-Benutzer-System kann man durch die Vergabe von Rechten gezielt den Zugang zu sensiblen Daten einschränken. Hier könnte (und müsste) Shopware zwar reagieren - aber auch wieder nur für das gute Gewissen des Nutzers. Die Presse schreit laut auf, erzeugt Panik, erzielt gute Quoten und schlecht informierte Leser laufen mit. Geschickte Software Hersteller verkaufen nun “bahnbrechende base64 Verschlüsselung” (frei erfundenes Zitat), ernten dafür Lob und Vertrauen und der Nutzer wägt sich dank gefährlichem Halbwissen in trügerischer Sicherheit. Ist vielleicht ein wenig weit hergeholt und übertrieben - aber so läuft es zu oft ab - und so möchte ich deine Behauptungen nicht stehen lassen. Du solltest die Informationen deiner “seriösen Quellen” etwas kritischer bewerten. Am Ende des Tages bist du in der Verantwortung. Wechsel deine Passwörter regelmäßig, installiere keine Plugins aus dubiosen Quellen, lasse keine Dritten in dein backend etc pp. Shopware ist das kleinste Übel in einer Reihe von angreifbaren Systemen - angefangen bei der Hardware, über das Betriebssystem, über den Webserver bis zum Faktor Mensch, der keine Firewall nutzt und alle seine Passwörter auf dem Desktop speichert. Viele Grüße
The user and all related content has been deleted.
[quote=„AllenSmithee“] sehr interessant wie sich hier Aquatuning GmbH zum Thema Sicherheit als Zertifizierter Showare Entwickler äußert (hätten wir mehr Verständnis erwartet) und dass Shopware (respektive Sebastian Klöpper) durch sein Bedanken des Posts von Aquatuning GmbH dies auch nocht bestätigt. Unserer Meinung nach wiederum eine sehr verdrehte Sichtweise zum Thema Sicherheit.[/quote] Ohne Dir zu nahe zu treten zu wollen… Deine Sichtweise ist die verdrehte. Wenn Du Dich darüber geäußert hättest das z.B. allowurlfopen aktiv sein müsste hätte ich ja Verständnis. Aber Passwörter in Klartext im Backend (mit umfangreichen Rollen für die User). Und dann hier so einen lauten machen? Hallo? Da kann man sich nett für die Antworten bedanken und ein Ticket aufmachen anstatt hier ein auf dicke Hose zu machen! Das Ganze dann noch getoppt mit einem verschlüsselten Datenbankpasswort in der config.php. Damit schießt Du wirklich den Vogel ab.
The user and all related content has been deleted.