PHP PW plain Übertragung gängige Praxis?

[derBobby]

Hallo zusammen,

seit ein paar Tagen lerne ich ja jetzt schon PHP. Ich habe diverse Tutorials durch und das Buch "PHP5.3 & MySQL 5.1" vom Addison-Wesley Verlag.

Eine Kinokette, die hier in der Gegend ein Kino betreibt, bietet die Möglichkeit Karten online zu reservieren und zu buchen. Was mich jetzt etwas irritiert ist, dass die Login-Daten ohne SSL plain übermittelt werden. Gibt es nicht irgendwelche Funktionen, um das PW verschlüsselt oder MD5-gehashed per POST/GET zu übertragen? Oder ist das der Punkt an dem man mit JS anfangen müsste?

Mit SSL würde sich das natürlich auch lösen lassen. Ich nehme an, dass die Kino-Kette hier Kosten spart.

Liebe Grüße
derBobby

 

[NagathoR]

Ja, vom Kino ist das fast unverantwortlich, pers. Daten im Klartext zu übertragen.
Alles was vom Client passiert, wird mit Javascript gemacht, aber das ist keine richtige Verschlüsselung, sondern nur /mehr pseudo Verschlüsselung.

Ich denke, die Kinokette sollte lieber mal 50 EUR im Jahr in die Hand nehmen und sich ein Zertifikat besorgen, die Onlinebesteller werden es dem Kino danken, hoffe ich

 

[Daaron]

SSL ist die einzige Möglichkeit. Lediglich via JS könnte man die POST-Daten vor Versand manipulieren, aber sowas ist hochgradiger Unsinn. In allen anderen Fällen gehen die Daten erst raus und werden dann verarbeitet. Viel wichtiger ist, in welcher Form das PW in der Datenbank hinterlegt ist. Bei ner Firma, die kein SSL einsetzt, würde es mich noch niht einmal wundern wenn die wahlweise im Klartext speichern oder per MD5 ohne Salt....

Und wenn die Kinokette kein Geld für SSL hat, dann sollte sie evtl. mal bei Startssl.com vorbei schauen. Kostenloses Class1-Zertifikat mit einem Jahr Laufzeit für eine Domain nebst einer Subdomain.
Ist nur etwas knifflig einzurichten, wenn die Webseite auf einem VHost liegt. VHost + SSL, damit hab ich mir die letzten Wochen über schon so manche Stunde um die Ohren geschlagen... Am Ende ist man einfach resolut und schließt Opfer, die unter WInXP mit dem IE surfen, rigoros aus.

 

[derBobby]

Alles was vom Client passiert, wird mit Javascript gemacht, aber das ist keine richtige Verschlüsselung, sondern nur /mehr pseudo Verschlüsselung.

Wieso Pseudo-Verschlüsselung? Immerhin erschwert es das direkte erkennen eines Passwortes?

Lediglich via JS könnte man die POST-Daten vor Versand manipulieren, aber sowas ist hochgradiger Unsinn. [...] oder per MD5 ohne Salt....

Wieso Unsinn? Wie kann man Passwörter denn mit MD5 salten? Soweit bin ich noch nicht im Buch!

 

[Daaron]

Wieso Pseudo-Verschlüsselung? Immerhin erschwert es das direkte erkennen eines Passwortes?

Alles, was JS macht, macht es im Endeffekt "öffentlich". Du kannst den Quellcode von JavaScript eventuell etwas verschleiern, du kannst ihn aber nie geheim halten. Also würde alles, was du auf Client-Seite per JS machst, im Endeffekt nur verschwendete Rechenzeit darstellen.
Außerdem: Was machst du mit all den Leuten, die kein JS aktiv haben, weil sie z.B. NoScript laufen haben oder mit einem Screenreader etc. auf deiner Seite sind? JS sollte nur in absoluten Ausnahmefällen für mehr als "Eye Candy" verwendet werden.

Wieso Unsinn? Wie kann man Passwörter denn mit MD5 salten? Soweit bin ich noch nicht im Buch!

