Business Continuity Management & Desaster Recovery - Broken Authentication

Broken Authentication

Einleitung

Stellen Sie sich vor Sie wollen eine Messe besuchen (nehmen wir die CeBIT, die 2018 nach 33 Jahren geendet hat). Sie kaufen sich ein Ticket und werden bei einem Eingang kontrolliert (mittels QR Code). Sobald Sie im Messegelände sind, hinterfragt niemand mehr die Gültigkeit Ihres Tickets und die damit verbundene Legitimität. Noch deutlicher wird es, wenn Sie kein Ticket haben, aber zufällig jemand in der Halle vor dem Eingang ein Ticket verliert. Sie eignen es sich an, und können im Namen dieser Person alle Vorteile der Messe genießen. Umgelegt auf die digitale Welt bedeutet dies: fragen Sie sich einmal was passieren würde, wenn Hacker Ihren Zugang zu Amazon kapern würden? Diese Lektion befasst sich mit den Grundlagen von Sessions und den damit verbundenen Session-Token, Authentisierungsmechanismen, aber auch wie Man-in-the-Middle Attacken grundlegend funktionieren.

Passworte

Lassen Sie uns über Ihr Passwort reden … Auch wenn es vielleicht banal klingt, die meisten Attacken basieren auf dem Herausfinden von Passworten. Nachdem Sie in einem Masterstudium der Wirtschaftsinformatik sind, wissen Sie sicherlich über die grundlegenden Anforderungen an Passwörter Bescheid. Ich möchte sie daher zu einem kleinen Selbsttest einladen: Wenn Sie auf Ihrem Mobiltelefon ein Sperrmuster verwenden, wo beginnen Sie? Eine Studie von Marte Loge[29] zeigte, dass 44% aller Nutzer*innen links Oben beginnen, in Summe sogar 77% an einer der Ecken. Die folgende Abbildung zeigt die 6 häufigsten Entsperr-Muster.

die 6 häufigsten Entsperr-Muster nach Loge

Ähnlich wie bei Passworten ist die Hürde ein gutes Passwort zu verwenden meist schlicht unsere Vergesslichkeit. Wer kennt nicht die Situation, wenn man nach 3 Wochen Urlaub ins Büro kommt und das Passwort für seinen PC vergessen hat (das aber gottseidank zur Sicherheit auf einem Zettel unter der Tastatur klebt). Passwörter zu Zugängen, die man vielleicht nur einmal pro Jahr benötigt wird, man sich auch nicht merken. Eine Folge bei den vielen nötigen Passworten ist oft, dass diese mehrfach verwendet werden. Das ist für den Hacker natürlich ideal, da dann damit gleich mehrere Seiten kompromittiert sind. Tipps für gute Passwörter gibt unter anderem das BSI . Es wird aufgrund der großen Menge an verschiedenen Konten bei diversen Anbietern generell empfohlen einen geeigneten[30] Passwortmanager zu verwenden. Beispielhaft sei hier das frei verfügbare Tool KeePass[31] genannt. Ergänzend dazu wird bei kritischen Anwendungen immer die Verwendung von 2-Faktor-Authentisierung empfohlen. Aus der Sicht der Entwickler*innen gilt es in dem Zusammenhang auch einige Dinge zu beachten. So sollten Benutzer*innennamen niemals Case Sensitive (also „Admin“ und „admin“ sind unterschiedliche Nutzer*innen) sein. Ein weiterer Aspekt ist die Ausgabe der Fehlermeldungen bei falschen Eingaben. So deutet die Meldung „Falsches Passwort“ bereits auf die Eingabe eines gültigen Users hin. Weiters muss man sich über die Anzahl an ungültigen Logins Gedanken machen. Dies kann man beispielsweise durch automatische (steigende) Wartezeiten zwischen möglichen Logins erreichen. Vielleicht kennen Sie die Geschichte, wie das E-Mailaccount von Sarah Palin (damals Kandidatin für die US Präsidentschaft) gehackt wurde[32]. Um das Yahoo E-Mailkonto von Frau Palin abzusichern, gab es Sicherheitsabfragen: Die Frage lautete nach ihrem Geburtsdatum, dass netterweise in einem Wikipedia Artikel zu ihr auffindbar war. Zwei weitere Fragen betrafen ihre Postleitzahl und der Ort, an dem Sie Ihren Mann getroffen hat. Alle nötigen Informationen waren im Internet verfügbar, der Hack an sich würde eher unter Social Engineering fallen, aus Sicht der Authentifizierung ist ein System jedoch immer nur so sicher, wie das schwächste Glied, was in dem Fall der Mechanismus zum Zurücksetzen des Kennwortes war.

