login

zwutz

Shade Of Mine schrieb:

@zwutz:
Soweit ich das sehe fährst du dann lediglich zweigleisig. Du hast keine eigenen Sicherheitslücken erschaffen aber auch nicht wirklich einen Vorteil von deinem System. Wenn du die Session mit session_start startest und mit session_destroy löscht, und dazwischen zusätzlich Daten in $_SESSION und in einer DB speicherst, dann ist das kein Sicherheitsproblem. Sofern du die Garbage Collection korrekt machst (du musst die Session ID ja aus der Datenbank und aus dem PHP System etwa gleichzeitig löschen oder für ungültig markieren).

Die Session-ID in der Datenbank hat rein statistische Gründe und wird zu keinem Zeitpunkt für sicherheitsrelevante Tätigkeiten genutzt.

Naja... bei Gelegenheit seh ich nochmal drüber. Das ist teilweise vor fünf oder sechs Jahren entstanden ^^

Wie sollte man es denn idealerweise machen?

Shade Of Mine schrieb:

Folgendes Szenario: du bist Admin deiner Seite. zB gibt es dort eine Online Anzeige die anzeigt welcher User online ist. Ich sehe dass du jetzt gerade Online gekommen bist. Nun versuche ich deine Session ID zu erraten. Da dein Algorithmus zum Erzeugen der Session ID sehr schwach ist, kann ich recht schnell deine Session ID erraten und übernehme deine Session. Ich komm damit direkt in den Admin Bereich und gebe meinem User Adminrechte und habe deine Seite gehackt.

Was ein Blödsinn. Da kannst du ebensogut mein Passwort erraten.

Nebenbei:
"In Deutschland ist die rechtswidrige Datenveränderung (§ 303a StGB) und Computersabotage (§ 303b StGB) ebenso wie das Ausspähen von Daten, die gegen unberechtigten Zugang besonders gesichert sind, (§ 202a StGB) eine Straftat."
Quelle Wikipedia

zwutz

RandomAccess85 schrieb:

Was ein Blödsinn. Da kannst du ebensogut mein Passwort erraten.

hm.. um 10:45:50 warst du noch nicht online, dafür aber um 10:45:55.

Macht insgesamt mit deinem System nur 5 Mio. session-ids, die man durchtesten muss, eine davon gehört dir. Je nach Auflösung der microtime wohl eher deutlich weniger

Shade Of Mine

RandomAccess85 schrieb:

Was ein Blödsinn. Da kannst du ebensogut mein Passwort erraten.

Nope.
Auf diese Art und weise werden die meisten Algorithmen geknackt. Zumal du nichts gegen Bruteforce von Session IDs machen kannst, gegen Bruteforce von Passwörtern aber schon.
Aber ja, das ist die Standard Antwort auf Sicherheitsbedenken...
Dabei sind diese Sachen so trivial. Es ist wirklich Deppensicher. Es ist genauso wie ich nie verstehen werde warum es Buffer Overflows, SQL Injections, etc. gibt. Es ist trivial zu lösen.

Aber Arroganz hilft hier halt nicht weiter. Klar für die kleine private Homepage ist es egal - aber stell dir mal vor diesen Fehler gäbe es auf Seiten wie facebook. Oder auch zB hier. Du könntest ohne Probleme das ganze Forum löschen...

Du denkst dir vielleicht die genaue Uhrzeit ist schwer zu erraten, aber der PHP RNG ist bekannt ich brauche nur den Seed und schon habe ich die Session ID. Aber wieviele mögliche Seeds gibt es? Ich kann die Auflösung des Timers ja recht leicht herausbekommen da ich ja jederzeit selber eine Session ID generieren lassen kann und der Server sagt mir seine Zeit auf auch die Sekunde genau. Es ist wirklich kein Aufwand sowas zu knacken.

Wenn ich die Auflösung kenne, die wird so etwas 40ms sein, dann sind das nur noch ~25 Seeds pro Sekunde. Wenn ich dein Login auf 5 Minuten genau bestimmen kann sind das 7500 mögliche Session IDs.

Nur so damit du eine ungefähre Vorstellung hast wieviel einfacher das ist als dein Passwort zu erraten.

"In Deutschland ist die rechtswidrige Datenveränderung (§ 303a StGB) und Computersabotage (§ 303b StGB) ebenso wie das Ausspähen von Daten, die gegen unberechtigten Zugang besonders gesichert sind, (§ 202a StGB) eine Straftat."
Quelle Wikipedia

Oh, es ist illegal die Seite zu hacken?
Das hilft sicher.

Hallo,

