Login-System für lokale Anwendung
wucher wichtel
- programmiertechnik
Hallo!
Ich habe eine Anwendung in C#.NET geschrieben, die nur für bestimmte Leute zugänglich sein soll. Deswegen würde ich gerne die Anwendung durch verschiedene Passwörter für verschiedene User schützen. Dabei soll das Programm sich mit dem Benutzernamen und dem Passwort auch auf einem FTP-Server einloggen und dort Daten ablegen bzw. downloaden können.
Auf folgende Lösung wäre ich gekommen. Allerdings bin ich mir überhaupt nicht sicher, ob sie sicher ist: Wäre es eine Lösung einen String, der auf dem Server und im kompilierten Programm bekannt ist, an den Password-String anzuhängen und dann mittels einer Hash-Funktion die zwei Sachen umzuwandeln?
Dann stellt sich für mich die Frage, wie ich die Daten sicher auf dem Computer des Anwenders speichern kann. Warscheinlich bietet sich dazu die Registry an, oder? Aber wie speichern, damit es nicht einfach ausgelesen werden kann?
Vielen Dank für eure Hilfe!
ciao, Lukas
Moin Moin!
Passworte speicherst Du -- egal ob local oder remote -- als Hashwert, vorzugsweise mit einem "salt" genannten Zufallswert, der bei identischen Passworten identische Hash-Werte vermeidet. Die Passwort-Abfrage ist dann, den "salt"-Wert und das eingegebene Passwort ebenfalls durch die Hash-Funktion zu jagen und das Ergebnis mit dem Hashwert in der Datenbank zu vergleichen.
MD4 und MD5 sind als geknackt anzusehen, SHA-1 ebenfalls. 3DES müßte ich mal suchen. SHA-256 gilt noch als sicher.
Den Zugang zum FTP-Server aus der Anwendung heraus könntest Du durch SSH/SCP/SFTP ersetzen und auf jeden Client einen Public Key verteilen. Die entsprechenden Private Keys kannst Du bei Bedarf auf dem Server sperren, womit der Zugang unmöglich wird.
Es wäre auch möglich, den Zugang zur Applikation nur dann zu erlauben, wenn das Login am FTP-Server klappt. Damit entfiele die notwendigkeit, auf dem Client irgendwelche Zugangsdaten zu speichern.
Verstecken der Zugangsdaten in irgendwelchen ominösen Dateien oder auf der großen Windows-Müllhalde genannt Registry ist Security by Obscurity, das hat noch nie gut funktioniert.
Alexander
Hallo!
MD4 und MD5 sind als geknackt anzusehen, SHA-1 ebenfalls. 3DES müßte ich mal suchen. SHA-256 gilt noch als sicher.
Oh, ok. Das wusste ich noch nicht.
Den Zugang zum FTP-Server aus der Anwendung heraus könntest Du durch SSH/SCP/SFTP ersetzen und auf jeden Client einen Public Key verteilen. Die entsprechenden Private Keys kannst Du bei Bedarf auf dem Server sperren, womit der Zugang unmöglich wird.
Da hab' ich zwar noch keine Ahnung wie Public und Private-Keys funktionieren, aber da finde ich sicherlich was dazu.
Es wäre auch möglich, den Zugang zur Applikation nur dann zu erlauben, wenn das Login am FTP-Server klappt. Damit entfiele die notwendigkeit, auf dem Client irgendwelche Zugangsdaten zu speichern.
Das möchte ich nicht. Die Applikation soll auch dann funktionieren, wenn kein Internetzugang vorhanden ist.
Verstecken der Zugangsdaten in irgendwelchen ominösen Dateien oder auf der großen Windows-Müllhalde genannt Registry ist Security by Obscurity, das hat noch nie gut funktioniert.
Ok. Vielen Dank für deine Hilfe! Meine Fragen sind vorerstmal alle geklärt. Für weitere Tipps bin ich trotzdem dankbar :-)
Danke schön.
ciao, Lukas
Hallo Alexander,
MD4 und MD5 sind als geknackt anzusehen,
Ja und nein, siehe mein Posting vor ein paar Monaten: http://forum.de.selfhtml.org/archiv/2007/10/t159853/#m1039743
MD4 kann man wirklich den Hasen geben, keine Frage.
MD5 ist *NOCH* hinreichend sicher für gesaltete Passwörter, allerdings stimme ich zu, dass man es wohl besser für neue Anwendungen nicht verwendet, da man ja auch gerne an die Zukunft denkt.
Denn inwiefern ist MD5 geknackt? 1. Es gibt eine einfache Möglichkeit, Kollisionen herzustellen. Nützt einem bei einem gegebenen Hash aber nichts. 2. Es gibt eine Möglichkeit, Brute Force angenehmer zu machen - es bleibt aber immer noch ziemlich unpraktikabel.
SHA-1 ebenfalls.
Nein. Brute-Force wurde um einige Größenordnungen reduziert, die heutige Rechenkapazität reicht aber bei weitem nicht aus, um das in realistischer Zeit zu knacken.
Ich stimme Dir zu, dass man bei einem neu entwickelten System, das keine Kompabilitätsprobleme hat, lieber etwas anderes wie z.B. das von Dir vorgeschlagene SHA-256 nutzen will. Daher kann ich Deinen Rat an den OP, SHA-1 nicht zu verwenden, untersützen, weil er das hier für eine einzige Anwendung baucht, die er selbst schreibt.
Allerdings sagt mir die Panikmache "SHA-1 ist geknackt" nicht zu. Wenn ich aus Kompabilitätsgründen nur SHA-1 für Passwort-Hashes verwenden kann, dann habe ich selbst keine Bedenken, das einzusetzen.
Bei MD5 kommt es darauf an, wofür. Wenn die Passwörter sowieso im Klartext über die Leitung gehen, habe ich auch mit MD5 keine Probleme.
3DES müßte ich mal suchen.
3DES hat keine Kollisionen, daher ist eine Attacke wie auf MD5 undenkbar. Ferner gibt es meines Wissens keine Vereinfachung bei Brute-Force-Angriffen auf 3DES-Hashes. Wenn man sich also mit 8 Zeichen als Passwort und 2 Zeichen als Salt zufrieden gibt, ist 3DES eine sinnvolle Möglichkeit. Fragt sich halt, ob bei nur zwei Zeichen als Salt Rainbow-Tabellen nicht langsam wieder praktikabel werden.
SHA-256 gilt noch als sicher.
Ja. Wenn ich ein neues System designen würde, würde ich wohl auch SHA-256 nutzen wollen.
Den Zugang zum FTP-Server aus der Anwendung heraus könntest Du durch SSH/SCP/SFTP ersetzen und auf jeden Client einen Public Key verteilen. Die entsprechenden Private Keys kannst Du bei Bedarf auf dem Server sperren, womit der Zugang unmöglich wird.
Du solltest Public und Private vertauschen. ;-)
Verstecken der Zugangsdaten in irgendwelchen ominösen Dateien oder auf der großen Windows-Müllhalde genannt Registry ist Security by Obscurity, das hat noch nie gut funktioniert.
Full ACK.
Viele Grüße,
Christian
Hi Christian,
Den Zugang zum FTP-Server aus der Anwendung heraus könntest Du durch SSH/SCP/SFTP ersetzen und auf jeden Client einen Public Key verteilen. Die entsprechenden Private Keys kannst Du bei Bedarf auf dem Server sperren, womit der Zugang unmöglich wird.
Du solltest Public und Private vertauschen. ;-)
Dachte ich mir auch gerade ;-)
Ein kleiner Denk-Anstoß an den OP: Du lieferst die Software erstmal ohne irgendwelche Zertifikate aus. Bei der Installation der Software (bzw. beim erstmaligen Start) generierst du für den User ein Schlüsselpaar, bestehend aus Private- und Public-Key (schau dir mal PGP an). Den Private-Key sicherst du mit einem Passwort, nur unter Verwendung dieses Passwortes lässt sich der Private-Key später verwenden, somit hast du gleichzeitig deine lokale Passwort-Funktion, also die Anwendung vor Zugriff durch Unbefugte geschützt. Wenn du alle Textdateien ebenfalls mit dem Private-Key verschlüsselst, so sind auch diese entsprechend geschützt.
Damit die Anwendung nun Zugriff auf den Server erhält, muss der Public-Key an den Server gesendet werden, dies kann automatisch geschehen, allerdings muss da noch irgendeine Instanz (z.B. DU, wucher wichtel *g*) kontrollieren, ob dies wirklich der erwartete Public-Key ist und nicht ein Man-in-the-middle dir einen anderen Public-Key geschickt hat. Anschließend nutzt zu z.B. SFTP zur Datenübertragung und realisierst den Login wie bereits von Alex erwähnt über das Schlüsselpaar, wofür du den Public-Key auf dem Server hinterlegst.
Viele Grüße,
~ Dennis.
Hallo!
Ein kleiner Denk-Anstoß an den OP: Du lieferst die Software erstmal ohne irgendwelche Zertifikate aus. Bei der Installation der Software (bzw. beim erstmaligen Start) generierst du für den User ein Schlüsselpaar, bestehend aus Private- und Public-Key (schau dir mal PGP an).
Ok. Mein Problem ist jetzt: Wie generiere ich ein solches Schlüsselpaar? Und bekommt jeder User einen eigenen Public-Key oder ist der bei allen Usern gleich (die Anzahl der Anwender wird relativ klein sein)?
Den Private-Key sicherst du mit einem Passwort, nur unter Verwendung dieses Passwortes lässt sich der Private-Key später verwenden, somit hast du gleichzeitig deine lokale Passwort-Funktion, also die Anwendung vor Zugriff durch Unbefugte geschützt. Wenn du alle Textdateien ebenfalls mit dem Private-Key verschlüsselst, so sind auch diese entsprechend geschützt.
Wie kann ich das verschlüsseln? Gibt es dazu Klassen, die ich in mein Programm einbinden kann? Die gleiche Frage bei der Generierung des Schlüsselpaars: Wie erzeuge ich das? Muss ich das irgendwie selber schreiben?
Damit die Anwendung nun Zugriff auf den Server erhält, muss der Public-Key an den Server gesendet werden, dies kann automatisch geschehen, allerdings muss da noch irgendeine Instanz (z.B. DU, wucher wichtel *g*) kontrollieren, ob dies wirklich der erwartete Public-Key ist und nicht ein Man-in-the-middle dir einen anderen Public-Key geschickt hat.
Aber die Entschlüsselung funktioniert doch nur mit dem richtigen Public-Key, oder? Dann wäre es doch egal wenn ein Man-in-the-middle es mit falschen Public-Keys versucht, oder?
Anschließend nutzt zu z.B. SFTP zur Datenübertragung und realisierst den Login wie bereits von Alex erwähnt über das Schlüsselpaar, wofür du den Public-Key auf dem Server hinterlegst.
Ok, das habe ich verstanden. 'tschuldigung für die Fragen, ich könnte mir vorstellen dass sie bescheuert sind. Aber ich mach es nicht mit Absicht :-) Vielen Dank für die tiefergehenden Erläuterungen.
ciao, Lukas
Moin Moin!
Ok. Mein Problem ist jetzt: Wie generiere ich ein solches Schlüsselpaar?
Library-Funktion oder externes Programm.
Und bekommt jeder User einen eigenen Public-Key oder ist der bei allen Usern gleich (die Anzahl der Anwender wird relativ klein sein)?
Der Key identifiziert den User. Also einer pro User.
Den Private-Key sicherst du mit einem Passwort, nur unter Verwendung dieses Passwortes lässt sich der Private-Key später verwenden, somit hast du gleichzeitig deine lokale Passwort-Funktion, also die Anwendung vor Zugriff durch Unbefugte geschützt. Wenn du alle Textdateien ebenfalls mit dem Private-Key verschlüsselst, so sind auch diese entsprechend geschützt.
Wie kann ich das verschlüsseln? Gibt es dazu Klassen, die ich in mein Programm einbinden kann? Die gleiche Frage bei der Generierung des Schlüsselpaars: Wie erzeuge ich das? Muss ich das irgendwie selber schreiben?
Public Key Verfahren sollte es als fertige Libraries geben.
Damit die Anwendung nun Zugriff auf den Server erhält, muss der Public-Key an den Server gesendet werden, dies kann automatisch geschehen, allerdings muss da noch irgendeine Instanz (z.B. DU, wucher wichtel *g*) kontrollieren, ob dies wirklich der erwartete Public-Key ist und nicht ein Man-in-the-middle dir einen anderen Public-Key geschickt hat.
Aber die Entschlüsselung funktioniert doch nur mit dem richtigen Public-Key, oder? Dann wäre es doch egal wenn ein Man-in-the-middle es mit falschen Public-Keys versucht, oder?
Du mußt EINMAL den Public Key zum Server transportieren und dabei gewährleisten, dass nicht ein Dritter den Public Key gegen *seinen* Public Key austauscht. Ein zweiter Kanal wäre hilfreich. Zum Beispiel läßt Du im Programm den Hash des Keys anzeigen und per Telefon-Hotline mit dem auf dem Server angekommenen Hash vergleichen. Oder Du benutzt eine bereits vorhandene sichere (verschlüsselte) Verbindung. Das artet leider schnell in ein Chicken-and-Egg-Problem aus.
Alexander
Hi wucher,
Alexander hat dir ja schon die wichtigsten Sachen geschrieben, zusätzlich möchte ich dir noch ein paar Links empfehlen, da ich das Gefühl habe, dass du mit asymmetrischer Kryptographie noch nicht wirklich vertraut bist ;-)
Und bevor du einen Nervenzusammenbruch kriegst, weil du fürchtest das alles selber implementieren zu müssen, sei noch mal auf GnuPG.org (Erläuterungen) verwiesen. Dabei handelt es sich um freie Software (GPL), welche eigentlich alle notwendigen Algorithmen implementiert hat und welche es möglich sein sollte, bequem zu benutzen.
Übrigens: Falls du mal nichts zu tun hast, was spannendes lesen und trotzdem was lernen willst, dann sei dir „Geheime Botschaften - Die Kunst der Verschlüsselung von der Antike bis in die Zeiten des Internet” von Simon Singh empfohlen, lässt sich gut lesen, wie ich finde :-)
Viele Grüße,
~ Dennis.
Hallo Dennis,
- Schlüsselaustauch nach Diffie-Hellmann (histor. Grundlage)
- RSA-Kryptosystem (heutiger Standard)
Naja, das mit "historisch" vs. "heutiger Standard" stimmt so nicht ganz. DH und RSA werden BEIDE nämlich noch heutzutage eingesetzt - teilweise sogar in Kombination, das passiert bei TLS (ferner gibt's noch weitere Algorithmen).
Daher: DH ist definitiv nicht veraltet oder rein historisch, es hat auch bestimmte Anwendungen, die mit RSA nicht möglich sind (Perfect Forward Security) - beide haben ja sowieso vollkommen andere Zielsetzungen.
Viele Grüße,
Christian
Hallo!
Hmm... eigentlich hatte ich mich gestern schon bedankt, aber scheinbar hab ich das Posting nicht abgeschickt.
Also nochmal: Vielen Dank für eure Hilfe! Ich werde für die nächste Zeit sehr viel zu lesen haben :)
Danke!
ciao, Lukas
Moin Moin!
Du solltest Public und Private vertauschen. ;-)
Hmmm, könnte wirklich helfen... ;-)
Wenigstens bin ich damit nicht allein: Warum haben die "english speakers" ab einem gewissen Alter "public hairs" an ihren "private parts", die sie "public" im allgemeinen nur äußerst ungern zeigen?
Noch ein paar Links dazu -- äh, zum Public Key Verfahren:
http://sial.org/howto/openssh/publickey-auth/
http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Public-Key_Authentication-2.html
http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter8.html
Gerade PuTTY ist ein gern genommener Weg für sichere Kommunikation zwischen Windows-Kisten und SSH-Servern, kann man auch in eigene Software einbinden (gesehen bei TortoiseCVS und TortoiseSVN). Für "dummes" Kopieren von Dateien kann man auch stumpf pscp oder psftp benutzen. Auf der anderen Seite kommt dann ein ganz normaler SSH-Server (openssh, ssh.com, dropbear) zum Einsatz.
Alexander
Hallo!
Wenigstens bin ich damit nicht allein: Warum haben die "english speakers" ab einem gewissen Alter "public hairs" an ihren "private parts", die sie "public" im allgemeinen nur äußerst ungern zeigen?
Noch ein paar Links dazu -- äh, zum Public Key Verfahren:
[...]
Danke für die Links. Wenn ich mal mehr Zeit habe (am Wochenende) lese ich mir die Sachen genauer durch.
Gerade PuTTY ist ein gern genommener Weg für sichere Kommunikation zwischen Windows-Kisten und SSH-Servern, kann man auch in eigene Software einbinden [...].
Ok, damit ist geklärt wie ich es einbinden kann.
Auf der anderen Seite kommt dann ein ganz normaler SSH-Server (openssh, ssh.com, dropbear) zum Einsatz.
Die Daten, die übertragen werden, sind nicht so wertvoll, dass sie geschützt werden müssen. Deswegen ist es (erst einmal) mein Ziel nur ein Loginsystem zu programmieren. Die sichere Übertragung von Daten interessiert mich sehr, ist jetzt aber noch zuviel. Wenn ich das ganze Häppchenweise (erst Loginsystem dann Übertragung auf SSH-Server :-)) lösen könnte wäre es gut.
Oder muss ich einen SSH-Server besitzen um ein sicheres Public- und Private-Key verfahren einzusetzen? Ich denke nicht, aber ich frage lieber nochmal nach :)
ciao, Lukas
Moin Moin!
Die Daten, die übertragen werden, sind nicht so wertvoll, dass sie geschützt werden müssen.
Nimm einmal an, ich käme an eine Kopie der Daten. Nimm weiter an, ich sei hoch motiviert, Dir ernsthaft zu schaden. Nimm außerdem an, dass mir reichlich Geld, Technik und hoch motivierte, begabte Menschen zur Verfügung stehen. Und nimm an, ich arbeite für Dich. Wie groß ist der Schaden, den ich anrichten kann?
Die meisten Angriffe (je nach Quelle 75 bis 90 Prozent) kommen von innen.
Deswegen ist es (erst einmal) mein Ziel nur ein Loginsystem zu programmieren. Die sichere Übertragung von Daten interessiert mich sehr, ist jetzt aber noch zuviel. Wenn ich das ganze Häppchenweise (erst Loginsystem dann Übertragung auf SSH-Server :-)) lösen könnte wäre es gut.
Wenn Du keine sichere Datenübertragung hast, kannst Du Dir das Login vermutlich auch gleich schenken.
Oder muss ich einen SSH-Server besitzen um ein sicheres Public- und Private-Key verfahren einzusetzen? Ich denke nicht, aber ich frage lieber nochmal nach :)
Nö, ssh brauchst Du nur als Ersatz für telnet, rlogin und ftp bzw. deren Server.
Public-Key-Verfahren funktionieren prinzipiell ohne Server. Öffentliche Key-Server machen das Arbeiten mit PGP/GPG zwar leichter, aber technisch käme man ohne sie aus. Siehe auch Web of Trust.
Alexander