Passwortangriffe

Brute Force Attacke

Im Wesentlichen gibt es drei Varianten von Passwortangriffen. Bei der Brute Force (am ehesten noch mit „rohe Gewalt“ zu übersetzen) Methode nutzen Hacker meist bekannte oder einfach abzuleitende Benutzernamen in Kombination mit Standardpasswörtern. Gibt es im Unternehmen einen „Donald Duck“, so könnte der zugehörige Benutzername „dduck“ sein, oder „donald.duck“. Namen lassen sich oft auf den offiziellen Webseiten der Firmen in Erfahrung bringen, womit Hacker schon die Hälfte des Weges geschafft haben. Kombiniert man diese Namen nun noch mit der Top 1000 Passwort-Liste, so ist ein Treffer sehr wahrscheinlich. Um dies in der Praxis zu Testen verwenden wir das frei verfügbare Tool „John the Ripper“ (Nerd Humor). Das dies auch eine Signatur für die Downloads bietet, machen wir hier einen kleinen Exkurs zur Verifizierung von Downloads. Sie können diesen Exkurs jedoch auch gerne überspringen, da er mit dem Kern der Vorlesung nichts zu tun hat.

Exkurs GnuPG

GnuPG[33] (PG steht für Privacy Guard) ist eine frei verfügbare Umsetzung des OpenPGP Standards wie er in RFC4880 beschrieben wurde. Man kann damit Daten oder Kommunikation verschlüsseln, so ist eine Integration in Outlook problemlos möglich. Kleopatra ist in Windows Umgebungen das grafische Front-End dazu.

Kleopatra Schlüssel generieren

Damit kann man einfach Schlüssel erzeugen und diese dann verteilen. Für den Fall „John the Ripper“ wollen wir deren Schlüssel importieren. Dazu laden wir den Offline Signing Key herunter und vergleichen dann den Fingerabdruck manuell:

Kleopatra Schlüssel generieren

Bei Übereinstimmung können wir davon ausgehen, dass die Installationsdateien nicht durch externe Malware kompromittiert wurde. Das Vertrauen beruht hierbei immer auf der Seriosität der Stelle, die die Schlüssel für vertrauenswürdig erklärt.

Starten wir nun John the Ripper und nehmen als Passwort . Als SHA1 Hash ist dies dann 7c4a8d09ca3762af61e59520943dc26494f8941b.

John the Ripper bei einfachem Passwort 123456

Ebenso verhält es sich für das Passwort „Donald“ (da249710d64d00223d25a097a3d98dee32297b32):

John the Ripper bei einfachem Passwort Donald

Kombiniert man nun die beiden Worte „Donald123456“ (6566af0d4043810d69702304c34fc4435c3a643b), so benötigt eine Brute Force Attacke ohne weitere Optimierungen schon sehr lange. Ein Abbruch nach 25 Minuten brachte noch kein Ergebnis:

John the Ripper Kombination einfacher Passwörter

Wörterbuchattacke

