Extrem sicherer AJAX Login

Administrator

Monday, August 28th 2006, 1:43pm

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:
http://www.webthreads.de/2006/08/login-abfrage-via-ajax/
http://ajaxpatterns.org/Direct_Login

Quoted

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.

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

Blue

Intermediate

Posts: 150

2

Wednesday, August 30th 2006, 1:22am

Hmm, sowas ist immer sehr nützlich. Habe mich letztens ein wenig mit PHP Hacking beschäftigt und mir ist aufgefallen, das meine momentanen Scripts total unsicher gegenüber Angriffe sind *döpdedöö*

Torben Brodt

Administrator

Posts: 8,454

3

Monday, September 4th 2006, 10:07pm

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:
Ajax Sicherer Hash Seed Login

Torben Brodt has attached the following files:

md5.js (8.57 kB - 739 times downloaded - latest: May 21st 2012, 10:38pm)
sicherer-ajax-login.zip (5.41 kB - 970 times downloaded - latest: May 20th 2012, 9:51am)

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

newb

Intermediate

Posts: 89

4

Tuesday, September 5th 2006, 1:09am

"extrem sicher" würd ich das nicht nennen.
Das Passwort bekommt man immernoch durch Bruteforce auf Hash+Token oder "phishing", da die Daten vom Browser nicht authentifiziert werden können.
Den Rest der Verbindung liest man ja eh im Klartext.
Was sollte eine Firma gegen SSL haben?

Torben Brodt

Administrator

Posts: 8,454

5

Tuesday, September 5th 2006, 11:28am

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

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

sebbonaut

Beginner

Posts: 5

6

Tuesday, September 19th 2006, 10:05am

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

Torben Brodt

Administrator

Posts: 8,454

7

Tuesday, September 19th 2006, 10:41am

hi,

willkommen bei easy-coding
ja, korrekt - in der implementierung hält der login nur für einen refresh. Im Idealfall holst du dir regelmäßig neue Tokens nach und hasht deine Passwort damit jedesmal neu.

kommt ganz auf die anwendung an

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

newb

Intermediate

Posts: 89

8

Tuesday, September 19th 2006, 12:19pm

Quoted from ""d0nUt""

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

Quoted from ""d0nUt""

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.

Quoted from ""d0nUt""

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

Niveau? :wink:

sebbonaut

Beginner

Posts: 5

9

Tuesday, September 19th 2006, 12:27pm

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

newb

Intermediate

Posts: 89

10

Tuesday, September 19th 2006, 1:22pm

Quoted from ""sebbonaut""

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?

Torben Brodt

Administrator

Posts: 8,454

11

Tuesday, September 19th 2006, 2:20pm

@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

PHP Quellcode

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

@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

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

newb

Intermediate

Posts: 89

12

Tuesday, September 19th 2006, 2:54pm

Vielleicht übersehe ich irgendwas...aber mir fällt kein Grund ein warum man den Seed als Hash übertragen sollte.

Casper

Trainee

Posts: 10

13

Tuesday, September 19th 2006, 9:51pm

Falls jemand statt MD5 lieber SHA1 benutzen möchte:

http://pajhome.org.uk/crypt/md5/sha1src.html

Hier noch ein Link zu einem Wikipedia-Artikel, bei dem auch nochmal erklärt wird wie die Authentifizierung von statten geht: CHAP

Gruß

Casper

sebbonaut

Beginner

Posts: 5

14

Wednesday, September 20th 2006, 1:54am

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:
http://www.securityfocus.com/infocus/1868
http://search400.techtarget.com/qna/0,28…1198365,00.html
http://www.it-observer.com/articles/1062/ajax_security/

Casper

Trainee

Posts: 10

15

Wednesday, September 20th 2006, 3:20pm

Quoted

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

thally

Beginner

Posts: 1

16

Wednesday, October 11th 2006, 4:52pm

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?

lukas

Beginner

Posts: 2

17

Sunday, January 13th 2008, 8:14pm

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

Torben Brodt

Administrator

Posts: 8,454

18

Sunday, January 13th 2008, 8:32pm

Ach herje, ein riesen Danke an dich! Ich hatte vergessen, dass ich mal so jung angefangen habe!
Es sind zwar glücklichweise keine Fehler, die das Script unsicher machen, aber dafür sind es doch so einige in der Anzahl!

Schau im Wiki, da findest du eine runderneuerte login.html (ungetestet mit IE7 - bitte um Feedback)

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung