Datenbank schützen, SQL abfragen mit Passwort Übergabe, SSL-Verschlüsselung

[ChristianK]

Doch, ich habe für jeden Login ein anderes Passwort. Dafür gibt es ja Passwort-Manager.

Dein Argument relativiert sich:

1. Gibt es Rainbow-Tables für alle gängigen Hashing-Verfahren, die ziemlich vollständig sind.

2. Ist client-seitiges Hashen das falsche Verfahren. Dafür gibt es SSL. Wenn ich mich dazwischen setzen kann, also HTTP-Requests lesen, dann kann ich diese auch modifizieren. Du glaubst nicht, wie easy das ist ohne SSL. Und dann kann ich einen KeyLogger schreiben, der mir die Passwörter zusendet.

[Thallius]

Doch, ich habe für jeden Login ein anderes Passwort. Dafür gibt es ja Passwort-Manager.

Dein Argument relativiert sich:

1. Gibt es Rainbow-Tables für alle gängigen Hashing-Verfahren, die ziemlich vollständig sind.

2. Ist client-seitiges Hashen das falsche Verfahren. Dafür gibt es SSL. Wenn ich mich dazwischen setzen kann, also HTTP-Requests lesen, dann kann ich diese auch modifizieren. Du glaubst nicht, wie easy das ist ohne SSL. Und dann kann ich einen KeyLogger schreiben, der mir die Passwörter zusendet.

Seit wann kann ich denn einen Hash zu EINEM Passwort zurück codieren? Wenn ich nur den Hash transportiere, dann kann derjenige soviele Request abfangen wie er will. Ja klar, kommt er dann auf diese Plattform aber er kommt nicht auf eine andere da er mein Passwort nicht erfährt. Und andere Plattformen hashen anders. Also müßte er tatsächlich für jede Verbindung die ich mache alles Abfangen.

Das das Abfangen ohne SSL total easy ist ist klar. Ich habe ja auch zu SSL geraten.

Wobei es doch eh egal ist wieviel Mühe Du Dir gibst. Es gibt immer einen Weg das zu knacken.

Gruß

Claus

[ballotade]

Okay, das wäre also ein Argument für SSL, danke!

Bei der Sache, ob ich meine Datenbank mit einem Passwort sichern soll, sodass ich bei jeder SQL-Abfrage ein Passwort mitschicken muss, ist jetzt Konsens, dass das nicht nötig ist?

[Thallius]

Okay, das wäre also ein Argument für SSL, danke!

Bei der Sache, ob ich meine Datenbank mit einem Passwort sichern soll, sodass ich bei jeder SQL-Abfrage ein Passwort mitschicken muss, ist jetzt Konsens, dass das nicht nötig ist?

Irgendwie scheinst Du noch ein Problem zu haben was Client und Server kommunikation angeht.

Wenn du ein PHP Script auf dem Server laufen läßt, dann kommt davon erstmal gar nichts nach draussen. Wenn der Server also eine SQL Abfrage macht und dafür mit der Datenbank connected (Wozu er ein Passwort braucht), dann passiert das alles lokal auf dem Server. Erst wenn du dann mit z.B. echo etwas an den Client schickst geht das übers Netz. Da Du das Passort der Datenbank wohl kaum mit echo versenden willst, brauchst du dich dabei auch nicht um irgendwelche Sicherheit zu kümmern.

Was Du natürlich nicht machen darfst (und was die meisten Provider sowieso nicht zulassen) ist, dass du die PHP Scripte auf einem anderen Server laufen läßt als die Datenbank und dann die SQL Befehle übers internet verschickst. Das ist absolutes NoGo.

Gruß

Claus

[ChristianK]

Seit wann kann ich denn einen Hash zu EINEM Passwort zurück codieren? Wenn ich nur den Hash transportiere, dann kann derjenige soviele Request abfangen wie er will. Ja klar, kommt er dann auf diese Plattform aber er kommt nicht auf eine andere da er mein Passwort nicht erfährt. Und andere Plattformen hashen anders. Also müßte er tatsächlich für jede Verbindung die ich mache alles Abfangen.