Bei der Wörterbuchattacke ist die Vorgehensweise ähnlich der eines Brute Force Angriffes, die Passwörter werden jedoch aus einem Wörterbuch genommen und gegebenenfalls miteinander kombiniert. Wortlisten kann man von vielen Quellen beziehen, manche sind länderspezifisch. Man spricht von der Entropie eines Passworts. Diese wird von der Menge der verwendeten Zeichen bestimmt. Sie kann durch die Verwendung von Groß- und Kleinbuchstaben, Ziffern sowie Sonderzeichen erweitert werden. Die Entropie eines Passworts besag also auch wie schwierig es ist ein Kennwort durch einen Wörterbuchangriff zu knacken. Die Angabe erfolgt meist in Form von Bits. Ein bereits bekanntes Passwort hat eine Entropie von 0 Bit. Die Entropie eines Passwortes kann berechnet werden, indem die Entropie für jedes verwendete Zeichen bestimmt wird. Für ein Kennwort mit einer Entropie von zum Beispiel 20 Bit werden 220 Versuche benötigt, um alle Möglichkeiten auszuprobieren. Die Anwendung solch einer Liste auf das Passwort „Donald123456“ ist dann wieder rasch erledigt:

John the Ripper Wörterbuchattacke

Key-Logger

Die dritte Variante, um Passworte herauszufinden sind Key-Logger – also Hard- oder Software, die Tastaturanschläge aufzeichnet. Diese Version der Passwortattacke ist besonders gefährlich, da auch starken Passwörter gegen diese Art des Angriffes nicht geschützt sind. Oft wird diese Attacke über Malware eingeschleust. Wirksamen Schutz bietet 2-Faktor Authentisierung.

Sessions

Eine Session (der deutsche Begriff „Sitzung“ wird in dem Kontext kaum verwendet) stellt zunächst eine simple Verbindung zwischen einem Server und einem Client dar. Der Beginn der Session stellt die Anmeldung dar, das Ende die (automatische) Abmeldung. Was simpel klingt ist technisch durchaus spannend.

Aufbau einer gesicherten Verbindung

Wir werden uns am Beispiel einer SSL Seite (amazon.de) im Detail ansehen wie eine sichere Verbindung aufgebaut wird. Streng genommen ist der Begriff SSL (Secure Sockets Layer) nichtmehr aktuell, denn die neuen Versionen des Protokolls laufen unter dem Namen TLS (Transport Layer Security), was auch gleich beantwortet auf welchem Stapel des TCP/IP Protokolls wir uns bewegen. Sie verwenden TLS vermutlich jeden Tag, wenn Sie im Internet surfen, denn HTTPS ist einer der prominentesten Vertreter des TLS Protokolls. Für Laien ist die gesicherte Verbindung je nach Browser an bestimmten Symbolen zu erkennen, in Chrome ist dies ein Schloss, dass geschlossen ist. Klickt man auf dieses Schloss, liefert der Browser Details über die zugrunde liegenden Zertifikate, wie folgende Abbildung zeigt.

Zertifikat von amazon.de

Die erste Seite zeigt die Gültigkeitsdauer und den Aussteller des Zertifikates. Spannender für uns ist aber die Detailseite, denn sie zeigt spezifische Informationen zum verwendeten Protokoll, wie die folgende Abbildung zeigt.

Spezifische Informationen zum amazon.de Zertifikat

Um zu sehen was genau passiert, müssen wir die Kommunikation zwischen dem Server (in dem Fall Amazon) und unserem Computer als Client genauer betrachten. Dazu benötigen wir einen Sniffer, also ein Tool, dass die Kommunikation in für uns nachvollziehbare Weise protokollieren kann. Wir wählen für dieses Studienheft das Tool Wireshark[34], da es frei Verfügbar ist. Sie können Wireshark einfach installieren und dann vor dem Aufruf der Seite amazon.de die Protokollierung starten. Das Bild wird in etwa aussehen wie die folgende Abbildung:

Ausgabe von Wireshark - Client Hello

Suchen Sie nun den ersten Eintrag, der „Client Hello“ als Text anzeigt. Lassen Sie sich in Wireshark die Paketdetails anzeigen und suchen sie dort die Zeile „Secure Sockets Layer“. Sehen wir es uns ein wenig detaillierter an:

