Login verbessern

  • VB.NET

Es gibt 19 Antworten in diesem Thema. Der letzte Beitrag () ist von Linkai.

    Login verbessern

    Hallo Community,
    Ich habe ein Login Programmiert und frage mich ob man vielleicht das ein wenig sicherer machen kann oder verbessern kann

    VB.NET-Quellcode

    1. If textbox1.text = my.settings.username and textbox2.text = my.settings.password then
    2. Form2.show()
    3. end if

    My.Settings ist eine XML Datei auf deinem PC die jeder lesen kann.

    Der erste Ansatz wäre das Password gehasht auf deiner Festplatte zu speichern und die Hashwerte zu vergleichen.

    Allerdings kann einfach jeder die Datei löschen/ändern in der du das gespeichert hast. NET Code ist zudem mit einem kleinen Tool innerhalb weniger Sekunden dekompiliert und daher lässt sich alles ziemlich einfach rausfinden (auch ohne das Programm zu "patchen").
    Die sicherste Variante wäre ein Onlinelogin über zB PHP/Webservice und die Daten kommen dann auch nur über einen Webservice oder eine PHP Seite zu deinem Programm. Kurz: Alles was lokal gespeichert ist, ist grundsätzlich unsicher.

    Die Frage ist, wofür soll der Login sein?
    Das ist meine Signatur und sie wird wunderbar sein!

    Die einfachste art einen Login mit PHP zu bauen ist garnicht soo einfach (wenn man es das erste mal macht.)

    Dafür benötigst du:
    Einen Webserver (zB Apache)
    Einen Datenbankserver (zB Mysql)
    und natürlich einen Zugang zum Server!

    Dann solltest du dir (falls nicht schon vorhanden) PHP beibringen.
    Mit PHP kommunizierst du mit der Datenbank. Es ist mehr oder weniger deine Schnittstelle zu deinen Daten.

    In VB verwendest du nun einen Webclient um deine Daten an den Server zu versenden. Dafür verwende bitte eine gesicherte HTTPS verbindung, da sonst jeder idiot mit einem auf google findbaren tool alles mitlesen kann!
    Nun kannst du im Beispiel vom Login den Benutzernamen sowie (wie oben schon erwähnt) das gehashte passwort an den Server schicken und mit den Einträgen in der Datenbank vergleichen lassen.
    Die PHP Datei kann dann soetwas wie Okay oder False zurückgeben. Dies kannst du dir als Antwort in VB in einer Variable speichern die du dann weiterverarbeiten kannst.
    zB dann die Hauptform des Programms öffnen lassen oder aber eine Fehlermeldung ausgeben, dass die Anmeldung fehlgeschlagen ist.

    Infos dazu gibts auch hier im Forum wie Sand am Meer.
    Viele Frauen kamen, viele sind gegangen, eine ist geblieben 12.5.12 <3 ich liebe dich Schatz :love: :love:

    Linkai schrieb:

    Dafür verwende bitte eine gesicherte HTTPS verbindung
    Jo.

    Linkai schrieb:

    das gehashte passwort an den Server schicken
    Das kann etwas suboptimal sein. Bei HTTPS ist die ganze Sache nicht so dramatisch, aber nur allgemein: Das Hashen sollte im Allgemeinen immer auf dem Server ablaufen. Hintergrund: Schickst Du das bereits gehasht an den Server und jemand schafft es den abzugreifen, kann er diesen direkt benutzen, um sich einzuloggen.
    Wie gesagt, ist die Verbindung verschlüsselt, ist das jedoch soweit kein Problem.

    @OxFord Dialoge: Instanziierung von Forms und Aufruf von Dialogen

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Trade schrieb:

    Hintergrund: Schickst Du das bereits gehasht an den Server und jemand schafft es den abzugreifen, kann er diesen direkt benutzen, um sich einzuloggen.

    Ach so. Dann ist es wohl in der Tat besser wenn man das Passwort nicht hasht. Immerhin hätte der Angreifer dann nur das Passwort im Klartext und könnte sich nicht einloggen.

    Nö, in so einem Falle könnte/sollte man das dann doppelt hashen. Ist aber davon abgesehen eh nie ein Ersatz für HTTPS, sodass immer eine verschlüsselte Verbindung benutzt werden sollte.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Trade schrieb:

    Bei HTTPS ist die ganze Sache nicht so dramatisch, aber nur allgemein: Das Hashen sollte im Allgemeinen immer auf dem Server ablaufen.

    Diese Aussage ist einfach Mist, so was sollte auf dem Client passieren, egal ob HTTP oder HTTPS.
    Du sagtest: Sollte es einem Angreifer bei einer HTTPS Verbindung trotzdem gelingen den Traffic im Klartext mitzulesen, ist es besser, wenn man das Passwort erst auf dem Server hasht.

    Schickst Du das bereits gehasht an den Server und jemand schafft es den abzugreifen, kann er diesen direkt benutzen, um sich einzuloggen.

    Schickst du es im Klartext an den Server, kann der Angreifer sich nicht nur einloggen, sondern hat auch das Passwort des Users und kann eventuell noch Accounts bei anderen Portalen kompromittieren.

    ​Nö, in so einem Falle könnte/sollte man das dann doppelt hashen.

    Nö, in so einem Fall sollte man das mehrere tausend male hashen, siehe z.B. PBKDF2.

    Rinecamo schrieb:

    Schickst du es im Klartext an den Server, kann der Angreifer sich nicht nur einloggen, sondern hat auch das Passwort des Users und kann eventuell noch Accounts bei anderen Portalen kompromittieren.
    Also gut, wenn das anscheinend doch so missverständlich war und ich eigentlich dachte, es wäre logisch, dass man es nicht im Klartext senden soll: Nein, Klartext natürlich auch nicht.

    Aber: Sendest Du jetzt das Passwort auch in der gehashten Form, in der es auch in der Datenbank steht, an den Server und es gelingt, das abzugreifen, dann ist's problematisch.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    das gehashte passwort an den Server schicken -> Das Hashen sollte im Allgemeinen immer auf dem Server ablaufen.
    Ist im Kontext, vor allem für eher unerfahrene User wie OP, sehr missverständlich, in der Tat.

    Na gut, das hätte ich etwas weiter formulieren sollen. Hatte ich mir noch überlegt, dann aber für redundant gehalten.
    Mach ich dann das nächste Mal, ist ja nun geklärt.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Nö, in so einem Falle könnte/sollte man das dann doppelt hashen. Ist aber davon abgesehen eh nie ein Ersatz für HTTPS, sodass immereine verschlüsselte Verbindung benutzt werden sollte.


    ​Nö, in so einem Fall sollte man das mehrere tausend male hashen, siehe z.B. PBKDF2.


    Aber: Sendest Du jetzt das Passwort auch in der gehashten Form, in der es auch in der Datenbank steht, an den Server und es gelingt, das abzugreifen, dann ist's problematisch.


    Was würde es denn für einen Unterschied machen, es dann am Webserver nochmal zu Hashen?
    Sobald ich weiß, was die Anwendung sendet kann ich den Request nachbauen, egal ob das Passwort ein Hash oder im Klartext ist. Damit komme ich auch an die Daten so oder so. Ich sehe keinen Vorteil es am Server nochmal zu hashen (auch 1000 mal hashen ändert daran nix). Wenn man es 1000 Mal hasht, dann auch am Client.
    Das ist meine Signatur und sie wird wunderbar sein!

    Ich habe erst gestern ein Programm geschrieben, welches das gehashte Passwort im Code speichert und dann das was du eingibst hasht und dann vergleicht.
    Hier das Snippet in C#:

    C#-Quellcode

    1. public string ErstelleMD5Hash(string inhalt)
    2. {
    3. MD5 md5 = System.Security.Cryptography.MD5.Create();
    4. byte[] inhaltBytes = System.Text.Encoding.ASCII.GetBytes(inhalt);
    5. byte[] hashBytes = md5.ComputeHash(inhaltBytes);
    7. StringBuilder sb = new StringBuilder();
    8. for (int i = 0; i < hashBytes.Length; i++)
    9. {
    10. sb.Append(hashBytes[i].ToString("X2"));
    11. }
    12. return sb.ToString();
    13. }

    Das ist eine Funktion mit der ein Hashwert eines beliebigen Strings erstellt wird in MD5.
    Als nächstes habe ich mein bereits vorher verschlüsseltes Passwort im Code gespeichtert und die Funktion(siehe oben) genutzt um das eingegebene Passwort in einer Textbox zu Verschlüsseln und dann mit dem im Code gespeicherten String(verschlüsselt) zu vergleichen.
    Da jeder gleiche String den gleichen Hashwert hat kannst du es mit jedem beliebigen String machen

    C#-Quellcode

    1. private void button1_Click(object sender, EventArgs e)
    2. {
    3. string eingegeben;
    4. string p = "04c304a2524bdd5e101aa10bc8b1335e";
    5. eingegeben = ErstelleMD5Hash(textBox1.Text);
    6. eingegeben = eingegeben.ToLower();
    7. if(eingegeben == p)
    8. {
    9. label2.Text = "Richtiges Passwort";
    10. }
    11. else
    12. {
    13. label2.Text = "Falsches Passwort";
    14. }
    16. }

    Die Variable p ist das im Code gespeicherte Passwort und die Variable "eingegeben" ist der Return von der Funktion der mit p vergleichen wird.

    Ich hoffe ich konnte dir weiterhelfen

    Grüße Ardian

    Edit: 04c304a2524bdd5e101aa10bc8b1335e im Klartext ist: p6drypnyx3n

    Ich wollte das ganze jetzt nicht bis an die Spitze treiben aber wenn wir es richtig machen wollen:

    Passwort lokal hashen! Dafür gibt es definitiv keine andere Möglichkeit. Im klartext an den server ist der letzte rotz!
    Nun sollte man natürlich wie bereits erwähnt das ganze dann nicht einfach so in die Datenbank eintragen, sonste könnte, wie bereits erwähnt, nach dem abfangen des hashes
    der angreifer einfach so an deine Daten im Programm gelangen. Hat zwar den Vorteil dass es "NUR" diese Daten sind und nicht das Passwort im klartext mit dem er sich ggf auch wo anders anmelden könnte,
    aber es muss ja nicht sein!.
    Also verschlüsslung her.
    Nun kannst du eine Symetrische oder eine Asymetrische variante nehmen.
    Falls du ganz sicher gehen willst Hybrid aber da weiß ich jetzt nicht, in wie weit die daten wichtig sind um einen solchen aufwand zu betreiben.
    auf dem Server dann entschlüsseln nochmal hashen und dann abgleichen.

    gibts sonst noch was beim Thema Verschlüsslung zu sagen?
    Viele Frauen kamen, viele sind gegangen, eine ist geblieben 12.5.12 <3 ich liebe dich Schatz :love: :love:

    Mono schrieb:

    Was würde es denn für einen Unterschied machen, es dann am Webserver nochmal zu Hashen?

    Du darfst dir das nicht so linear vorstellen. Der Client bekommt vom Server beim Authentifizieren einen zufälligen Salt. Mit diesem Salt wird das password gehasht.
    Mit dieser Methode ist der Passwordhash bei gleichem Passwort bei jedem Versuch anders. Damit der Server nun überprüfen kann, ob der Hash richtig ist, muss er selbst noch mal den Hash den er bereits hat mit seinem Salt hashen.

    MIt PBKDF2 bezog ich mich übrigens schon auf die Client-Side.

    Das ist dann ein anderes Verfahren, liesse sich aber auch nachstellen. Das einzig Sinnvolle ist eine komplett verschlüsselte Übertragung mit einem am Client erzeugten Hash.
    Das ist meine Signatur und sie wird wunderbar sein!

    Mono schrieb:

    liesse sich aber auch nachstellen

    Nur wenn der Angreifer das Passwort im Klartext hat. Wenn er nur den Hash hat kann er nix machen, da dieser immer unterschiedlich ist.

    Mono schrieb:

    Das einzig Sinnvolle ist eine komplett verschlüsselte Übertragung mit einem am Client erzeugten Hash.

    In Verbindung mit oben genannter Methode (oder ähnlich).

    Ja Nachstellen wäre zeitaufwändig(Der Salt kommt ja normal unverschlüsselt vom Server. Anhand desses und des Hashes mit dem Salt kann man durch Bruteforce auf das Passwort kommen und dann das Ganze nachbauen). Aber wenn einer dazwischen hängt kann er einfach den salty Hash vom Client nehmen und sich als Client ausgeben und anstelle des Clients diesen dann an den Server senden damit seine Session hijacken.
    Das ist meine Signatur und sie wird wunderbar sein!

Facebook
Telefonspende