Unsinn ist die Modifikation per JS, weil sie clientseitig erfolgt. Siehe oben.

Und das mit dem Salt bezieht sich auf die Speicherung in der Datenbank. Zu MD5 gibt es im Netz die sog. Rainbow Tables, in denen zu jedem möglichen Hash passend das klare Ursprungs-Wort gelistet ist. Speicherst du ohne Salt, kannst du im Endeffekt auch gleich Reintext speichern, mit modernen CPUs ist ratzfatz die Rainbow Table nach dem Reintext durchsucht.
Wie man am Ende "salzt" entscheidet der Programmierer. Eine Möglichkeit ist, an das Reintext-PW eben dieses (irgendwo fest programmierte) Salz anzuhängen, bevor man MD5 laufen lässt. Man könnte sicherlich auch n anderen Ersetzungs-Algorithmus finden (z.B. ne Binär-Operation).
In der DB steht dann nur der Hash, der User gibt sein reguläres PW ein, das Programm führt jetzt die salt+hash - Funktion auf den Reintext aus und vergleicht en erzeugten Hash mit dem, was in der DB steht.
Oder man nimmt gleich ne bessere Hash-Funktion, z.B. SHA1, da spart man sich den Stress...

Ändert aber nix daran, dass das PW vom Client zum Server weiter unverschlüsselt übertragen wird, wenn der Server kein SSL bereit stellt.

 

[derBobby]

Okay, das clientseite leuchtet ein!

Hast du vielleicht gerade ein Beispiel für mich da, wie man ein PW salten kann? Wieso gibt es solcha Rainbow Tables dann aber nicht auch für andere Verschlüsselungsverfahren wie das SHA1?

Gruß und Dank!

 

[Daaron]

Hm, n Beispiel?
Irgendwo in einer Konfigurationsdatei machst du sinngemäß: $salt="HierKommtDeinSalz";
Der MD5-Hash errechnet sich dann statt aus "md5($passwort);" eben aus "md5($passwort.$salt);".

Natürlich kann man auch mit Salt noch per Rainbow Table vorgehen, aber die Datenmenge, die die Tabelle umfasst, steigt exponentiell an.
Es gibt grundsätzlich für alle Hash-Verfahren einen Weg, eine Rainbow Table zu erzeugen. Die Frage ist immer nur: Macht es wirtschaftlich Sinn? Es gibt z.B. angeblich eine Rainbow Table aller SHA1-Hashes, die aus (bis zu) sechstelligen Strings erzeugt wurden. N siebenstelliges PW oder n vierstelliges mit nem dreistelligem Salt, wäre hier in der RT schon nicht mehr drin. Eine RT für n siebenstelliges PW wäre hingegen so viel komplexer, dass es AKTUELL noch unhandlich wäre, sie zu durchsuchen oder auch nur zu lagern.

Edit: grad mal nachgeguckt, wie groß so ne RT eigentlich ist.
SHA1, kleinbuchstaben+zahlen+leerzeichen, 1-8 Zeichen: 17GB
dasselbe, aber 1-9 Zeichen: 109GB

Die gesamte MD5-RT-Sammlung, die ich hier seh, wiegt schlappe 2,2TB.

 

[derBobby]

Wtf?!

Wo gibt's denn solche Infos?

 

[ice-breaker]

SSL wird einfach meist gespart, weil es "zu teuer ist", bzw. technisch langsam limitierend ist.
Das SSL-Zertifikat kostet zwar nur seine 20€/Jahr aber es ist zudem noch eine eigene IP nötig, da SNI (Server Name Indication) z.B. von allen IEs auf einem Windows XP nicht unterstützt wird oder Android 2.x Geräten. Im Endeffekt führt SNI bei den Nutzern dazu, dass der Browser vor einer nicht vertrauenswerten Seite warnt, also hat man genau das Gegenteil von dem erreicht, was man erreichen wollte.
Eine eigene IP bietet dann auch nicht jeder Webspace-Provider, oder verlangt auf Grund der Ipv4-Adressen-Knappheit dann teilweise ordentlich Geld. Ein eigenes SSL-Zerifitkat darf dann eventuell auch nicht genutzt werden und man muss die teilweise sündhaft überteuerten Zertifikate des Webhoster für teilweise bis zu 100€/Jahr im nehmen.
Oder die zuständigen IT-"Spezialisten" haben einfach keine Ahnung von Ahnung SSL.


