login

[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.

[Gast]

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.

[iop_offline]

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 ).

[llllllllll]

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.

[Gast]

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..

[Gast]

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.