Extrem sicherer AJAX Login

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Extrem sicherer AJAX Login

    Ich werde unser Tutorial in Kürze darauf anpassen:
    Diese Möglichkeit des AJAX Logins ist echt genial..

    Nichtmal Portsniffer haben damit eine Chance..
    (normale php oder .htaccess logins über HTTP können da nicht mithalten)

    Link zur Seite:
    webthreads.de/2006/08/login-abfrage-via-ajax/
    ajaxpatterns.org/Direct_Login

    Der Server generiert serverseitig ein einmaliges Token mit zufälligen Zeichen (im englischen wird hier oft von einem “Seed” gesprochen). Dieses Token wird anschließend im Browser verwendet um das schon gehashte Passwort noch einmal ein eine neues Hash umzuwandeln. Die Daten werden anschließend an den Server übertragen. Das in der Datenbank gespeicherte Passwort-Hash wird nun auch mit dem Token in ein neues Hash umgewandelt und mit dem vom Browser übertragenen Wert verglichen. Stimmen die beiden Hashwerte überein sind auch die eingegebenen Daten korrekt und der User hat sich authentifiziert.
    Wichtig bei dieser Vorgehensweise ist, dass das Token immer nur ein einmaliges Token ist. Bei jeder Anfrage wird das Token neu generiert und ist nur für einen Versuch gültig. So kann ein abgehörtes Hash, was im Browser generiert wurde, nicht noch einaml verwendet werden.
  • Zu Worten folgen nun Taten:

    Hier im Wiki beschreibe ich einen sicheren AJAX Login. (Ihr könnt mich gerne vom Gegenteil überzeugen)

    Über Feedback würde ich mich wie immer freuen!

    Wiki:
    [coderwiki]HowTos/Ajax-Sicherer-Hash-Seed-Login[/coderwiki]
    Dateien
    • md5.js

      (8,57 kB, 1.268 mal heruntergeladen, zuletzt: )
    • sicherer-ajax-login.zip

      (5,41 kB, 1.672 mal heruntergeladen, zuletzt: )
  • ssl ist natürlich toll - kostet aber
    ich finde, dass das die beste möglichkeit der authentifizierung ohne ssl ist

    denn 100% plain wird doch nichts vom passwort übertragen

    der seed wird vom server erzeugt und als hash zum client übertragen
    der seed und das clientseitig gehashte password wird auf dem client erneut gehasht und zur authentifizierung zurück übertragen

    am besten löscht man nun serverseitig den hash wieder und lässt den client einen neuen seed anfordern
    bleiben ca. 3 Sekunden in denen der md5 algorithmus geknackt werden muss?

    bruteforce und wörtbuch-attacke gelten nicht als argumente da SSL dagegen auch nicht gewappnet ist..

    man-in-the-middle und phising - naja, was soll ein script dagegen tun???

    werde nun noch ein paar hinweise auf das löschen des seeds und die ip-sperre bei häufigen anfragen über die gleiche IP ergänzen

    BTW: Extreme Sicherheit gibt es nicht ;)
    Aber seit der Bildzeitung wissen wir, dass Schlagzeilen wie "Extreme Sicherheit" Klicks beschert
  • Hi! Ich bin neu hier und versuch mich gerad in Ajax einzuarbeiten :)
    Das mit dem Login gefällt mir sehr gut und ich hab da mal ein paar Fragen zu:

    Wenn ich im Browser nen Reload mache oder auf eine andere Seite forwarde dann muss ich mich doch danach wieder neu anmelden weil die Sessiondaten über Javascript gehändelt werden?

    Dann hab ich gelesen das man die Session-ID bei einem Login neu vergeben sollte wegen Session-Hijacking. Ist da was dran?

    Wenn ich die Session-Id nun über Ajax ändern will hab ich erstmal schon ein Problem weil die Header schon gesetzt sind und ich zum ändern die ganze Seite neu aufbauen müsste :-/

    Gruß Basti
    ---
    What's the main difference between intelligence and ignorance?
    A: I don't know and I don't care!
  • "d0nUt" schrieb:

    bruteforce und wörtbuch-attacke gelten nicht als argumente da SSL dagegen auch nicht gewappnet ist..

    Mich stört eben am meisten, dass jedes Kind den Hash in ne Rainbowtable schmeissen kann...Ein SSL Paket ist da schon eher ne Herausforderung ;)

    "d0nUt" schrieb:

    man-in-the-middle und phising - naja, was soll ein script dagegen tun???

    Ich würde das Script dann aber nicht als "extrem sicher" bezeichnen, es ist keine Alternative zu SSL! Und "extrem sicher" suggeriert eben, dass man sich zurücklehnen kann und keine Angst haben braucht. Ich würde eher "besser als nix...aber nicht viel besser als nix" sagen. In Zeiten von Rainbowtables oder johnd sollte man es vermeiden gehashte Passwörter zu übertragen.
    Im Worst Case wurde vom man-in-the-middle dem Benutzer ein Login ohne hash -Funktion vorgelegt. Für den Benutzer nicht zu bemerken solange er nicht jedesmal den Source anguckt und das Passwort geht im Kartext zum Angreifer. Authentifizierung vom Server/Client würde da Abhilfe schaffen.

    "d0nUt" schrieb:

    BTW: Extreme Sicherheit gibt es nicht ;)
    Aber seit der Bildzeitung wissen wir, dass Schlagzeilen wie "Extreme Sicherheit" Klicks beschert

    Niveau? :wink:
  • ok danke

    Ich hab vor ne Userverwaltung mit Instant-Messaging zu erstellen nur so zum Ausprobieren von Ajax und als Basis für spätere Projekte.

    cookies würde ich gerne aussen vor lassen :)

    Ich kann also entweder die Komplette Anwendung auf einer geladenen Seite ablaufen lassen und vielleicht versuchen den Reload abzufangen. Wenn die Webanwendung aus mehreren Seiten besteht dann könnte ich das so versuchen:

    1. Beim Klick auf den Login-Button holt Javascript über einen asynchronen http-request den gehashten seed der gleichzeitig in DB gespeichert wird.
    Der Seed kann aus dem User-Agent+DateTime+RandomNumber generiert werden vlt so 50 Zeichen..
    2. Javascript hasht Passwort mit dem Seed und sendet einen normalen Post-Request (ohne Ajax) an den Server.
    3. auf dem Serverskript wird dann alles validiert und gegebenfalls ne neue Session für den User erstellt.

    Der Seed ist dann nur die Sekunden-Millisekunden gültig und jedes mal unterschiedlich ich glaub kaum das Angriffe bei einer ordentlich großen Zeichenanzahl über Rainbowtable realistisch sind..

    U.u. kann man ja noch überlegen über sha-1 zu codieren.
    Ich werde mal nen bisschen rumprobieren..
    ---
    What's the main difference between intelligence and ignorance?
    A: I don't know and I don't care!
  • "sebbonaut" schrieb:

    1. Beim Klick auf den Login-Button holt Javascript über einen asynchronen http-request den gehashten seed der gleichzeitig in DB gespeichert wird.
    Der Seed kann aus dem User-Agent+DateTime+RandomNumber generiert werden vlt so 50 Zeichen..
    2. Javascript hasht Passwort mit dem Seed und sendet einen normalen Post-Request (ohne Ajax) an den Server.


    Also ich bekomm den gehashten seed, mein browser versucht nun den hash per bruteforce zu knacken um den seed im Klartext an das Passwort anzuhängen?
    Mal im Ernst: Was will ich mit nem gehashten seed?
  • @sebbonaut
    also der sinn eines seeds ist es nicht, dass er jedes mal der selbe ist
    was bei einer kombi aus bestimmten statischen daten, der fall wäre
    benutz doch lieber meine generate_seed() aus dem wiki

    Quellcode

    1. function generate_seed($length) {
    2. $seed = "";
    3. for($i=0; $i<$length; $i++) {
    4. $array[1] = chr(rand(48,57));
    5. $array[2] = chr(rand(65,90));
    6. $array[3] = chr(rand(97,122));
    7. $seed .= $array[rand(1,3)];
    8. }
    9. return $seed;
    10. }


    @newb:
    wir setzen hier ja doppeltes hashing ein
    - server erzeugt seed hash
    - client erhält den seed hash
    - client hasht das eingegebene passwort
    - client erstellt einen neuen hash aus (seed-hash+passwort-hash)
    - server tut das selbe mit vorliegendem passwort hash und dem gesendeten seed-hash
  • OK danke für die Tipps!
    Das mit dem Seed stimmt macht keinen Sinn den zu hashen weil der sowieso elementar in Klartext übertragen wird.. Das Verfahren ist so für sich schon ziemlich gut und sicher für die einmalige Übertragung.
    Hab mich jetzt erstmal durch ein paar Beiträge zum Thema AJAX und Sicherheit gelesen und das größte Problem ist der lesbare und komplett manipulierbare Code auf Clientseite :-/ Das ist wie eine riesige Spielbibliothek die zum Cheaten einlädt.. Ich werde Ajax bzw. Javascript dann doch lieber nur für wenige gezielte visuelle Effekte einsetzen..

    Hier ein paar gute Links bezüglich Sicherheit:
    securityfocus.com/infocus/1868
    search400.techtarget.com/qna/0…2,sid3_gci1198365,00.html
    it-observer.com/articles/1062/ajax_security/
    ---
    What's the main difference between intelligence and ignorance?
    A: I don't know and I don't care!
  • komplett manipulierbare Code auf Clientseite :-/ Das ist wie eine riesige Spielbibliothek die zum Cheaten einlädt..


    Das ist aber jetzt nichts Ajax spezifisches.. Sondern betrifft generell Client seitige Scripte.

    Zur Sicherheit kann ich nur sagen: Es gilt das selbe wie bei anderen Applikationen. Es gibt viele Sachen die man falsch machen kann.. vlt bei Ajax im Moment mehr, da es noch wenig "gute" Beispiele gibt wie man es richtig macht. Aber jetzt so pauschalisiert zu behaupten Ajax wäre unsicher, halte ich für groben Unfug.

    Wenn das Server-Backend vernünftig programmiert ist (ich erinner an den schönen Satz: Don't trust any user input), dann habe ich da keine Sicherheitsbedenken.

    Just my 2 cents ;)
  • Hallo,

    mich würde an dieser Stelle interessieren, wie das mit einem "dauerhaften Login" über Sessions laufen würde.

    Über das PHP-Skript kloppe ich Name und md5-Passwort in die session und nu? brauch ich ne neue js-Funktion z.b. checkuser() die bei onload die session-vars abklopft und den loginhandler aufruft? hmhm..

    schwierig schwierig. kann mir jemand nen tipp geben?
    Gruss, Thally
  • Hallo erstmal!

    Sorry das ich diesen alten Beitrag rauskramen muss.

    Ich hab noch nicht so viel mit Ajax gemacht, darum dachte ich fragen kostet nichts:

    Und zwar funktioniert diese Anmeldevariante bei mir Perfekt - allerdings nur im Firefox.
    Im Internet Explorer verhält sich anderst - ist etwas bekannt das dieses Tutorial nicht
    mit dem IE 7 harmoniert?

    Grüße,

    lukas