login
-
PRIEST schrieb:
Shade schreib mal nen Artikel drüber den les ich mir dann durch, komm grad net zum punkt was genau jetzt euer Thema is .. irgendwie hüpft man von A zu X und von X zu G und von G zu A oO
Der Punkt ist leicht:
Security Management sollte man bestehenden, erprobten, wenn möglich Open Source basierten Lösungen überlassen und nicht selber machen.Das ist wie Verschlüsselung. Da nimmt man ja auch fertige Systeme und baut nicht seinen eigenen Algorithmus.
-
ich hab jetzt nochmal nachgesehen, wie ich das mache...
session_start wird bei jedem Seitenaufruf aufgerufen (also existiert definitiv immer eine session_id.
Beim Login wird diese mit übergeben. Damit die nicht verändert wird, wird diese zur Sicherheit nochmal mit der "echten" session_id abgeglichen (fragt mich nicht, warum ich sie dann übergebe. Ich werd aber irgendeinen Grund gehabt haben :p)
Danach enthält die Session auch den Benutzernamen und das Passwort des angemeldeten Benutzers. Außerdem wird die sid in der Datenbank gespeichert (in der Tabelle, in der alle aktuell angemeldeten Benutzer gelistet sind, inkl. IP und Useragent)Beim Logout dann das übliche prozedere: session_destroy, session_start, session_regenerate_id
Hab ich da denkfehler drin? Es ist ein paar Jahre her, dass ich diesen Teil meines Projekts geschrieben hab und steigt derzeit noch nicht ganz durch. Bei Bedarf kann ich auch Code geben. Ich will nur sicher sein, dass hier kein Schlupfloch existiert (obwohl ich erstaunt bin, an was ich das alles gedacht hab oO)
-
Shade Of Mine schrieb:
PRIEST schrieb:
Shade schreib mal nen Artikel drüber den les ich mir dann durch, komm grad net zum punkt was genau jetzt euer Thema is .. irgendwie hüpft man von A zu X und von X zu G und von G zu A oO
Der Punkt ist leicht:
Security Management sollte man bestehenden, erprobten, wenn möglich Open Source basierten Lösungen überlassen und nicht selber machen.Das ist wie Verschlüsselung. Da nimmt man ja auch fertige Systeme und baut nicht seinen eigenen Algorithmus.
Wen dies der Punkt ist geb ich dir Recht. :schland:
-
Hallo,
ich bin kein Freund vom "mit Kanonen auf Spatzen schießen". Ich will eine einigermaßen sichere Website und nicht das Pentagon nachbauen.
Wieso soll ich mich schlau lesen wenn du es alles weißt? Du wirfst mit Begriffen um dich, hälst es aber nicht für nötig, diese auch mal zu erläutern, oder mit meinem Beispiel zu verbinden...
Btw.: Nun hab ich mich doch schlau gelesen und festgestellt, dass ich nicht mehr weiß als ich vorher auch schon wusste.
Alle 3 Dinge kommen in etwas folgendem Szenario gleich:
Mein bester Freund ruft mich an und fragt - nur so aus Neugier - nach meinem Benutzernamen und meinem Passwort. Ich bin natürlich so blauäugig und gebe ihm die gewünschten Informationen. Nachdem ich festgestellt hab, dass diese Aktion mächtig unklug war, geh ich zu meinem Dienstanbieter und mecker ihn an, wieso er das Problem nicht erkannt hat und schnell mein Kennwort änderte....VlG
-
RandomAccess85 schrieb:
Btw.: Nun hab ich mich doch schlau gelesen und festgestellt, dass ich nicht mehr weiß als ich vorher auch schon wusste.
Alle 3 Dinge kommen in etwas folgendem Szenario gleich:
Mein bester Freund ruft mich an und fragt - nur so aus Neugier - nach meinem Benutzernamen und meinem Passwort. Ich bin natürlich so blauäugig und gebe ihm die gewünschten Informationen. Nachdem ich festgestellt hab, dass diese Aktion mächtig unklug war, geh ich zu meinem Dienstanbieter und mecker ihn an, wieso er das Problem nicht erkannt hat und schnell mein Kennwort änderte....Nein, falsch. Komplett.
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.
Das ist recht trivial zu machen.
Also vielleicht doch mal in das Thema einlesen? Das sind wirklich nur die Grundlagen. Es gibt viel mehr Angriffe als ich überhaupt kenne...
@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).
-
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
-
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
-
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 WikipediaOh, 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
-
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
-
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!
-
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ürfenVlG
-
RandomAccess85 schrieb:
Reicht jetzt
Wir sind alle alt genug um eine eigene Meinung haben zu dürfenSolange 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