Sichere authentifizierung

[th_bone]

Hi,

ich brüte gerade darauf herum wie ich ein gesichertes Login
über das Internet zu meinem Server herstellen kann..

meine IDEE ist folgende

Server kennt: Name, Passwort, Privates Passwort

1. Der Client sendet Name offen an den Server
2. Server sendet eine Zufallszahl verschlüsselt mit dem Passwort an den Client
3. Client sendet die Zufallszahl mit dem privaten Passwort verschlüsselt zurück
4. wenn die übereinstimmung vorhanden ist, ist das Login erfolgreich

Frage: Ist dieser Ansatz so sicher oder habe ich etwas übersehen ?

Danke Ralf

[inherited]

wozu die beiden passwörter?

Client sendet 'wanttologin'
Server hat nur MD5-Hash des PW
Client Sendet sein MD5-Hash des eingegebenen PW.
Server vergleicht, wenn gleich, login ok, wenn nicht, dann nicht

[th_bone]

Hi,

dann braucht man als Angreifer doch eigentlich nur den MD5Hash abfangen und kann
sich dann ebenfalls einloggen... ist im grunde ja nichts anderes als wenn Du
das Passwort offen sendest der MD5Hash ändert sich ja nicht.

ich weiß ist zwar theoretisch, aber mir geht es ja darum wie man ein
sicheres login hinbekommt..

cu

Ralf

[Nikolas]

Eine Methode der digitalen Unterschrift läuft so ab: Du nimmst ein Verschlüsselungsverfahren mit Public/Private-Key.

Der User nimmt einen Text ('Hallo Server ich will Rein. Bob.) und verschlüsselt das mit seinem eigenen private Key. Dann nimmt er diesen verschlüsselten Text und verschlüsselt ihn nochmal mit dem public Key des Servers und schickt das dann weg.

Der Server bekommt das Teil und kann es als einziger lesen. Also macht er erstmal die Datei mit seinem eigenen Private Key auf. Dann nimmt er den public Key des Users und entschlüsselt die Datei. Wenn das Funktioniert und was sinnvolles drinsteht, weiss er, dass der Text nur von demjenigen erstellt wurde, der den Private Key von Bob hat.

Eigentlich reicht es auch Bob einfach nur einen Text mit seinem Private Key zu verschlüsseln und hinzuschicken. Die kann zwar dann jeder lesen, aber das stört ja auch nicht, da kein Passwort übermittelt wurde.

In dem Text der verschickt wird, sollte natürlich noch die Uhrzeit eingebacken sein, damit der Angreifer den Code nicht einfach mitschreibt und nachher benutzt. Oder der Server schickt offen eine Nachricht an Bob, die er doch bitte verschlüsseln soll.

Also das war vielleicht etwas verdeht, somit mein Vorschlag in Kurz:

Bob klopft an, Server schickt im offen irgendeinen schönen Text, Bob verschlüsselt ihn mit seinem private key und der Server öffnet sie einfach mit Bobs public Key. Das sollte dann ein sicheres Verfahren sein.

[Basilikum]

ich würde mich eher an CRAM-MD5 anlehnen (Vorteil: keine asymetrischen Schlüssel notwendig):

1. Server sendet Client eine Nonce (irgend etwas einmaliges, z.B. Server-Name + Zeit + Zufallszahl)
2. Client hängt sein Kennwort an die Nonce, berechnet davon einen Hash (z.B. SHA1) und sendet diesen zum Server
3. Server kennt seine Nonce und das korrekte Client-Kennwort -> er kann den Hash ebenfalls berechnen -> wenn identisch, ist der Client authentifiziert.

[gsh]

Zitat:

Zitat von Basilikum

ich würde mich eher an CRAM-MD5 anlehnen (Vorteil: keine asymetrischen Schlüssel notwendig):

1. Server sendet Client eine Nonce (irgend etwas einmaliges, z.B. Server-Name + Zeit + Zufallszahl)
2. Client hängt sein Kennwort an die Nonce, berechnet davon einen Hash (z.B. SHA1) und sendet diesen zum Server
3. Server kennt seine Nonce und das korrekte Client-Kennwort -> er kann den Hash ebenfalls berechnen -> wenn identisch, ist der Client authentifiziert.

hmm ja genau so wollte ich es auch vorschlagen aber dann hab ich den Post fertig gelesen und Basilikum war schneller als ich :(
naja aberwas ich noch sagen wollte für den Zufallswert brauchst du nicht sowas komliziertes wie z.B. Server-Name + Zeit + Zufallszahl sondern einfach sagen wir mal eine 10 stellige Zufallszahl ... mehr braucht man nicht.

Hab dieses System mal bei einem Chat von mir eingebaut und es funktioniert perfekt :thumb:

[Zacherl]

Bei Chats, bei denen lediglich ein Passwort von Server verlangt wird und es keine Benutzer ansich gibt, ist es sinnvoller alle gesendeten Commands mit dem Passwort zu verschlüsseln. Kann der Server den Befehl nun lesen, ist gut und er weiß, dass das Kennwort stimmen muss. Wenn nicht, wird das Passwort falsch gewesen sein.

Florian

[Nikolas]

Da ich mich nicht so mit modernen verschlüsselungsmethodenauskenne, wollte ich mal fragen, wie groß der geschwindigkeitsunterschied zwischen meiner und der Hash-Methode ist. Ich geh mal davon aus, das hashen schneller geht, aber kann das jemand bestätigen?

[jfheins]

Zitat:

Zitat von Toxman

Bob klopft an, Server schickt im offen irgendeinen schönen Text, Bob verschlüsselt ihn mit seinem private key und der Server öffnet sie einfach mit Bobs public Key. Das sollte dann ein sicheres Verfahren sein.

Ich glaube, du hast da was verwechselt ... das wäre nämlich total unsicher, wenn man mit dem public-Key entschlüsseln könnte ...

Der private-Key ist zum Entschlüsseln und darf nie nicht weitergegeben werden.

Der public-Key ist zum Verschlüsseln, und den darf jeder sehen.

Verschlüsseln kann also jeder, entschlüsseln nur der, der den private-Key hat, also idealerweise nur der Empfänger ;)

Bei einer sichern Kommunikation sendet also jeder seine Nachricht verschlüsselt mit dem public-Key des Gegenüber ;)

