Ich glaube nicht, dass es möglich ist Tastendrücke ins Nirvana zu senden, davon abgesehen hast du aber doch ein grundsätzlicheres Problem deiner Idee schon erkannt?!

Ein zweites Programm, was nebenbei läuft, wäre nicht so gut, da einige Keylogger auch die Prozesse anzeigen, in denen die Keys gedrückt wurden.

Ein solcher Keylogger würde doch ohnehin nur die Characters anzeigen, die dein Programm auch empfangen hat.

Wie würdet ihr das machen? Gibt es da eine Möglichkeit?

Spontan würde ich einfach eine zufällige Characterfolge in das Textfeld schreiben, mir diese aber merken und nach dem Druck auf Enter wieder ausfiltern. Um den Nutzer nicht zu verwirren müsstest du den Inhalt des Feldes natürlich ausblenden, das Passwort müsste also blind eingegeben werden, ich halte das aber bei üblichen Passwortlängen für zumutbar.

Danke, das hilft mir schonmal, ich weiß allerdings, wie du das genau meinst mit den "zufällige Characterfolge in das Textfeld schreiben. Könntest du mir das mal genauer erklären?

Sobald dein Passwortfeld den Fokus bekommt rufst du im entsprechenden Event Handler eine Methode auf und generierst einen zufälligen String. Diesen schreibst du dann buchstabenweise in zufälligen Zeitabständen (zB. zwischen 100-500ms) mittels SendKeys() in dein Textfeld, solange bis du entweder an das Stringende gekommen bist, das Textfeld den Fokus verliert oder der Nutzer auf Enter drückt/die Eingabe absendet. Anschließend vergleichst du die fertige Eingabe mit den gesendeten Characters und konstruierst daraus das Passwort.

Damit dein Programm dazwischen nicht einfriert wirst du die Methode, die die Zufallseingaben übernimmt wohl in einem eigenen Thread laufen lassen müssen. Einfach ist anders, aber so sollte es zumindest gehen.

Ich habe einen anderen Ansatz.

Der User gibt das Passwort ein: geheim

In das Textfeld wird aber geschrieben: gtehkjeimrm

Du legst die erst mal paar Zufallszahlen bereit, also 1 2 2 1. Die Summe darf höchstens so groß sein, wie die Mindestlänge des Passworts, hier 6.

Gibt der User das 1. Zeichen ein, streust du nun eine zufällige Zeichenkette ein, hier das t.
Dann gibt der User 2 weitere Zeichen ein und du streust zufällig kj ein.
User gibt wieder 2 Zeichen ein, du streust zufällig mr ein.
User gibt 1 Zeichen ein, du streust zufällig nichts ein.

Da du hier nichts von der Zeit abhängig machst, kannst du auch viel einfacher das echte Passwort geheim speichern. Deine zufällig eingestreuten Zeichen kannst du sofort wieder vergessen.

Ich habe mir das gerade so erdacht, also wenn hier ein grober Denkfehler ist, dann bitte unbedingt bescheid sagen.

Ich glaube jetzt, das ist das gleiche was niles geschrieben hat, aber nicht mit "in zufälligen Zeitabständen" sondern mit zufälligen Zeichenabständen.

Gruß

FeliX_22

Das geht sicher auch, der Grund warum ich eher auf zufällige Zeiteinheiten setzen würde ist der, dass ein Keylogger, der die Zeitabstände zwischen den Tastenanschlägen mitloggen würde die generierten Tastenanschläge erkennen könnte. Denn SendKeys() wird erkennbar schneller arbeiten als ein Durchschnittsnutzer, der sein Passwort blind eingeben muss.
Allerdings ist das wohl ein pathologisches Szenario, zumindest ich habe noch nie davon gehört, dass Keylogger in der Praxis sowas protokollieren. Unter diesem Gesichtspunkt ist dann deine Variante, da einfacher zu implementieren, die bessere.



Um was genau zu tun? Die erste Zufallseingabe sollte bereits erfolgen, sobald das Textfeld den Fokus bekommt, danach kannst du dann im Prinzip jedes dieser Events benutzen, TextChanged bietet sich insofern an, als du nicht überprüfen musst ob der Nutzer ein PW-Zeichen oder eine Taste wie Enter gedrückt hat.

Edit: Wobei das ganze natürlich etwas trickreich zu implementieren ist, denn diese Events werden ja alle durch SendKeys.Send() wieder getriggert.

Der kritische Bereich ist dieser:



Wenn der Thread hier abgewürgt wird, dann werden einige "virtualkeys", wie du sie nennst, nicht abgefangen. Um das zu verhindern musst du diesen Bereich als atomar (= nicht unterbrechbar) deklarieren mittels einer Lock-Variablen (zumindest heißen die Dinger in C# so). In vb.net nutzt man dazu laut google das SyncLock Statement.

Ich versteh den Sinn von SyncLock nicht ganz, heißt das, der Teil wir in einem Rutz ausgeführt, ohne das ein anderer Thread nebenbei etwas ausführen kann?

Richtig, man braucht solche Mechanismen um den sogenannten wechselseitigen Ausschluss zu garantieren.

Was bei deinem Code passieren kann:

1. Die innere while-Schleife wird betreten, virtualkeys wird auf true gesetzt.
2. Der Nutzer drückt eine Taste, das KeyPressed Event wird ausgelöst
-> dein KeyPresshandler fängt die gedrückte Taste ab, setzt virtualkeys auf false
3. threadsendkey() läuft weiter und sendet eine Taste, die nicht abgefangen wird

Das Phänomen solltest du leicht beobachten können, wenn du dein Programm ausführst und dann eine Taste konstant hinunterdrückst.

Was ich hier schrieb:

Der kritische Bereich ist dieser:

ist allerdings Blödsinn. Der kritische Bereich ist natürlich, wie aus obigem hervorgeht, die innere while Schleife in threadsendkey().

Wie setze ich das korrekt ein...?

Kann ich dir leider nicht sagen, dafür bin ich in VB nicht sattelfest genug. Aber dürfte nicht allzu kompliziert sein, wenn ich mir das msdn Beispiel anschaue

Hmm, da sich nichts ändert kann ich mir das prinzipiell nur so erklären, dass SyncLock nur taugt, um eigene Threads voneinander abzusichern, die Systemprozesse (die die Tastatureingaben behandeln) sind offensichtlich immer noch in der Lage deinen Thread abzuwürgen und den entsprechenden Handler aufzurufen.

Dann eben anders: Wenn wir schon nicht garantieren können, dass threadsendkey() nicht unterbrochen wird, dann muss eben ein zusätzlicher Kontrollmechanismus her, damit dein Handler erkennt, woher der Tastendruck kommt. Dazu bietet es sich an, neben virtualkeys eine zusätzliche char-Variable virtualkey anzulegen, mittels der überprüft wird, ob der empfangene Character dem entspricht, der mittels SendKey() gesendet wurde. Das sollte dann ungefähr so aussehen:



Jetzt können zwei Sachen passieren:

1. Der Nutzer drückt eine von der virtuellen verschiedene Taste
-> wird erkannt
2. Der Nutzer drückt die gleiche Taste
-> dann wird theoretisch der echte Tastendruck ausgefiltert, aber logischerweise der virtuelle durchgelassen (virtualkeys = false), was aber dann offensichtlich keine Rolle spielt.

Hoffe mal das ich nichts übersehen habe, aber eigentlich sollte das so klappen.