Sicherer Chat programmieren

  • VB.NET

Es gibt 32 Antworten in diesem Thema. Der letzte Beitrag () ist von Switcherlapp97.

    Sicherer Chat programmieren

    Hallo

    Ich bin gerade dabei ein Chat Programm auf FTP Basis zu entwickeln. Im Internet habe ich Videos gesehen wie einfach aus dem Quellcode Zugangsdaten zu entnehmen sind. Kann man sich mit einem FTP Server verbinden ohne das Passwort in den Quellcode zu schreiben???

    Ich bin nach längerer Beschäftigung auf keine Lösung gekommen. Was für ein anderes Protokoll könnte für so etwas noch werden??

    Auf dem Server sollen die Kontakte des Benutzers, die Nachrichten und die persönlichen Einstellungen und Profil-Daten gespeichert werden. Diese ganzen Daten werden verschlüsselt auf dem Server gespeichert und vom Benutzer wieder entschlüsselt. Nur Verschlüsselungen können doch recht schnell wieder in Klartext übersetzt werden ...

    Also meine Frage: Ist ein sicheres Chat-Programm auf FTP Basis möglich oder ist dafür ein anderes Protokoll notwendig? Wenn ja welches?

    Gruß
    Switcherlapp97
    RubiksCubeSolver


    Jetzt im Showroom

    Also das mit dem Multiserver (TCP) finde ich ein guter Ansatz. Allerdings habe ich mit diesem Protokoll noch nie etwas programmiert. Wenn man den Login also noch um ein Passwortfeld erweitert, habe ich keine Ahnung wie dies abgefragt und als richtig festgestellt werden kann. Wäre sehr erfreut über ein einfaches Beispiel zum Login mit Passwort ..

    Vielen Dank schon mal für die bisherigen Antworten
    LG
    Switcherlapp97
    RubiksCubeSolver


    Jetzt im Showroom

    1. Benutzer gibt Passwort ein.
    2. Client macht einen Hash aus dem Passwort
    3. Client sendet Benutzername und Passwort an Server
    4. Server schaut nach ob er den Benutzernamen kennt. Wenn ja holt sich dieser das Passwort aus seiner Datenbank/Tabelle/Datei/Speicher... Wenn dieses schon gehasht ist, dann Passwörter vergleichen. Wenn nein erst hashen und dann mit dem Passwort das vom Client gesendet wurde vergleichen.
    5. Wenn Logindaten stimmen -> in Chat aufnehmen
    6. Ansonsten Verbindungsversuch abweisen.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    Also dafür wird ein Server benötigt und damit man auf diesen Server zugreifen kann benötigt man doch wieder Username und Passwort und dann steht das doch wieder im Code.

    Oder habe ich das Prinzip von TCP falsch interpretiert??
    RubiksCubeSolver


    Jetzt im Showroom

    thefiloe schrieb:

    Wenn dieses schon gehasht ist, dann Passwörter vergleichen.
    Er sollte lieber nicht prüfen, obs schon gehasht ist oder nicht.
    Stell dir mal vor, der Hacker kommt an den Hash <- theoretisch müsste er den Hash cracken, aber bei deinem Vorschlag, nimmst du dem Hacker die Arbeit.


    Edit: Bei TCP brauchst weder Username noch Passwort. Es sei denn, du programmierst es dazu (du musst ja auch den Server selbst programmieren).


    Mfg.
    SAR

    @SAR-71 Der Server läuft ja noch über Localhost und der ist ja dann nur erreichbar wenn mein Rechner an ist. Und wenn er immer erreichbar sein soll, läuft dass ja über einen Server und der benötigt Zugangsdaten oder habe da was missverstanden??

    @Artentus Dieses Verfahren scheint für so etwas sehr gut geeignet zu sein. Ich habe allerdings noch überhaupt keine Erfahrung mit solchen etwas komplexeren Verschlüsselungen. Hast du schon mal mit dieser Verschlüsselung etwas programmiert?? Wär cool wenn du mir vielleicht ein einfaches Beispiel posten könntest.

    Vielen Dank für die bisherigen Antworten
    LG
    Felix
    RubiksCubeSolver


    Jetzt im Showroom

    Damit Programmiert habe ich noch nicht, aber es sollte nicht allzu schwer sein. Als erstes tauscht du, wie in dem Artikel beschrieben, die Schlüssel aus. Danach brauchst du lediglich noch alle Nachrichten zu ver- bzw. entschlüsseln, wofür es bereits fertige Klassen im Framework gibt.

    Das mit dem Diffie-Hellman-Schlüsselaustausch habe ich noch nicht ganz geschnallt. Also bevor man chattet wird dieser Schlüssel erst willkürlich festgelegt. Also um nur mal schnell ne Nachricht zu schreiben gleich eine Verschlüsselung selbst erfinden?? Oder generiert ein Programm diesen Schlüssel. Da Blick ich echt noch nicht durch ...
    RubiksCubeSolver


    Jetzt im Showroom

    SAR-71 schrieb:

    Er sollte lieber nicht prüfen, obs schon gehasht ist oder nicht.
    Stell dir mal vor, der Hacker kommt an den Hash <- theoretisch müsste er den Hash cracken, aber bei deinem Vorschlag, nimmst du dem Hacker die Arbeit.
    Was? Was soll daran unsicher sein? Entweder sind Passwörter in der Datenbank im Klartext(unsicher -> dann müsste er aber zum Vergleichen dieses noch zuerst hashen) oder sie sind bereits gehasht in der Datenbank was wesentlich sicherer ist und er kann gleich vergleichen. Manche speichern Passwörter leider trotzdem immer noch im Klartext ab. :(
    Aber was du da überprüfen willst bleibt offen. Entweder er speichert diese im Klartext oder als Hash. Prüfen muss man da gar nix.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    Du musst nicht die Verschlüsselung erfinden, du musst lediglich den Schlüssel (auch Passwort genannt) erzeugen. Der Diffie-Hellman-Austausch ist lediglich ein Verfahren dafür, den Schlüssel allen Parteien bekannt zu machen, ohne ihn schicken zu müssen (was ja den Sinn der Verschlüsselung zu Nichte machen würde).

    thefiloe schrieb:

    Was? Was soll daran unsicher sein? Entweder sind Passwörter in der Datenbank im Klartext(unsicher -> dann müsste er aber zum Vergleichen dieses noch zuerst hashen) oder sie sind bereits gehasht in der Datenbank was wesentlich sicherer ist und er kann gleich vergleichen. Manche speichern Passwörter leider trotzdem immer noch im Klartext ab. :(
    Aber was du da überprüfen willst bleibt offen. Entweder er speichert diese im Klartext oder als Hash. Prüfen muss man da gar nix.

    thefiloe schrieb:

    4. Server schaut nach ob er den Benutzernamen kennt. Wenn ja holt sich dieser das Passwort aus seiner Datenbank/Tabelle/Datei/Speicher... Wenn dieses schon gehasht ist, dann Passwörter vergleichen. Wenn nein erst hashen und dann mit dem Passwort das vom Client gesendet wurde vergleichen.


    Ein Szenario: Klaus hat eine Datenbank mit Usernames und entsprechende Passwörter. Die Passwörter sind gehasht und sind stark gesalzen (Anspielung auf Salts). Robert loggt sich regelmäßig ein und die Software wurde so entwickelt, dass keine Klartext-Passwörter übertragen werden, sondern nur Hashes. Da Robert aber nur in öffentlichen WLAN-Netzen unterwegs ist, werden seine Loginformationen vom Hacker (Name unbekannt) abgegriffen.
    Leider hat der Hacker kein Klartext-Passwort. Aber Klaus hat einen Fehler beim Login. (Dieser Fehler bei dir in Punkt 4 enthalten und in diesem Beitrag auch zitiert).
    Also gibt der Hacker einfach das gehashte Passwort an - obwohl er nicht den Klartext kennt - und kann sich als Robert einloggen und Schwachsinn treiben.



    Mfg.
    SAR

    Ich editiere mal deinen Punkt:
    4. Server schaut nach ob er den Benutzernamen kennt. Wenn ja holt sich dieser das Passwort aus seiner Datenbank/Tabelle/Datei/Speicher... und dann mit dem gehashten Passwort das vom Client gesendet wurde vergleichen.


    Mfg.
    SAR

    Der User erstellt auf dem Server einen Account mit UserName und Passwort. User verbindet sich und übergibt den UserName (Klartext oder gehashed). Server sucht in seiner Datenquelle nach diesem UserName. Findet er ihn, holt er sich das zugehörige Passwort (gehashed). Ab hier beginnt die verschlüsselte Übertragung. Als Schlüssel dient der Hash des Passwortes oder eine Kombination aus UserName und Passwort (was auch immer). Server sendet (verschüsselt) die Aufforderung zur Passowortübertragung. Client kennt die Methode des Servers und kann somit die verschlüsselte Übertragung seinerseits entschlüsseln. Client sendet verschlüsselt das Passwort (als Hash oder was auch immer). Server entschlüsselt, prüft Passwort.

    Ist nun ein MITM involviert. So kann er höchstens den UserNamen abgreifen, hat aber keine Ahnung, wie er die verschlüsselte Antwort des Servers interpretieren soll, da für ihn nur Datenmüll ankommt. Die einzige Angriffstelle ist hier die Erstanmeldung, alles andere passiert verschlüsselt und sollte somit einigermaßen sicher sein.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

    SAR-71 schrieb:

    4. Server schaut nach ob er den Benutzernamen kennt. Wenn ja holt sich dieser das Passwort aus seiner Datenbank/Tabelle/Datei/Speicher... und dann mit dem gehashten Passwort das vom Client gesendet wurde vergleichen.
    Genau das sage ich ja?? Was hast du für ein Problem damit^^ Lies es doch mal durch.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    Schon mal Danke für die Antowrt @SpaceyX. Wenn der Client die Aufforderung kennt, muss im Code vom Client doch etwas von der Verschlüsselung stehen. Und dies kann doch wieder ausgelesen werden. Oder habe ich das Prinzip falsch verstanden??

    Ich hätte jetzt noch ne Frage: habe Webspace bei kilu.de. Ist es überhaupt möglich den TCP-Chat über den kilu.de Server laufen zu lassen??

    Gruß
    Switcherlapp97
    RubiksCubeSolver


    Jetzt im Showroom

    Der User muss ja bei jeder der Anmeldung seinen UserNamen und Passwort angeben. Ob diese Daten nun lokal auf seinem PC gespeichert werden, steht auf einen anderen Blatt. Client schickt seinen Nutzernamen an den Server, Server antwortet verschlüsselt. Der Schlüssel ist hier beiden bekannt. Kann der Client den Stream/Daten nicht entschlüsseln, stimmt wohl das Passwort nicht, welches der User eingegeben hat.

    Du brauchst einen Windows-Server (bzw. Linux mit MONO), um .NET-Programme laufen zu lassen. Also spricht, einen Root-Server oder etwas vergleichbares.
    Die Unendlichkeit ist weit. Vor allem gegen Ende. ?(
    Manche Menschen sind gar nicht dumm. Sie haben nur Pech beim Denken. 8o

Facebook
Telefonspende