[Nikolas]

Nein, du hast das System nicht verstanden. Bei RSA z.B. kann man mit beiden schlüseln ent/verschlüsseln.

Hier geht es ja nicht darum, dass Bob was geheimes an den Server schickt, sondern, dass der Server weiss, dass nur Bob die Nachricht geschickt haben kann, denn er ist der einzige, der mit Bobs geheimen Schlüssel arbeiten kann. Bobs anfrage an den Server kann also von jedem gelesen werden, es ist aber sicher, dass er ihn geschickt hat.
Soll Bobs nachricht an den Server aber geheim bleiben, überschlüsselt er seinen Code noch mal mit dem Public des Servers.

[Chewie]

Das ist ja gerade das tolle an RSA:
Wird der private Schlüssel zum Entschlüsseln und der öffentliche Schlüssel zum Verschlüsseln verwendet, hat man eine Möglichkeit, sicher Daten auszutauschen.
Verwendet man dagegen den privaten Schlüssel zum Verschlüsseln und den öffentlichen Schlüssel zum Entschlüsseln, kann der Empfänger verifizieren, dass eine Nachricht wiorklich von dem vermuteten Absender kommt.
Und alles mit dem gleichen Verfahren. Das freut den, der das für eine Klausur lernen muss :D

[negaH]

Suche hier in der Codelib meinen SRP Code. Der liegt als DLLs vor und du kannst diesen frei verwenden. Darin ist alles schon fertig umgesetzt und du musst nur noch wenig anpassen.

Implementiert wird ein verbesserter SRP-6a Standard, Secure Remote Passwort Protocol, siehe http://srp.stanford.edu/

Vergiß sowas wie Zertifikate auf Basis von RSA oder ähnlichem Quatsch. So wie du dir das gedacht hast mit dem Benutzername+Passwort ist es schon absolut richtig. Alle Zertifikat basierten Systeme benötigen TrustCenter und externe Storage für die Schlüssel. Und WOMIT werden diese Schlüssel dann geschützt ? Ja mit einem Passwort das im Kopf gespeichert ist. Ergo: SRP kommt ohne diese Storage und TrustCenter aus und benutzt auch nur ein Passwort im Kopf. SRP gilt als ausgesprochen sicher, sicher als eine RSA, SSL, SSH Autentifizierung, besonders wenn es um Logins geht. Und üder die einfachen System mit Hashfunktionen etc.pp. brauchen wir erst garnicht reden. SRP ist resistent gegen alle bekannten Angriffsmuster, auch besonders gegen MITMA.

Gruß Hagen

[edit]
http://www.delphipraxis.net/internal...976&highlight=

Ich habe auch noch eine neuere Version, falls Interesse besteht.
[/edit]

[Nikolas]