Alles das sind Gründe warum SSL heute so wenig eingesetzt wird. Wenn jede Webseite SSL mit einer eigenen IPv4-Adresse nutzen würde, wären diese auch längst aufgebraucht. Dann hätten wir zwar eventuell mittlerweile schon IPv6, aber das ist eine andere Geschichte.

 

[Daaron]

IPv6 wird sich in Jahren nicht durchsetzen. Eher fahren alle Autos weltweit mit Wasserstoff oder Strom, statt mit Benzin/Diesel...

Und SNI: Tja, Armutszeugnis für Android 2, dass es (außer via Firefox/Fennec) kein SNI kann... aber da darf man halt auch kein Mitleid haben. Das Netz wird nicht besser, wenn man laufend Mitleid mit Idioten hat.
Wie willst du z.B. zu deiner Facebook-Firmenpage einen Page Tab hinzufügen, wenn du keinen Zugriff auf einen SSL-Server hast? Toll, deine reguläre Firmenseite liegt irgendwo als VHost ganz gemütlich, aber ausgerechnet für deine Facebook-App musst du wegen Technologie-Opfern dann extra noch schweineteuer ne eigene IP mieten?

 

[Labtec]

@ Daaron
Europa und die USA sitzen ja auch noch auf genug IPv4-Adressen
Problem ist der Asiatische Raum - zuviele Leute und sie waren "zu spät"

 

[derBobby]

Wie ist das dann zum Beispiel hier auf Computerbase? Wie wird es hier gemacht? SSL wird nicht eingesetzt, allerdings wird das Passwort auch nicht im Klartext übertragen?

EDIT:
Beispiel mit FALSCHEM Passwort!
vb_login_username=derBenutzer
&vb_login_password=
&do=login
&vb_login_md5password=535779fdef24585375be9c10994b43ac
&vb_login_md5password_utf=535779fdef24585375be9c10994b43ac

 

[ice-breaker]

Neija es wird scheinbar vorher das Passwort in einen MD5-Hash umgewandelt, da kein Salt mitgeschickt wird, scheint es plain-md5 zu sein. Also reine Augenwischerei, denn dann steht das PW ggf. schon in einer der gigantischen Rainbow-Tables.

 

[derBobby]

Vielleicht ist es ja aber gesaltet, woher weiß man das denn?

 

[Daaron]

Wie gesagt: jegliche Form von nicht-serverbasiertem Hash ist pure Augenwischerei und im Zweifel sogar hochgradig gefährlich. Vor dem Versand kannst du nur auf eine einzige Art hashen: per JavaScript. Und wie schon gesagt:
- nicht jeder User hat JS aktiv
- JS ist immer lesbar

 

[derBobby]

Dann kommt jetzt mal noch eine Anschlussfrage dazu:

Ist man mit einem selbstsignierten SSL Zertifikat sicher vor dem Abgehört werden?

Natürlich ist das nichts, das man für offizielle Webseiten verwenden würde. Aber bietet diese Möglichkeit Sicherheit, wenn ich für den privaten Gebrauch eine Seite betreibe, um was-auch-immer zu tun? Oder können andere, wenn sie sich das Zertifikat beim Besuch der Seite zulegen dann doch "mithören"?

 

[ice-breaker]

Vielleicht ist es ja aber gesaltet, woher weiß man das denn?

wenn es gesalzen ist, wird aber für jeden Benutzer der gleiche Salt genutzt, damit ist dieser wieder nutzlos und man kann eben eine Rainbow-Table für alle Computerbase-Nutzer erstellen.

