nicht angemeldet
hi!
Wenn Cookies verwendet werden, natürlich nicht. Insofern ist die Methode mit Cookies natürlich besser, weil der Browser diese Daten im Cookie wirklich nur an den entsprechenden Server zurücksendet (oder wahlweise an Server dieser Second-Level-Domain), aber sicher ist es dadurch natürlich noch lange nicht. Nur die Session-ID im Cookie kann ebenfalls geraten werden. Da sollte dann doch lieber der Timestamp der Anmeldung mit reingeraten und verschlüsselt werden. Den Timestamp kann dann nur der Server generieren, und nur wer sich ordentlich angemeldet hat, kann arbeiten.
Wenn die Sicherheit es erfordert, muß man eben Cookies zur Pflicht machen.
OK, also cookies, aber nicht für die SesionID sondern vielleicht microtime() oder so ja? Auch hier wieder, sollteman das noch verschlüsseln?
Ach ja, und den Wert registriere ich in der Session und kann dann immer vergleichen, prima :-)
Aber bei der Flut an Trojanern und Würmern sind Cookies ja auch nicht mehr unbedingt das sicherste, naja.
Ja, Proxys könnten da was reinfummeln. Aber wie häufig und wahrscheinlich ist das? Und was passiert, wenn es tatsächlich gemacht wird? Wenn man die Möglichkeit voraussieht und sich entsprechend darauf einstellt, dann ist das zwar auch ein Problem, aber nur ein relativ kleines für eine sehr begrenzte Zahl von Benutzern. Und wenn man das Problem durch Umgehen des Proxys abstellen kann - ok. Wer das nicht kann - Pech. Lieber gewisse Mindestforderungen stellen, als unsicher werden, oder?
Aber das Problem kann nur bei Leuten auftreten, die selber bewußt Proxies verwenden? Ich meine es gibt ja acuh viele proxies in Firmen... und ich glaube alle AOL User hängen hinter Proxies, wenn ich mich recht erinnere! Also schon ein paar mehr Leute! Wobei damit nicht gesagt ist, das die proxies alle den Referer verändern, naja.
Eben, die meisten Browser akzeptieren nun mal text/html, image/gif, image/jpg und */*. Nur sehr selten tragen sich hier Plugins ein, die dann ebenso auftauchen - dazu wird diese Browserangabe viel zu selten ausgewertet. Ich habe beispielsweise noch von keinem Server gehört, der dem Browser wahlweise GIF, JPG oder PNG liefert, je nach Wunsch. Das wäre viel zuviel Aufwand für den Ersteller (der sich entweder für GIF entscheidet, weil er transparenz braucht oder Schriften hat, oder für JPG, weil Fotos vorliegen). Es lohnt also kaum, sich hieran zu orientieren, die Angaben sind zu ähnlich.
Aber gerade weil es so dumm wäre kommt da noch nicht mal ein schlauer Cracker drauf, und da das so lang ist kommt er auch mit probieren nicht sehr weit :-)))
Du hast dann immer noch einen riesigen Bereich des Internets, aus dem gleichzeitig Benutzer und Angreifer kommen könnten. 62.0.0.0/8 ist beispielsweise der Beginn von IP-Adressen in Israel, Griechenland, der Schweiz... ich hab nurmal kurz angetestet, was ripe.net dazu sagte. Deutschland ist auch vertreten.
Naja, hast Recht, aber was mich noch mehr stört ist die Tatsache, das es anders herum auch ahnungslose User die die Internet-Verbindung getrennt hatten rausschmeißen kann!
Aber nur mal angenommen ein Angreifer bekommt die SessionID aus dem Referer-Eintrag in irgendwelchen log-Files, da steht der Agent doch direkt daneben, oder?
Bingo, daran hatte ich irgendwie nicht gedacht. Allerdings weiß das der Angreifer natürlich nicht, und ein schlaues System wird den Einloggversuch mit falschen Daten bei gleichzeitig aktiver Session mit richtigen Daten registrieren und evtl. Warnungen aussprechen oder die Session beenden und eine Neuanmeldung verlangen.
Naja, letztendlich stimmt in solch einem Fall was an der Sicherheit nicht, und diese obige Idee wäre ein Nachreparieren, wo vorher grundlegende Konstruktionsfehler gemacht wurden. Außerdem kann das wieder mal bei flexiblen Benutzern (z.B. zweiter Browser des gleichen Benutzers, URL per Copy&Paste übertragen -> User-Agent unterschiedlich) zu Fehlern führen, die nicht sein müssen.
Ja, aber das könnte man ja grundsätzlich machen, wenn irgendwas nicht stimmt! Wenn der User sowas macht ist er selbst schuld, wenn er in einem sensiblen Bereich arbeitet. Da bringen ja noch nichtmal Cooies was, geschweige denn htaccess!!!
Anscheinend nicht so einfach. Im Prinzip wirklich nur mit Cookies. Der Cookie wird, genau wie die Useranmeldung bei .htaccess, ausschließlich an den jeweiligen Webserver gesendet, und zwar im HTTP-Request. Keine dieser Daten gelangen durch irgendwelche Datenlecks wie Referrer etc. an andere Webserver, da zum Glück entsprechende Sicherheitsvorschriften gemacht wurden. Das System kann nur kompromittiert werden, wenn der Angreifer die Kommunikation zwischen Benutzer und Server abhören kann.
Aber das hätte ja bei htaccess dasselbe Resultat, oder? Aber kann man das denn überhaupt abhören, wenn man per SSL verschlüsselt?
Das ist alles nichts. Wie findest du raus, daß Javascript aktiv ist? Du läßt eine externe Javascript-Datei laden. Wie kriegst du diese Information eines vollkommen separaten Requests in die eigentliche Sessioninformation mit hinein? Wohl garnicht. Was, wenn der Benutzer beim Anmelden JS ausgeschaltet hat und es aus irgendwelchen Gründen zwischendurch einschaltet - oder umgekehrt? Eben...
http://www.php.net/manual/de/function.get-browser.php
ich weiß, das ist nicht 100%ig, da kann man fälschen, das stimmt eh nicht... das hatten wir alles schon! Aber tatsache ist, das man diese Werte abfragen kann, und ich bin mir 100%ig sicher, das keiner auf dei Idee kommen wird, mal zwischendurch seine Einstellungen der Art zu verändern. Auf anderen Seiten vielleicht(glaube ich aber grundsätzlich nicht), aber die durchschnittlichen User der betroffenen Seite wissen wahrscheinlich noch nichtmal dass man das mache kann...
und das verändert sich _garantiert_ nicht bei irgendwelchen Proxies! Ein weiterer Vorteil, ich denke 90% der User haben Javascript & Co eingeschaltet, und wenn jetzt einer mit was für tools auch immer probiert auf die Seite mit bekannter Sesion ID und bekanntem Timestamp auf die Seite zuzugreifen, wird er scheitern, solange der User Javascript aktiviert hatte, denn solche "Sicherheits"-Software wird sowas wohl kaum mitsenden, oder?
Und was ich dann noch weniger verstehe, wenn ich vergleiche:
if($crypt_pw==crypt(klartext_pw)
Du mußt eben dafür sorgen, daß das Salz identisch ist, indem du einfach das verschlüsselte Paßwort als Salzwert an crypt() mit übergibst. Crypt wird die ersten beiden Zeichen als Salz verwenden.
Aber was mache ich bei der ursprünglichen Verschlüsselung? Ich könnte mir das nur mit dem Klartext Passort vorstellen, das habe ich sowohl wenn ich das erste mal verschlüsele und das speicher, und jedesmal wenn ich prüfe. Aber das als Parameter eine Funktion, die mir erstmalig ein Passwort verschlüsseln soll das eigentlichen Ergebnis anzugeben geht IMHO nicht, oder? Wie hattest Du das gemeint?
Man kann sich aber vorstellen, daß es bei unbegrenzter Länge des Paßwortes ganz sicher unendlich viele Paßwörter gibt. Unendlich viele Inputvarianten werden auf 218.340.105.584.896 Outputvarianten gemappt - da gibt es Dopplungen im Ergebnis, ganz klar. Wie lange man dafür suchen muß, kann ich aber nicht sagen.
Na das hört sich ja rosig an :-)
Grüße
Andreas