Was hast du denn gegen die Methode per RSA? Die einzige Schwachstelle ist die Speicheung der Private Keys und darum wirst du mit keinem Verfahren rumkommen. Man müsste zwar auch die Public Keys der Nutzer speichern um von einem Trustcenter wegzukommen, aber wenn man den eigenen private schützen kann, sollten die anderen Schlüssel auch kein Problem darstellen.

[negaH]

Doch mit SRP muß man auf Clientseite eben NICHTS speichern, es ist ein Password based Protocoll, und kein Certificate based Protocoll.

Je nachdem wie die Schlüssel für RSA erzeugt wurden ist, bzw. kann RSA sehr unsicher sein.
In den meisten Fällen gibt es 3 Methoden für die Erzeugung eines RSA Schlüselpaares

1.) TrustCenter
2.) einbruchsichere Hardware wie SmartCards, FritzChip
3.) Windows Crypto API

In allen drei Fällen haben wir defakto keinerlei Kontrolle über den Schlüssel-Erzeugungsprozess. Da aber RSA Sicherheit gerade auf der Geheimhaltung der Schlüssel basiert und bisher es keinen mathmatischen sicheren Standard gibt die Korrektheit dieser Schlüsselerzeugung zu verifizieren ergibt sich folgendes Bild:

Mit einer abgewandelten Form der RSA Schlüsselerzeugung ist es möglich für denjenigen der diesen Prozess real kontrolliert diese Schlüssel schneller zu brechen als dies normalerweise notwendig wäre bei einer Faktorization. Das Dumme daran oder eben auch Geniale (je wie man es betrachtet) ist es das man mathem. beweisen kann das solche geschummelten Schlüssel zu beweisen/entdecken exakt genausso schwierig ist wie die Faktorization eines RSA Schlüssel. Im Klartext: ein TrustCenter oder SmartCard Hersteller oder CryptoAPI Sofwtarehersteller hat die Möglichkeit die Schlüsselerzeugung so zu verändern das er
1.) jeden Schlüssel nur anhand des public Parts brechen kann, weitaus schneller als normal
2.) diese erzeugten Schlüssel und ihr verdeckter Kanal zum schnellen brechen so sicher ist wie das RSA Problem selber. Das heist das ein Anwender solcher Schlüssel nicht praktisch in der Lage ist solche Schlüssel zu entdecken.
3.) die erzeugten Schlüssel ansonsten praktisch identisch zu normalen RSA Schlüsseln sind, sie sind also mathmatisch korrekt

Aus der Sicherheit für einen Anwender wird somit defakto eine Unsicherheit und er kann noch nichtmal wissen ob es an dem ist, und das ist wiederum mathem. beweisbar und es kann bewiesen werden das diese Entdeckung genauso schwierig ist wie eine Faktorization.

RSA ist nur dann sicher wenn man die 100%'tige Kontrolle über die Erzeugung der Schlüssel hat.

Und wenn du nun nach praktischen Beweisen suchst dann lade mein DEC Version 5.1c das so ein Verfahren demonstriert. Übrigens eine Eigenentwicklung von mir. Ich betone das weil ich einfach weiß das ich eine Null im Vergleich zu den vielen Experten darstelle und wenn ich sowas entwickeln kann dann erst recht die Überflieger die für TrustCenter, SmartCard Hersteller oder Mircosoft arbeiten. (übrigens gibt es mindestens ein Patent das exakt so ein RSA Verfahren anmeldet, ob es nach meiner Methode arbeitet weis ich aber nicht).

Diese Problematik lässt sich auf alle Verfahren die mit dem Faktorizationsproblem arbeiten übertragen. Probleme die auf dem Logarithmus beruhen sind davon nicht betroffen. Deren Geheimnis sind im Normalfalle purer Zufallsdaten und somit sind alle sicherheitsrelevanten Parameter jederzeit im Protokoll auch public verifizierbar. Das ist ein enormer Unterschied und der Hauptgrund dafür das ich immer wieder System wie die Elliptischen Kurven in GF(p), ElGamal oder den Diffie Hellman Keyexchange empfehle. Und SRP beruht auf dem Diffie Hellman Schlüsselaustausch.

Gruß Hagen

[th_bone]

Hi,

erst mal Danke für all die interessanten Anworten...

Den RSA ansatz fand ich persönlich für mich zu kompliziert hatte mir mal testweise einen SSL Server gebaut.

@negaH: Dein SRP sieht sehr interessant aus... was hälst Du eigentlich von der CRAM-MD5 Methode ? hört sich für
mich auch recht einfach und sicher an ?

(ich habe mal für diejenigen die Indy 10 nutzen dein Testprojekt für Indy 10 angepasst und angehängt)

Danke