Das das Abfangen ohne SSL total easy ist ist klar. Ich habe ja auch zu SSL geraten.

Wobei es doch eh egal ist wieviel Mühe Du Dir gibst. Es gibt immer einen Weg das zu knacken.

Gruß

Claus

Kannst du nicht, du kannst allerdings einen String suchen, der zum gleichen Hash wird. Das wäre dann eine sogenannte Collision. Und wie viele Hashing-Verfahren werden wirklich angewendet? Wordpress z.B. noch md5 und dann die meisten sha1.

Und wenn du SSL verwendest, wieso willst du dann zusätzlich auf dem Client hashen? Du erstellst damit eine Scheinsicherheit, die niemandem etwas bringt. Ich wiederhole es: Wenn ich die Kommunikation abfangen kann, kann ich sie auch beeinflussen. Wenn ich sie beeinflusse, dann kann eben jeglichen Inhalt der Webseite beeinflussen. Das bedeutet, ich kann auch dein Hashing deaktivieren und den User den Klartext senden lassen.

Client-seitiges Hashen/Verschlüsseln hat schon seine Berechtigung, man muss sich allerdings auch bewusst sein, wann es tatsächlich Sicherheit schafft und wann es nur Scheinsicherheit ist.

[ballotade]

Danke Thallius,

mir ist schon der Unterschied zwischen Client- und Serverseitig klar.
Und ich habe bisher noch keine Datenbank bei strato erstellt, deswegen war mir nicht klar, dass da unbedingt ein Passwort geschickt werden muss. Oder ist das das Passwort mit dem ich mich auch bei strato anmelde?
Dann geht es mir um genau dieses Passwort und ob ich es in einer externen Datei in einem verschlüßelten Ordner auslagern soll, damit er nicht im PHP-Code steht. Denn wie ich weiß kann man ganze Homepages aus dem Netz herunterladen (inkl. PHP Quelcode) und dann wäre das Passwort ja für jeden zu sehen.

Das wichtigste für mich ist aber: Wie macht man sowas? Gibts irgendwo eine Anleitung?

[Thallius]

Wenn Du Dir mal die Mühe machst und Dich bei Deinem Strato Account einloggst, dann wirst du dort den Punkt Datenbank-Verwaltung finden. Dort kannst du Deine Datenbanken sehen und die Passwörter für diese festlegen.

Und nein, man kann keinen PHP Quellcode von deiner Strato-Seite herunterladen. Das kann man nur, wenn man einen FTP oder sonstigen direkten Zugang zu Deinem Strato-Server hat. Diese wirst Du aber sicher nicht an andere weitergeben oder?

[ballotade]

Niemals!!!
Gut, dann schaue ich mir das mal an!

Danke!!

[Condor93]

Thallius das sind ja sehr interessante Fakten. ChristianK hat da aber recht.

Oder ich verstehe immer noch nicht, was es dir bringt.

Ein Clientbasierter Hash bringt dir 0. Jeder Benutzer kann sehen, wie du das PW hashed (muss ja im JS i.wo stehen). Gerade das wollen viele vermeiden, das Fremde wissen, wie man ein PW hashed. Was du wohl meinst sind eher Viren auf deinen Rechner, die deine Abfrage einfangen, bevor diese mit SSL verschlüsselt werden und an den Server sendet.

[ChristianK]

Solche Viren sind z.B. auch Norton AntiVirus oder auf Lenovo-Geräten vorinstallierte Software, die SSL-Zertifikate on-the-fly ersetzen.

http://www.scmagazineuk.com/pre-inst...rticle/399009/

[lstegelitz]

Ich frage mal anders herum: Was hindert jemanden externen daran auf meine Datenbanken zuzugreifen, in denen sich z.B. Kundendaten befinden? Habe da wirklich keine Ahnung!!!

Die Netzwerkkonfiguration...
Datenbanken werden in der Regel so konfiguriert, das nur interne IPs connecten können. Vom Internet aus sieht man den Datenbankserver also garnicht..