PHP Login Sicherheitstheorie

    Hi,

    mir ist grade eine Idee gekommen und einen PHP-Login (wenn er vor sql-injection geschützt ist) weite abzusichern.

    Zurzeit gibt es im Grunde ja drei Konzepte um einen PHP-Login abzusichern:

    - Captcha
    - Code per SMS (z.B. Paypal)
    - Token (z.B. Blizzard)

    Captcha ist kein wirklicher Schutz sonder lediglich eine Erschwernis für automatisiertes Login, Code per SMS schreckt viele Leute direkt ab weil man sein Handynummer rausgeben muss und Token bringt kosten da man ein entsprechendes Stück Hardware benötigt. Bei SMS und Token entstehen für den Betreiber der Webseite noch zusätzliche Kosten. Aller zusammen haben den Nachteil das man noch einmal zusätzlich etwas eintippen muss neben Username und PW.

    Meine Idee war nun eine Abwandlung des "Code per SMS". Und zwar das ganze auf ICQ/MSN angewandt. Hierbei wird dann auch nicht ein Code gesendet sondern direkt ein entsprechender Link. Dies hat meiner Meinung nach folgende Vorteile:

    - keine manuelle zusätzliche Eingabe nötig
    - ICQ oder MSN haben die meisten Personen bzw. selbst wenn man es nicht hat entstehen durch das Installieren keine Zusatzkosten
    - keine zusätzlichen Kosten für den Betreiber, da man direkt via PHP Daten an ICQ/MSN versenden kann
    - Die "Anonymität" des User bleibt weiterhin bestehen, da man ja nicht gezwungen ist bei ICQ persönlich Daten anzugeben

    Wüsste nun mal gerne ob ich irgendwas an dieser Sache übersehne habe, was das ganz doch nichtmehr so gut macht.

    Andy hat mir ein Schnitzel gebacken aber da war ein Raupi drauf und bevor Oscar das Bugfixen konnte kam Alina und gab mir ein AspirinJunkie.

    Also der grundlegende Schutz fängt schon bei der Datenbankabfrage an.
    erstmal alle Informationen die von außen kommen müssen mit mysql_real_escape_string escaped werden.
    Dann zu der eigentlichen Abfrage. Spalten und Tabellennamen in `` und Daten in '' damit kann man verhindern das ein OR '' = '' angehängt wird.

    Du kannst auch einmal-Passwörter generieren, die du per Mail schickst.
    Letztendlich kann man das beliebig skalieren, nur halt dann auf Kosten des Komforts.
    Absolute Sicherheit - sowohl des Logins selbst wie auch vor Automatisierung - erreichst du per Definition nicht, es ist also immer ein Abwägen.

    Falls deine Theorie in die Praxis umgesetzt wird und auch öfters angewandt ist es noch einfacher als mit Captcha:

    Zitat von chip

    Captcha ist kein wirklicher Schutz sonder lediglich eine Erschwernis für automatisiertes Login


    denn einen Account bei ICQ/MSN zu erstellen kann man ja auch automatisieren,

    mfg autoBert

    autoBert: Das ist doch egal denke ich. So wie ich das sehe, möchte chip doch den Login absichern und nicht die Registrierung. Durch den zusätzlichen Link über ICQ ist es schwerer einen Account zu hacken. Man muss nicht nur Benutzer das Passwort kennen sondern auch die zugehörige ICQ-Nummer und das ICQ-Passwort, um sich einloggen zu können. Das dient also der Anwendersicherheit und eindeutiger Identifizierung des Users, nicht dem Schutz vor Bots.

    Edit: Es gibt noch eine weitere Möglichkeit, den Login abzusichern. Du erstellst ein AutoIt-Programm, das mit Hilfe eines für jeden Nutzer eindeutigen Strings und eines Sessionkeys pro Anmeldung einen Hash generiert, den der Nutzer zum Login angeben muss, das ist auch etwas zusätzliche Sicherheit.

    @SlowlyDead: So eine Hash-Berechnung lässt sich auch mit Java und sogar Javascript oder sonst was durchführen. Autoit war nur ein Beispiel, weil das ein AutoIt-Forum ist ;)

    EInfach bei der Registrierung schon festlegen, dass das passwort länger al 8 Zeich sein muss und nicht glehc sein darf wie der Anmeldename, außerdem sollte man ebenfalls einbinden, dass das pw nicht nur aus einem einzellnen Zeichen bestehen darf, also z.b. 9 mal die 1 ^^.

    Wenn man das alles berücksichtigt wird so ein passwort, wenn man es nicht weiter gibt nie zu knacken sein.

    Zusätzlich könnte man bei 5 maliger falscheingabe des passwortes bei der Anmeldung einen sicherheitscode an die benutzeremail schicken.

    Zitat von SlowlyDead

    Achso meinst du das, ich hatte es als einen Hardware-Hash verstanden, um den Account an einen Rechner zu binden.


    finde ich keine gute Idee, wenn sich die Leute mal bei freunden oder sonst wo einloggen wollen wäre dies ja dann nicht möglich :)

    Das finden von Rechtschreibfehlern muss sofort und unverzüglich dem Autor gemeldet werden. Das eigennützige Verwenden dieser Rechtschreibfehler ist strengstens untersagt und kann mit Freiheitsenzug bestraft werden.

    StringRegExpTo2DArray

    Zitat von Sprenger120

    Also der grundlegende Schutz fängt schon bei der Datenbankabfrage an.
    erstmal alle Informationen die von außen kommen müssen mit mysql_real_escape_string escaped werden.
    Dann zu der eigentlichen Abfrage. Spalten und Tabellennamen in `` und Daten in '' damit kann man verhindern das ein OR '' = '' angehängt wird.

    Erst lesen dann Posten. Schon im ersten Satz steht "wenn er vor sql-injection geschützt ist".

    Zitat von Darter

    EInfach bei der Registrierung schon festlegen, dass das passwort länger al 8 Zeich sein muss und nicht glehc sein darf wie der Anmeldename, außerdem sollte man ebenfalls einbinden, dass das pw nicht nur aus einem einzellnen Zeichen bestehen darf, also z.b. 9 mal die 1 ^^.

    Wenn man das alles berücksichtigt wird so ein passwort, wenn man es nicht weiter gibt nie zu knacken sein.

    Da sag ich einfach mal das dieser Aussage falsch ist. Nehmen wir an du heißt Michael und bist 1980 geboren. Nun nimmt als dein Passwort "michael80". So ein Passwort sehr sehr sehr leicht zu erraten und es gibt viele die solche Passwörter haben.

    Zitat von progandy

    Edit: Es gibt noch eine weitere Möglichkeit, den Login abzusichern. Du erstellst ein AutoIt-Programm, das mit Hilfe eines für jeden Nutzer eindeutigen Strings und eines Sessionkeys pro Anmeldung einen Hash generiert, den der Nutzer zum Login angeben muss, das ist auch etwas zusätzliche Sicherheit.

    Was allerdings dann nur auf einem Windowsserver ginge, der das Autoitscript compiliert und dann an den User beim registrieren zum Download ausgibt. Das wären wiederum aber erhöhte Kosten durch die Serverlizenz da normaler Webspace das nicht machen kannst. Alternativ wäre höchstens noch eine seperate Ini.
    Nur müsste man das Programm dann überall dabei haben wenn man sich irgendwo anders einloggen will. Bei ICQ hat man immer die Möglichkeit noch ICQ2GO zu nutzen.

    Andy hat mir ein Schnitzel gebacken aber da war ein Raupi drauf und bevor Oscar das Bugfixen konnte kam Alina und gab mir ein AspirinJunkie.

    Einmal editiert, zuletzt von chip (21. November 2010 um 00:40)

    Allerdings reicht in dem Fall Username und Passwort aus um in den Account zu kommen. Da man ja zum berechnen des SHA1-Hashs der Sessionkey vom Server geschickt bekommt und die Berechnung immer gleich erfolgt.
    Wenn dann müsste man Tokensystem verwenden, sprich Server und Client berechnen mit einem jeweils einmaligen Hash temporär einen Loginkey uns zwar ohne, dass Daten vom Server zum Client gesendet werden.

    Andy hat mir ein Schnitzel gebacken aber da war ein Raupi drauf und bevor Oscar das Bugfixen konnte kam Alina und gab mir ein AspirinJunkie.

    Wie chip das meint, müsst der Token beim Registrieren gesendet werden, man ist also wieder an einen Rechner gebunden.
    Wie progandy das meint, schützt der Session Key vor einfachen replay-Angriff,
    jedoch nur solange, wie das Verfahren unerkannt bleibt (was bei einer Umsetzung in Js schwierig wird), aber es erhöht doch den Aufwand deutlich (für einen replay-Angriff).

    Eine weitere Möglichkeit wäre es, einen Session-Key in Abhängigkeit der Zeit zu errechnen, was allerdings eine syncrone Zeit an Client under Server vorraussetzt.

    Letztendlich wäre auch das wieder Security by Obscurity.