Ralf

[Phoenix]

Zitat:

Zitat von Florian Bernd

ist es sinnvoller alle gesendeten Commands mit dem Passwort zu verschlüsseln

... und damit einem Angreifer möglichst noch mehr Schlüsseltext zu geben den er Auswerten kann.
Je mehr Schlüsseltext, vor allem wenn viele gleiche Kommandos vorkommen, desto einfacher ist ein Angriff auf das Passwort. Das ist also eine ganz schlechte Idee.

[negaH]

Von CRAM-MD5 halte ich nicht viel. Eine MITMA, Man in the Midle Attack ist nicht ausgeschlossen noch überhaupt notwendig um die anschließende Komunikation zu belauschen. Denn diese ist ja im CRAM-MD5 STandard ja garnicht verschlüsselt. Eine Brute Force Attacke auf das Clientpassword ist ebenfalls nicht ausgeschlossen, denn alle Daten dafür stehen während einer Loginkommunikation zur Verfügung. Ein Verlust der Clientdatenbank auf dem Server kann ebenfalls für Offline Brute Force Angriffe benutzt werden. Desweiteren is CRAM-MD5 nur eine einseitige Authentifikation, der Server muß sich zb. nicht vor dem Client authentifizieren. Das ist eine enorme Lücke für MITMA Server Replacements Angriffe. CRAM-MD5 ist ein 3 Step Protokoll, im Gegensatz zu SRP das mathematisch gesehen ein 5 Step Protokoll ist. Das ist wichtig da bei diesen Steps immer nur Teilinformationen, die die vorherigen Steps aber benötigen, ausgetauscht werden.

All dies ist beim SRP ausgeschlossen, bzw. so schwierig das es praktisch nicht durchführbar ist. SRP ist ein sehr aktuelles Protokoll und setzt sich immer weiter durch. Immer mehr Standard Bibliotheken integrieren es in ihre APIs.

SRP benutzt intern ein modifiziertes Diffie Hellman Protokoll, arbeitet also mit einem mathematischen Zero Knownledge Verfahren. Nach einer erfolgreichen Authentifikation von Client beim Server und Server zum Client wurde autom. ein Shared Secret -> gemeinsammer Schlüssel berechnet. Mit diesem One Time Schlüssel, der zufällig gewählt ist, wird die nachfolgende Kommunikation verschlüsselt. Somit ist SRP nicht nur ein Passwort basiertes Authentifikations Protokoll sondern zusätzlich noch ein sicheres Schlüssel-Austausch-Protokoll. Wobei man das Wort "Austausch" nicht falsch verstehen sollte (kommt von Keyexchange), denn real einigen sich nur beide per mathematik auf ein und den selben Schlüssel ohne diesen real über eine Kommunikation austauschen zu müssen. Dh. dieser Schlüssel wird niemals übertragen und kann somit auch nicht von einem Lauscher abgehört werden.
Ein wichtiger Vorteil meiner SRP Version ist es das die Daten die kommuniziert werden keinerlei direkten Zusammenhang zu den berechneten Daten auf Client/Server seite haben. Somit ist sichergestellt das ein Lauscher nichts erfährt. Desweiteren sind die Clients in der Server Datenbank vollständig anonym. Ein Diebstahl dieser Datenbank durch Dritte wird nicht die Clients kompromittieren, im Gegenteil ist es sogar so das falls dieser sehr unwahrscheinliche Fall eingetreten ist und zudem noch der sehr sehr sehr unwahrscheinliche Fall das ein Hacker sich als regulärer Client ausgegeben hat, dann kann der reguläre Client dies autm. beim nächsten Login erkennen. Entweder er bekommt garkeinen Zugriff mehr, meil der Hacker sein eigenes Passwort benutzt hat, oder aber er sieht an Hand eines Counters das sich ein Anderer in der Zwischenzeit eingeloggt hat. Das und die Möglichkeit beim Counter-SRP zu jeder Zeit das Passwort zu wechseln ohne das dies der Server registrieren kann sind zwei ganz wesentliche Vorteile vom Counter-SRP zum original SRP-6a. Dh. selbst der Server wird quasi als Angreifer in meinem Protokoll betrachtet und das Protokoll weitestgehend auf diese Möglichkeit hin optimiert. Der Client kann anonym sein und die Sicherheit seiner Datensätze in der Serverdatenbank "verifizieren". Naja und dann noch die vielen anderen Angriffe, besonders solche die interleaved arbeiten werden ja schon vom SRP6a ausgeschlossen.
SRP ist meiner Meinung nach (und da bin ich nicht der Einzigste) als das bisher sicherste Login Protokoll betrachtet. Schau einfach mal in die sci.crypt Newsgroup rein.