Ausgabe von Wireshark - Client Hello

Es wird TLS 1.2 als Protokollversion verwendet, der Client bietet dem Server 19 verschiedene TLS Versionen zur weiteren Kommunikation an. So weit so gut, schauen wir uns an, was der Server antwortet. Dies finden wir in der Zeile „Server Hello“.

Ausgabe von Wireshark - Client Hello

Der Server ist mit der Protokollversion 1.2 zufrieden und hat sich („Cipher Suite“) eine bestimmte Suite aus dem Angebot ausgesucht. Der nächste Schritt wird nun die Übermittlung des Zertifikates vom Server an den Client sein. Dies ist quasi die Bescheinigung von einer unabhängigen Stelle, im Falle der Zertifikate die sogenannte Root Certificate Authority, dass das Zertifikat seine Ordnung hat. Ob der Browser der jeweiligen Root CA vertraut hängt davon ab, ob diese im Zertifikatspeicher hinterlegt sind. Um nicht bei mehreren Browsern unterschiedliche Root Cas zu erhalten beziehen sich die Browser auf das zugrundeliegende Betriebssystem, im Fall des Beispiels Microsoft Windows 10 . In letzter Instanz entscheidet also das Betriebssystem über gültige Root CA. In der für jeden einfach kontrollierbaren Fassung sieht der Pfad aus wie in der folgenden Abbildung:

Pfad der Zertifikate

In Wireshark suchen wir nach dem Begriff „Certificate“:

Wireshark Ausgabe des Zertifikates

Wir als Client befinden das jetzt für in Ordnung und wir erhalten vom Server den öffentlichen Schlüssel und die Signatur, dazu suchen wir die Zeile „Server Key Exchange“:

Details in Wireshark zum Zertifikat

Es werden offenbar Elliptical Curves verwendet (also EC), der Austausch erfolgt über den Diffie-Hellman Algorithmus, die Schlüssellänge ist 65. Parallel dazu gibt es die RSA Signatur die einen SHA256 Hash beinhaltet. Der Server ist nun mit seiner Aufgabe fertig, was wir in der Zeile „Server Hello Done“ sehen:

Wireshark Ausgabe zu Server Hello Done

Bitte beachten Sie, dass die Kommunikation bisher komplett unverschlüsselt erfolgt ist. Das ist letztlich auch das Problem, aus dem die öffentlich/privat Schlüsselstrukturen entstanden sind. Das Kernproblem war, über einen unverschlüsselten Kanal Schlüssel auszutauschen, die sonst niemand kennt. Der entscheidende Schritt folgt nun, denn der Client hat ja den öffentlichen Schlüssel des Servers erhalten und erstellt nun einen eindeutigen Session Key, den er mit diesem öffentlichen Schlüssel verschlüsselt. Es ist an der Stelle wichtig zu wissen, dass der Schlüssel nur vom Client und vom Server (der ja den privaten Schlüssel hat) entschlüsselt werden kann. Wie der Name schon sagt, gilt dieser Schlüssel auch nur für eine Session und muss danach neu ausgehandelt werden. In Wireshark suchen wir die Zeile „Client Key Exchange …“:

Wireshark Sicht zum Schlüsselaustausch

Die Zeile „Pubkey“ ist unser Session-Key. Letztlich senden Client und Server noch ein „Change Cipher Spec“ um die Gültigkeit der verschlüsselten Verbindung zu bestätigen.

Wireshark Change Cipher Spec

Zur Sicherheit schicken Client und Server noch eine bereits verschlüsselte Nachricht „Encrypted Handshake Message“ zur Kontrolle, danach erfolgt sämtliche Kommunikation verschlüsselt.

Wireshark Handshake