Ist man mit einem selbstsignierten SSL Zertifikat sicher vor dem Abgehört werden?

ja, es ist bei SSL egal, von wem das Zertifikat kommt. Offiziell signierte Zertifikate sind vom Sicherheitspunkt streng genommen weniger sicher, als ein selbst signiertes Zertifikat, welches du einmal komplett geprüft und erlaubt hast. Denn die offiziell signierten werden automatisch angenommen, das selbst signierte muss noch erlaubt werden. Wenn nun wieder eine CA gehackt wird, kann der Hacker eben ein Zertifikat für Google ausstellen und jeder Browser würde dies akzeptieren. Der Sicherheitsunterschied kommt natürlich aber erst zum Tragen wenn ein Nutzer bei Warnungen sich das Zertifikat genau ansehen und abgleichen würde, wenn er einfach akzeptieren drückt, sind beide gleich (un)sicher.

Du musst aber kein selbst signiertes nehmen, es gibt auch kostenlose: StartSSL.com bietet z.B. kostenlose Zertifikate an, die auch von allen Browsern unterstützt werden

 

[derBobby]

Okay! Vielen Dank für die vielen Antworten! Aber leider kommen mir immer wieder Fragen dazu!

Wenn man für jeden Benutzer einen eigenen Salt verwenden sollte, wie speichere ich diese denn dann ab? Wenn ich Benutzer, verschlüsseltes PW und Salt in die gleiche SQL-Tabelle schreibe, dann habe ich ja wieder nichts gewonnen?! Dann müsste ich für den Salt ja einen extra SQL-Server aufsetzen, wieder mit eigenem Benutzer und Passwort?!

 

[ice-breaker]

Wieso hast du nichts gewonnen? Wenn du für jeden Benutzer in deiner DB einen Salt speicherst, dann hast du den Vorteil gewonnen, dass nur noch Bruteforce-Angriffe auf ein Passwort zugleich möglich ist, das ist der maximale Schutz, den du erreichen kannst.

 

[Daaron]

Ist man mit einem selbstsignierten SSL Zertifikat sicher vor dem Abgehört werden?

Jap, die Verschlüsselung ist dann vollständig gegeben. Browser werden nur eben etwas zicken, weil dem Cert nicht voll vertraut wird. Für öffentliche Seiten ist das keine Option, für interne Zwecke ist es hingegen mehr als ausreichend.

wenn es gesalzen ist, wird aber für jeden Benutzer der gleiche Salt genutzt, damit ist dieser wieder nutzlos und man kann eben eine Rainbow-Table für alle Computerbase-Nutzer erstellen.

Ist der Salt nur lang/komplex genug, und bleibt er auch noch dazu geheim, ist es nicht wirtschaftlich tragbar, eine RT zu erstellen. Ich hab noch nie davon gehört, dass für jeden User ein eigener Salt angelegt wird. Ich hab bisher immer nur Lösungen mit einem einzelnen Salt gesehen, der dafür dann eben wenigstens 10-12 Zeichen lang is.

Übrigens hat deine Variante mit userbasiertem Salt, der in der DB gespeichert wird, einen RIESIGEN Haken!
Wann und wozu nutzt man Rainbow Tables? Man hasht die PWs in der Datenbank doch nur, dass falls mal jemand in die DB eindringen kann, er keine praktikable Möglichkeit hat, an die Klartext-PWs zu kommen. Wenn nicht gehasht ist, stehts gleich in Klartext. Wenn nur gehasht wurde, ohne Salt, kann man den Hash per RT "problemlos" in Klartext umwandeln. Wenn du jetzt für jeden User einen eigenen Salt anlegen willst, dann lagerst du diesen Salt in der DB. Du lagerst also Hash und Salt in einer gemeinsamen, kompromittierten Lagerstätte. Schlecht...
Viel sinniger ist da EIN Salt, der in einer Config-Datei außerhalb der DB gelagert wird. In der DB sollte keine Möglichkeit stehen, wie man z.B. per FTP auf diese Datei (und andere) zugreifen kann.