Es gibt defakto nur EINE Angriffstelle, und das ist die Registration eines neuen Clients im Server. Diese Angriffsstelle existiert in jedem Protokoll, sofern dieses nicht über TrustCenter arbeitet das mit einer persönlichen Gegenüberstellung des potentiellen Clients beim TrustCenter arbeitet, zb. Ausweis bei der Deutschen Post vorzeigen usw. Aber auch an dieser Stelle habe ich in meinem SRP einige Protokolländerungen vorgenommen. Zb. kann ein Client erstmal als vorläufiger Registrations Datensatz durch den Server angelegt werden (der natürlich nicht alle Zugriffsrechte erhalten wird). Das ist möglich weil der Server ein zufälliges Registrationspasswort für den Client anlegen kann und mein Counter-SRP ja in jedem Login die Möglichkeit hat transparent und unbemerkbar für den Server ein neues Passwort zu wählen. Das ist so in SRP-6a nicht möglich, ein Clientdatensatz ist immer unveränderlich, readonly, und beim Counter-SRP wird bei jedem Login dieser Datensatz verändert (könnte Datenbankbezogen aber auch ein Problem darstellen).

Ich habe wie gesagt noch eine neuere Version hier rumliegen. Sie wurde primär auf Geschwindigkeit hin optimiert. Immerhin führt sie alle SRP Schritte ca. 16 mal schneller durch. Die Gesamtzeit eines SRP Logins dauert ca. 15 Millisekunden. Desweiteren bastle ich noch an einem SRP das in Elliptischen Kurven in GF(p) arbeitet. Dies wird den nötigen Datentraffic/Datenbankgrößen/Clientdatengrößen um das 3 bis 4 fache reduzieren, bei gleicher Sicherheit wohlgemerkt.

Gruß Hagen

[negaH]

Zitat:

.. und damit einem Angreifer möglichst noch mehr Schlüsseltext zu geben den er Auswerten kann.
Je mehr Schlüsseltext, vor allem wenn viele gleiche Kommandos vorkommen, desto einfacher ist ein Angriff auf das Passwort. Das ist also eine ganz schlechte Idee.

Sehr gutes Argument ;) Beim Counter-SRP wird nachdem der sichere Schlüssel auf beiden Seiten berechnet wurde mit diesem die komplette Kommunikation verschlüsselt. Die Methoden .Encrypt() und .Decrypt() verschlüsseln nun diese Daten vor der Komunikation (AES und 256Bit Schlüssel). Um nun spezielle Angriffe auf Grund der benutzten Daten im eigenen TCP/IP Protokoll auszuschließen benutzt mein SRP 1.) einen sicheren Feedback Modus und 2.) bei jedem Aufruf dieser Methoden wird ein Zufalls-Salt benutzt um diese Daten zu randomisieren. Dh. zwei gleiche Kommandos nacheinander mit .Encrypt() und gleichen Sessionkey verschlüsselt würden denoch komplett unterschiedliche verschlüsselte Datenpackete erzeugen. Angriffe wie Known Plaintext Attacks, diffentielle Kryptoanalyse sind damit unterbunden.

Wichtig ist eben eines: Alle Stellen im Protokoll müssen imer für sich betrachtet werden und auf mathematisch beweisbare Sicherheit konstruiert werden. Und vom Client und dessen Daten übers INet hin zum Server in dessen Datenbanken ist es ein langer Weg der viele Angriffe ermöglicht.

Die niedrigste und garantierte Sicherheit beim Counter-SRP beträgt 256 Bit. Das heist in allen Protokollschritte und Datenbankdaten wäre eine Brute Force Attacke die einzigste Möglichkeit irgendwas zu knacken. Der Aufwand beträgt dann das Durchprobieren von 2^256 möglichen Kombinationen. Wichtig dabei ist das spezielle Optimierungen dieser Angriffe wie Dictionary/Wörterbuchangriffe oder Rainbow-Tables ausgeschlossen sind !
256Bit ist das doppelte der heutzutage als sicher angesehenen Größe von 128 Bit, das ist also 2^128 mal komplizierter als heute eh schon als sicher angesehen.

[edit]
Fast vergessen: nicht zu unterschätzen ist das Argument das SRP frei verwendet werden darf und ansonsten alle benutzten math. Hilfsmittel eh frei und unpatentierbar sind. "Frei verwendbar" bezieht sich natürlich nicht auf Staatliche Verbote Kryptographie benutzen zu können, wie in France ;)

[/edit]

Gruß Hagen