Sie sehen also, dass selbst der TLS Prozess einen Session Key zu generieren schon relativ viel Kommunikation voraussetzt. TLS ist jedoch ein guter Weg zu einem gültigen Session Key zu gelangen, ein entscheidender Faktor ist jedoch die Gültigkeitsdauer der Session. Stellen Sie sich vor, sie sind auf einer Europareise und buchen in einem Internetkaffee Ihr nächstes Hotel. Dazu steigen sie sie gesichert auf die Website des Buchungsportals ein, danach schließen Sie einfach den Browser. Sie wissen natürlich, dass dadurch der Session Key nicht automatisch gelöscht wird, auch wenn er meist nur im RAM des Computers gespeichert wird. Die nächste Person könnte jetzt den Browser öffnen und mit Ihren Daten eine eigene Buchung vornehmen. Eine weitere Schwachstelle ist die Weitergabe der Session IDs von Webanwendungen in der URL selbst. Jeder, der die URL einsehen kann, könnte dadurch sie Session ID missbräuchlich verwenden.

Open Authorization

Sie kennen sicher Anwendungen wie Online Shops oder Apps auf Mobiltelefonen, die eine Anmeldung via Amazon oder Facebook erlauben. Diese erlauben es, mit Ihrem – hoffentlich sicheren – Passwort auch dort direkt authentifiziert zu werden. In der Praxis (beispielsweise bei Amazon) wird dies über OAuth gelöst.

Anmeldung über ein Login-Portal wie Amazon

OAuth ist in der RFC 6749[35] detailliert beschrieben, zum Verständnis muss man vier wesentliche Rollen unterscheiden: Resource Owner Benutzer die Dritten den Zugriff auf geschützte Ressourcen gewähren können. Resource Server Der Server auf dem die geschützten Ressourcen liegen. Client Eine Anwendung, die auf geschützte Ressourcen des Resource Owners zugreifen möchte, die vom Resource Server bereitgestellt werden. Authorization Server Der Server authentifiziert den Resource Owner und stellt Access-Tokens für den vom Resource Owner erlaubten Anwendungsbereich (Scope) aus.

Eine sehr bildhafte Beschreibung eines Entwicklers aus den USA: How OAuth 2.0 works in real life:

I was driving by Olaf's bakery on my way to work when I saw the most delicious donut in the window -- I mean, the thing was dripping chocolatey goodness. So, I went inside and demanded "I must have that donut!". He said, "sure that will be $30."
Yeah, I know, $30 for one donut! It must be delicious! I reached for my wallet when suddenly I heard the chef yell "NO! No donut for you". I asked: why? He said he only accepts bank transfers.
Seriously? Yep, he was serious. I almost walked away right there, but then the donut called out to me: "Eat me, I'm delicious...". Who am I to disobey orders from a donut? I said ok.
He handed me a note with his name on it (the chef, not the donut): "Tell them Olaf sent you". His name was already on the note, so I don't know what the point of saying that was, but ok.
I drove an hour and a half to my bank. I handed the note to the teller; I told her Olaf sent me. She gave me one of those looks, the kind that says, "I can read".
She took my note, asked for my id, asked me how much money was ok to give him. I told her $30 dollars. She did some scribbling and handed me another note. This one had a bunch of numbers on it, I guessed that's how they keep track of the notes.
At that point I'm starving. I rushed out of there, an hour and a half later I was back, standing in front of Olaf with my note extended. He took it, looked it over and said, "I'll be back".
I thought he was getting my donut, but after 30 minutes I started to get suspicious. So, I asked the guy behind the counter "Where's Olaf?". He said, "He went to get money". "What do you mean?". "He take note to bank".
Huh... so Olaf took the note that the bank gave me and went back to the bank to get money out of my account. Since he had the note the bank gave me, the bank knew he was the guy I was talking about, and because I spoke with the bank, they knew to only give him $30.
It must have taken me a long time to figure that out because by the time I looked up, Olaf was standing in front of me finally handing me my donut. Before I left, I had to ask, "Olaf, did you always sell donuts this way?". "No, I used to do it different."
Huh. As I was walking back to my car my phone rang. I didn't bother answering, it was probably my job calling to fire me, my boss is such a ***. Besides, I was caught up thinking about the process I just went through.
I mean think about it: I was able to let Olaf take $30 out of my bank account without having to give him my account information. And I didn't have to worry that he would take out too much money because I already told the bank he was only allowed to take $30. And the bank knew he was the right guy because he had the note, they gave me to give to Olaf.
Ok, sure I would rather hand him $30 from my pocket. But now that he had that note I could just tell the bank to let him take $30 every week, then I could just show up at the bakery and I didn't have to go to the bank anymore. I could even order the donut by phone if I wanted to.
Of course, I'd never do that -- that donut was disgusting.
I wonder if this approach has broader applications. He mentioned this was his second approach, I could call it Olaf 2.0. Anyway, I better get home, I gotta start looking for a new job. But not before I get one of those strawberry shakes from that new place across town, I need something to wash away the taste of that donut. [36]

Der reale Ablauf ist dabei folgender:

1. Der Client fordert eine Autorisierung vom Resource Owner an. Diese Autorisierungsanforderung kann direkt erfolgen, wird aber bevorzugt indirekt über den Authorization Server durchgeführt.
2. Der Client erhält eine Autorisierungsgenehmigung vom Resource Owner. Die Autorisierung kann über einen der vier Autorisierungsgenehmigungen (authorisation grant types) erfolgen oder es wird ein erweiterter Genehmigungsprozess verwendet.
3. Der Client fordert einen Access-Token vom Authorization Server an. Hierfür nutzt er die Autorisierungsgenehmigung vom Resource Owner.
4. Der Authorization Server authentisiert den Client (permission to ask) und prüft die Autorisierungsgenehmigung des Resource Owners. Ist diese erfolgreich, stellt er einen Access-Token aus.
5. Der Client fragt die geschützten Daten beim Resource Server an. Zur Authentisierung benutzt er den Access-Token.
6. Der Resource Server prüft den Access-Token und stellt, wenn gültig, die gewünschten Daten zur Verfügung. [37]

OAuth Ablauf gemäß OAuth

OAuth-basierte Authentifizierung ist also ein Modell der Authentifizierung, das es Benutzern (Ressource Owner) ermöglicht, anderen Web/Mobilanwendungen (Client) den Zugriff auf ihre geschützten Ressourcen auf der Host-Website (Dienstanbieter) zu erlauben. Um sich einen Vorgang detaillierter anzusehen kann man Googles „Playground nutzen, dieser ist primär für Entwickler von OAuth Anwendungen gedacht.[37] Wir rufen also die Website auf und wählen die „Calendar“ API .

Google Playground zum Testen von OAuth

Ein Klick auf „Authorize API“ öffnen sofort ein Fenster zur Autorisierung.

Ein weiterer Klick zeigt d

Autorisierung über OAuth

ie Anfrage auf den Zugriff.

Sicherheitsabfrage zur Autorisierung der Anwendung via OAuth

In einer echten Anwendung würden nun die APIs ausgetauscht, in Google Playground wird man auf eine weitere Seite umgeleitet, die den Autorisierungscode anzeigt.

Autorisierungscode innerhalb von OAuth

Klickt man nun auf „Exchange authorization code for tokens“ erhält man einen Access Token und einen Refresh Token.

Accesstoken in OAuth

Die Verbindung ist nun hergestellt und man kann sich beispielsweise über den Button „List possible operations“ und „List Calendar List“ alle Kalender anzeigen lassen. Man kann hier gut erkennen, wie mächtig eine einmal getätigte Autorisierung ist. Im Bereich der Mobiltelefone sind viele Nutzer*innen schon auf das Hinterfragen der nötigen Berechtigungen sensibilisiert. So wird man einer Taschenlampen-App kaum Zugriff auf Kontaktdaten erlauben. Im Bereich von PCs hinterfragt man dennoch selten die Möglichkeiten die OAuth APIs bieten. Eine kurze Analyse von Wireshark zeigt dabei folgendes Bild für die „Client Hello“ Meldung:

Wireshark Sicht der Autorisierung

Da das Beispiel über Chrome als Browser aufgerufen wurde verwendet Chrome das eigene GQUIC (Google Quick UDP – eine Art Hybrid aus TCP und UDP) Protokoll zur Übertragung. Praxisbeispiel Als kleines Praxisbeispiel (vorausgesetzt Sie sind im Besitz eines Gmail Kontos) werden wir uns kurz ansehen welche Anwendungen und Geräte Zugriff haben. Dazu wechseln wir zu https://myaccount.google.com/security und klicken auf den Punkt „Zugriff von Drittanbietern verwalten“. Dort ist nun zumindest unsere Google Playground App gelandet. Sollten Sie WhatsApp nutzen, so werden Sie diese auch hier finden, denn die Sicherung läuft über GoogleDrive. 4.6 Schutz vor Broken Authentication Wir haben uns bisher einige mögliche Angriffsvektoren angesehen, wissen also wie ein möglicher Angreifer eindringen kann. Doch wie kann man sich nun dagegen schützen? Die Bestätigung der Identität des Benutzers, die Authentisierung und die Sitzungsverwaltung sind entscheidend für den Schutz vor authentisierungsbezogenen Angriffen. Anwendungen dürfen keine Standard-, schwachen oder bekannten Passwörter verwenden. Für „vergessene“ Passwörter müssen gesicherte Routinen vorhanden sein. Wissensbasierte Fragen und deren Antworten sind im Zeitalter von Social Media keine Absicherung mehr. Auch wenn es logisch erscheint, oft werden noch Nachrichten im Klartext versendet. Sessions müssen ordnungsgemäß ungültig gemacht werden. Dies gilt insbesondere für Single-Sign-On-Token. Wenn möglich sollte eine Multi-Faktor-Authentisierung verwendet werden. Es empfiehlt sich Passwörter zumindest gegen die Liste der 10000 schlechtesten Passwörter[38] zu prüfen und nicht zuzulassen. Weiters sollte man Anmeldeversuche durch zeitlich zunehmende Verzögerung oder Limitierung an fehlgeschlagenen Anmeldeversuchen beschränken. Fehler sollten protokolliert und automatisiert gemeldet werden, um Brute-Force oder andere Angriffe zu erkennen.

Multi-Faktor- Authentisierung

Bei der Multi-Faktor- Authentisierung handelt es sich lediglich um eine Verallgemeinerung der bekannten Zwei-Faktor Authentisierung. Man kann, muss aber nicht, mehr als zwei Faktoren verwenden. Zur Identitätsfeststellung können folgende Merkmale herangezogen werden:

• Etwas, das man besitzt (Mobiltelefon, Bankkarte),
• Etwas, das man weiß (Passwort, PIN),
• Ein biometrisches Merkmal, etwas was man „ist“ (Fingerabdruck, Stimme).

Meist kombiniert man Passworte mit Token, die man entweder an ein Mobiltelefon (TAN Codes beim Internet-Banking) schickt, oder die über spezielle Hardware generiert wird. Details zu den Verfahren liefert das BSI in seinem Grundschutzkatalog[30].

Hashing und Salt

Nachdem wir über Hash Funktionen gesprochen haben sehen wir uns diese an dieser Stelle ein wenig genauer an. Aus technischer Sicht ist eine Hashfunktion eine mathematische Abbildung einer Eingabemenge (Passwort) auf eine Zielmenge. Die HASH Funktion muss dabei drei grundlegende Eigenschaften aufweisen:

• Einweg-Eigenschaft (preimage resistance): Es ist praktisch unmöglich, zu einem gegebenen Ausgabewert y einen Eingabewert x zu finden, den die Hashfunktion auf y abbildet: h(x)=y.
• 2nd-Preimage-Eigenschaft und Kollisionsresistenz: Es ist praktisch unmöglich, für einen gegebenen Wert x einen davon verschiedenen Wert x’ zu finden, der denselben Hashwert ergibt: h(x)=h(x’) x ≠ x’.
• Starke Kollisionsresistenz (collision resistance): Es ist praktisch unmöglich, zwei verschiedene Eingabewerte x und x’ zu finden, die denselben Hashwert ergeben. Der Unterschied zur schwachen Kollisionsresistenz besteht darin, dass hier beide Eingabewerte x und x’ frei gewählt werden dürfen.

In der Praxis wäre x=“test“ mit MD5 als Hash Funktion h(test)= 098f6bcd4621d373cade4e832627b4f6 . MD5 gilt aktuell als nicht mehr sicher, da es mit vertretbarem Aufwand (schnelle CPUs oder GPUs) möglich ist, unterschiedliche Nachrichten zu erzeugen, die den gleichen MD5-Hashwert aufweisen. Um dem Vorzubeugen wurde „Salt“ eingeführt, die Brute-Force-Attacken oder Wörterbuchattacken deutlich erschweren. Dem eigentlichen Passwort im Klartext wird eine Menge an zufällig erzeugten Zeichen vorangestellt. „Zufällig“ bedeutet im Kontext der Kryptographie einen Zufallsgenerator, der auch wirklich zufällige Muster und keine pseudo-Zufallszahlen erzeugt (die sich beispielsweise aus einem Zeitstempel berechnen). Solche Zufallsgeneratoren heißen dann CSPRNG (cryptographically secure pseudo-random number generator). In php wäre eine Implementierung die Funktion openssl_random_pseudo_bytes[39]. Wir stellen also dem Passwort „test“ die zufällige Zeichenfolge „dfdfghbgh“ voran, es wird daraus also „dfdfghbghtest“. Als MD5 Hash ist dies: 050e6267673e21d82d3c3f857c287f07, ein Wert, der sich wie zu erwarten war, nicht mit dem obigen Wert deckt. Speziell bei mehreren Usern wird es vorkommen, das Passworte mehrfach vorkommen. Das Salt sorgt dann automatisch dafür, dass die Hash Werter der beiden identischen Passwörter trotzdem unterschiedlich ist. Auf der Serverseite kann man das Konzept in ähnlicher Form umsetzen, dort spricht man dann vom „Pepper“. Hier wird das Passwort meist mit einer für den Server eigenen Zeichenfolge ergänzt und der daraus entstehende Hashwert gespeichert. Um der modernen Rechenleistung und der damit verbundenen sinkenden Zeitdauer zum Hacken eines Hash-Algorithmus entgegenzuwirken veranstaltet die NIST regelmäßig Wettbewerbe für neue Algorithmen. Der letzte dieser Wettbewerbe war 2007[40] (der fertige Algorithmus wurde 2015 publiziert) und das Resultat daraus ist SHA-3[41]

Zusammenfassung

In dieser Lektion haben Sie die Grundlagen zu Broken Authentication kennengelernt. Sie können nun die Sicherheit von Passwörtern einordnen und kennen die Angriffsvektoren, um Passworte zu hacken. Weiters sind Sie mit dem Konzept der Open Authorization vertraut. Sie beherrschen das Konzept der Multi-Faktor-Authentisierung auch in der praktischen Anwendung. Zum Speichern von Passwörtern verstehen Sie das Konzept von Hashing und Salt.

Übungsbeispiele

Übungsbeispiel 4.1

Suchen Sie sich ein Passworttool Ihrer Wahl, das mit Hashfunktionen umgehen kann und versuchen Sie eines Ihrer alten Passworte berechnen zu lassen.

Übungsbeispiel 4.2

Sehen Sie sich das U2F (Universal Second Factor) Verfahren der FIDO Allianz[42] detaillierter an. Prüfen Sie gegebenenfalls den Einsatz in der Praxis anhand passender Hardware wie dem Yubikey Neo[43].

Übungsbeispiel 4.3

Wozu dienen OTP (One Time Pad) und was besagt in dem Zusammenhang das Kerckhoffsche Prinzip?