Blicke auf: Authentifzierung 1


Es ist geplant, dass ich euch auch Blicke unter die Haube von HackThatWeb gebe. Dieser Artikel witmet sich den Loginverfahren im Detail und erklärt ein paar Sachen, die ich eingebaut habe, um „echten“ Hackern die Lust zu nehmen und euch den Spaß bei voller Sicherheit zu geben.
Übrigens: Alles, was ich in diesem Beitrag erläutere, ist bereits implementiert.

MG0-Geräte
Vom Namen her könnte man auf die Idee kommen, dass diese Geräte etwas mit den aus der Waffenindustrie bekannten Maschinengewehren zu tun haben, jedoch sind sie bei weitem nicht so gefährlich. Die Bezeichnung MG0 sagt eigentlich nur, dass es ein Manuelles Gerät der „Klassifizierung“ 0 ist – oder, noch mal vereinfacht, es ist ein Gerät, hinter dem ein Benutzer steht. In der Regel ist das euer Browser, sprich Firefox, Chrome, Opera und so weiter.
Als Entwickler muss ich euch irgendwie identifizieren können, damit ich zwischen dem Firefox-Browser von Torben und dem Chrome-Browser von Alexander (Dummy-Daten) unterscheiden kann. Dazu gebe ich ihnen einzigartige Kennungen, genannt UUIDs („Universally Unique Identifier“), und speichere diese als Cookies.
Eine UUID sieht in etwa so aus: c7091e1c-19a2-4ee3-a542-804a5f1560b5. Und in meiner Datenbank steht dann, dass in diesem Gerät gerade der Benutzer Andreas eingeloggt ist. Um zu verhindern, dass sich Torben einfach den Code von Andreas kopiert, signiere ich das natürlich noch beim ersten Setzen, speichere das in einem weiteren Cookie, der das „HttpOnly“-Flag hat (bedeutet: man kann ihn im Clienten nicht über Scripte auslesen).
Das mag auf Anhieb zwar sehr kompliziert klingen („Warum nicht einfach die Logindaten als Cookie setzen?“), hat aber sehr große Vorteile

  • ihr könnt sehen, auf welchen Geräten ihr gerade eingeloggt seid (habe ich mich beim heimlichen Spielen im Informatik-Unterricht ausgeloggt?)
  • ihr könnt tracken, wann ein Gerät, auf dem ihr aktuell eingeloggt seid, zuletzt online war (spielt meine kleine Schwester schon wieder heimlich mit meinem Account?)
  • es werden keine Logindaten auf eurem Rechner gespeichert (sprich: selbst, wenn ihr einen Virus habt, euer Passwort ist nicht einsehbar)
  • … und sicher noch andere, die mir gerade nicht einfallen.

Die beiden Cookies werden bei jeder Anfrage, die ihr an den Loginserver schickt, überprüft, ein Übernehmen eurer Session ist nahezu unmöglich (da man den wichtigsten Cookie nicht auslesen kann) und egal, was passiert – euer Passwort ist sicher.

TLS
TLS bedeutet – eure Verbindung ist sicher. Wer das gerade eben gelesene hinterfragt, kommt sehr schnell zu dem Schluss, dass man über Man-in-the-middle-Attacken (ab jetzt: MITM) an alle Daten kommen könnte, die ihr meine Server sendet – also sowohl an die Passwörter, als auch diese geheimen Cookies. Falsch gedacht, davor schützt TLS – es verschlüsselt eure Daten mit einem Verschlüsselungspasswort, sendet sie dann an mich, nur ich kenne das Entschlüsselungspasswort und nur ich kann sie lesen. (Anmerkung: das ist nur die halbe Wahrheit. CloudFlare sitzt dazwischen und prüft, dass ihr keine Viren an mich sendet und ich keine Viren an euch sende. Doch selbst dann ist euer Passwort sicher, lest gespannt weiter)

MD5
a.k.a. Message-Digest Algorithm 5. Was das bedeutet? In meinem vorherigen Insider-Bericht als Entwickler von HTW habe ich es schon grob umrissen – es ist so etwas wie eine Einwegfunktion. Man kann aus der einen Sache eine andere machen, es aber nicht rückgängig machen. Die Teile nennt man auch „Hash“. Ich zitiere mich mal selber: Technische Erklärung, was ein „hash“ ist: man stelle sich vor, man möchte eine Dose hashen. Also schmilzt man sie und speichert die chemische Zusammensetzung ein. Sollte jemand an die chemische Zusammensetzung kommen, kann er nicht sagen, was es war; es könnte eine Motorhaube gewesen sein, es könnte irgendwas anderes aus Dosenmaterial gewesen sein oder eben eine Dose. Wer sich nun fragt, was ich mit diesen Dosen sagen möchte – das ist euer Passwort. Wenn ihr das eintippt, wird es geschmolzen. Diese geschmolzene Brühe wird an mich gesendet, ich mache damit auch noch ein paar Sachen, um Schwachstellen von MD5 zu umgehen (wen es interessiert: einen Salt ranhängen und SHA1 um Brute-Force-Attacken mittels Rainbowtables zu umgehen). Bei der Registrierung habe ich das mit eurem Dosenbrei gemacht und das Ergebnis gespeichert. Wenn ihr euch einloggt, mache ich das noch mal und überprüfe, ob das Ergebnis eurer Eingabe mit dem Ergebnis in der Datenbank übereinstimmt. Wenn ja, seid ihr eingeloggt.

Authentifizierungstoken
Solltet ihr eingeloggt sein, wird der LoginServer für euch einen „Authentifizierungstoken“ generieren. Der ist (indirekt!) dafür da, dass ihr euch auch an anderen Teilen von HTW einloggen könnt, zum Beispiel auf einem Spieleserver. Die Teile sind super lang und folgen einem speziellen Muster, das ich für euch mal aus meiner technischen Dokumentation kopiert habe, falls es euch interessiert – ich bin ein Link (Typ: PDF, 40kb). Je nachdem, was ihr also plant, fragt euer Browser zuerst einen Token an, wendet sich an die entsprechende Schnittstelle auf meinem System, diese überprüft den Token, indem sie eine Anfrage an die API-Server (https://api.hackthatweb.de/{token}/) sendet, dann bekommt der Browser seine Antwort (oder eben keine, wenn der Token falsch ist/keine Berechtigung hat/abgelaufen ist/…). 04. April 2016: Die Teile sind noch nicht ganz implementiert, es fehlen noch ein paar Sachen.

Login bei Drittanbietern
Auch dies wird es wieder geben und wieder mit einem System, was irgendwie an OAuth angelehnt ist aber auch irgendwie anders ist. Es läuft wieder so ab, dass die Seiten von Drittanbietern euch an eine spezielle Seite weiterleiten, dort dann wieder gesagt wird, was der Anbieter genau möchte, ihr klickt dann „Ja“ oder „Nein“, ihr werdet an den Anbieter zurückgeleitet und der bekommt je nachdem, wie gnädig ihr seid, einen Authentifizierungstoken. Mit dem kann er dann machen, was auch immer ihr im erlaubt habt.
Dieses mal ändert sich jedoch etwas – es gibt Abstufungen mit den Berechtigungen, nicht jeder Entwickler darf von Anfang an alles anfragen. Was im Detail das bedeutet, erkläre ich euch dann aber in einem anderen „Blicke auf“-Teil ^-^

Das wars dann auch mal wieder von mir. Vielen Dank für das Lesen und wir sehen uns, wenn es euch gefallen hat, eventuell dem nächsten Teil wieder 🙂


Ein Gedanke zu “Blicke auf: Authentifzierung

Kommentare geschlossen.