ich hab das Problem schon verstanden, finde es aber trotzdem absolut überflüssig weiter darauf einzugehen. Ihr könnt mir das nun super stolz vorrechnen -> aber auch nur weil ich euch das System verraten hab. Ich brauch keine 2 Minuten, dann ist es geändert und dann funktioniert es nicht mehr so einfach.

Man muss nicht klug spielen, wenn man mit Fakten umsich wirft, die sowieso jeder kennt. Nebenbei bemerkt kann ich euch meine ID auch direkt verraten, bringen wird sie euch nix :)!

VlG

Shade Of Mine

RandomAccess85 schrieb:

Nebenbei bemerkt kann ich euch meine ID auch direkt verraten, bringen wird sie euch nix :)!

Nach welchem Kriterium sperrst du?
Auf IP und HTTP Header Basis zu sperren ist eine schlechte Idee.

PS:
Du musst immer annehmen dass das System bekannt ist. Deins ist sogar trivial erkennbar. Ich generie 2 Sesison IDs pro 1ms und habe dein System erkannt - weil gleiche Session ID zurück kommt.

Dir geht es nur ums Prinzip, oder?

Hallo,

mir geht es darum, dass ich nicht übertreiben muss, wenn es um primitive Websites oder Homapages geht. ich sagte irgendwann am Anfang schon, dass das ganze im tägl. Job ganz anders aussieht, dort spielen aber auch viel wichtigere Faktoren eine Rolle.

Wenn jemand der Meinung ist mein Privatprojekt "hacken" zu müssen, kann er das gerne tun. Mit der dann erhaltenen ID kann er / sie wie gesagt nichts anfangen. Weder habe ich einen Admin-Bereich noch eine Benutzerverwaltung in meinem Projekt => wenn dann physisch getrennt (Benutzerverwaltung und Administration = Datenbank // Serveradministration).

Ich nutze die ID wie schon mehrfach erwähnt nur, um einen Benutzer zu identifizieren! Und ob am anderen Ende Paul, Hannelore oder Gustav sitzt ist mir sowas von sch*** egal.

Von daher nimm es bitte einfach so hin, wenn ich dir sage, dass dir die ID nichts bringt!

VlG

PRIEST

RandomAccess85 schrieb:

Von daher nimm es bitte einfach so hin, wenn ich dir sage, dass dir die ID nichts bringt!

Hihi, seh ich anders
Aber das ist ein anderes Thema :D! Habt ihr euch jetzt ausgekaspert? ^^

:schland:

PRIEST schrieb:

Habt ihr euch jetzt ausgekaspert? ^^

Ja, ich bin fertig!

Shade Of Mine

RandomAccess85 schrieb:

mir geht es darum, dass ich nicht übertreiben muss, wenn es um primitive Websites oder Homapages geht. ich sagte irgendwann am Anfang schon, dass das ganze im tägl. Job ganz anders aussieht, dort spielen aber auch viel wichtigere Faktoren eine Rolle.

Hat anders geklungen
Nur erzähl den Leuten hier dann nicht dass es so Gut ist.

Reicht jetzt
Wir sind alle alt genug um eine eigene Meinung haben zu dürfen

VlG

Shade Of Mine

RandomAccess85 schrieb:

Reicht jetzt
Wir sind alle alt genug um eine eigene Meinung haben zu dürfen

Solange Halbwahrheiten Anfängern nicht als Wahrheit verkauft werden ist mir alles recht.

Hey,

eigentlich sehr interessant hier - Danke Shade Of Mine für Dein Bemühen, hier ein paar Infos unters Volk zu werfen!

Ich habe mich in letzter Zeit ein wenig mit PHP, Logins und Sessions auseinandergesetzt und versucht, ein wenig dazuzulernen (in Fh Vorlesungen kam das Thema leider so gut wie gar nicht vor..). Gefunden habe ich folgende Profi-Variante aus diesem Tutorial: http://www.phpbuddy.eu/login-systeme-einfach-bis-profi.html?showall=1

Was haltet ihr davon? Ist das wirklich sicher und gibt es Verbesserungen?

Ich habe das System in mein Projekt so in der Art übernommen, fühle mich bisher ganz gut damit, allerdings wäre es schön, noch die Meinung eines zweiten Fachmannes zu hören (Shade Of Mine, da Du Dich ja schon angeboten hast hier zu sagen, wie mans richtig macht... es wäre schön, ein paar Worte von Dir darüber zu hören ).

Ich bezeichne mich nicht als PHP-Profi, aber kann dir trotzdem schon etwas dazu sagen. Dabei möchte ich mich nicht direkt auf das Script beziehen, sondern sagen, was ich als wichtig erachte, um ein sicheres System zu entwickeln.

Die Session-ID darf auf keinen Fall in die Hände dritter Fallen, da man sonst Zugriff erhält. Deswegen sollte man zu der Session-ID auch unbedingt die IP-Adresse abspeichern.

Passwörter werden als Hash gespeichert und dazu noch mit einem Salt zusätzlich verfremdet.

Benutzereingaben sind unschädlich zu machen. Bei Eingaben wie z.B. dem Benutzernamen sollte eine Whitelist verwendet werden, die definiert aus welchen Zeichen ein Benutzername bestehen darf.

Das Unterdrücken von Fehlermeldungen ist sicherlich sinnvoll, wenn das System fertig ist. Es sollte eine globale Variable geben, die die Fehlermeldungen wieder aktiviert, falls benötigt.

So wie ich das sehe wird das soweit alles gemacht. In dem Login steckt eine menge Arbeit und ich denke, dass das Login ausreichend sicher sein sollte.

Ich hab mir nicht den gesamten Quellcode angesehen, aber was ein gutes Login noch ausmacht ist das man nach einigen fehlerhaften Versuchen zunächst temporär gesperrt wird. So werden Bruteforce-Attacken unterbunden.

Genaures kann dir aber sicher Shade Of Mine sagen.

Hallo,

die Profi-Variante kann man bedenkenlos einsetzen. Aber nach meiner Meinung war ja nicht gefragt

Bye

PRIEST

RandomAccess85 schrieb:

... Aber nach meiner Meinung war ja nicht gefragt

lol, du bist sone zicke :D:D:D

:schland:

Shade Of Mine

llllllllll schrieb:

Die Session-ID darf auf keinen Fall in die Hände dritter Fallen, da man sonst Zugriff erhält. Deswegen sollte man zu der Session-ID auch unbedingt die IP-Adresse abspeichern.

Leider hilft das nicht immer. Denn du hast dann Probleme mit Leuten hinter Proxys und AOL Kunden. Auch bringt das nur bedingt etwas, da man Cross Site Request Forgeries so eh nicht abblocken kann.

Gegen Session ID Diebstahl hilft im Prinzip nur jedesmal eine Passwort Eingabe und neue Session ID generieren wenn eine wichtige Funktion ausgeführt werden soll (zB Zahlungsdaten ansehen, Admin Funktionen, etc.)

Der Rest von dir sind aber super Guidelines!

iop

@llllllllll
Die Punkte, die Du aufzählst bestätigen das Tutorial - gut zu wissen!

Shade Of Mine schrieb:

Leider hilft das nicht immer.

Was wäre eine Alternative? Im Tutorial wird die IP, der Benutzername, ein Hash der Anmeldezeit und die Browserkennung zur Erkennung des Users benutzt. Wäre ein AOL User hier also bei jeder geschützten Seite gezwungen sich neu anzumelden?
Also IP im Endeffekt checken oder nicht?

@RandomAccess85
Hey, ich will hier niemandem auf den Schlips treten, aber Du bettelst ja quasi darum... ich habe niemanden verboten seine Meinung zu schreiben, sondern lediglich explizit um eine Aussage von Shade Of Mine gebeten
Außerdem hast Du bereits selbst geschrieben, dass Du von Sessions wenig Ahnung hast, also wieso beschwerst Du Dich? Und einfach zu sagen, man kann dies und das bedenkenlos tun ohne zu sagen warum hat einen Hauch von blabla..

Hallo,

vermutlich hab ich deine Frage falsch verstanden. Es klang für mich wie: "Was haltet ihr davon?"...
Ich hätte mich auch ausführlicher ausdrücken können, aber ich dachte ein einfaches sinngemäßes: "Das Script ist in Ordnung, man kann es bedenkenlos einsetzen" reichte aus
Warum du es bedeneknlos einsetzen kannst? Weil so ziemlich jede Eventualität berücksichtigt ist und das Script somit als sehr sicher gilt.

VlG

Shade Of Mine

iop schrieb:

Wäre ein AOL User hier also bei jeder geschützten Seite gezwungen sich neu anzumelden?
Also IP im Endeffekt checken oder nicht?

Ja, das kann passieren.

Man kann nichts vom Client checken, auch nicht User Agent oder dergleichen, das führt alles zu falschen Erkennungen. Also IP nicht checken. Auch keinen User Agent, garnichts.

Gegen Session Hijacking hilft nichts. Wenn man die Session ID hat, kann man die Session übernehmen. Aber man kann sich gegen das Ausnützen schützen indem man immer Passwörter verlangt wenn der User seine privaten Daten einsehen oder ändern will. Amazon macht das zB sehr schön. Das muss man sowieso auch machen um sich gegen Cross Site Request Forgeries zu schützen. Und immer Session ID ändern nachdem der User einen Privilegien Wechsel durchgeführt hat (zB in den Admin Bereich eingeloggt, etc.)

Deshalb versucht man die Session ja geheim zu halten.