Gibt es was "Härteres" als Application.Exit ??

Hi C#ler

Also Folgendes:

In meinem Projekt gibt es mehrere Profile.
Dass heißt es können auch mehrere Forms auf einmal offen sein.

Nun möchte ich, dass mein Programm bei 3 maliger falscher Passworteingabe unverzüglich und ohne umwege über evenuelle OnClosing Evente beendet wird, damit das Programm für Bruceforceattacks oder mehrmalige PW eingaben geschützt ist.

Wie mach ich das?

Danke im Vorraus

Axxus

Process.GetCurrentProcess().Kill();

härter geht es wohl eher nciht mehr. das ist so als hättest du im taskmanager den prozess abgeschossen.

aber das ist keine gute lösung.

Environment.FailFast ?

@ JAck30lena mhh und was wäre eine besere Lösung? schließlich soll ja nichts mehr an dem Programm geamcht werden können

@ wakestar was meisnt du damit?

Schau doch mal in die MSDN, was die dazu sagt: Link

Hallo, das gleiche Problem hatte ich auch.

Habe ein Programm das vor dem PC Start ein Passwort abfrägt.

Nach 3 maliger Falscheingabe fährt sich der PC herunter,
sowie lasse ich davor die Textboxen verschwinden (für das Passwort)
so ist man auf jeden Fall vor Bruteforce geschützt.

Zusätzlich kann man dem String ja noch einen Wert übergeben das das Programm
ab jetzt gesperrt ist und keine Befehle mehr annimmt. Dann hat man es doppelt gemoppelt 😉

Edit: Der Kill Prozess würde ich nicht nehmen,
kann dazu führen das sich dein Programm aufhängt und dann erst recht nicht
beendet wird.

@ wakestar was meisnt du damit?

ich meine damit du sollst dir mal die Methode FailFast von der Klasse Environment anschauen 😉

evtl. hat für dich FailFast die richtige Mischung zwischen "abwürgen" und "sauber beeenden"

mhh ich glaub ihr habtr die situation falsch gedeutet:

Es ist nich so, dass am Anfang einamal das PW abgefragt wird und dann nie wieder.
Das Programm beinhaltet eine Methode zum wechseln des Profils.

d.h.

User gibt 3 mal das Pw falsch ein
->
Programm wird beendet, aber ein anders Form hat noch eine abfrage zum Schleißen
->
Person klickt auf nicht schließen und öffnet das Fenster erneut
->
siehe oben

das Enviroment ding übergeht nur die finally Blöcke aber ich möchte dass vor allem auch die OnClosing Blöcke übersprugen werden.

Ich könnte auch einfach eine bool Varriable einbauen aber ich möcht halt 100% tig sicher gehen dass das Prog sauber beenet wird und es keine möglichkeit gibt das beenden aufzuhalten

Ich könnte auch einfach eine bool Varriable einbauen aber ich möcht halt 100% tig sicher gehen dass das Prog sauber beenet wird und es keine möglichkeit gibt das beenden aufzuhalten

um es sauber zu beenden ist die bool-variante die beste. wenn du nicht willst das deine anwendung auch mit großen mühen gehackt wird dann verwende einen obfuscator oder andere entsprechende tools. wenn selbst das zu wenig ist musst du es unmanaged machen.

aber im ernst... ein environment.exit oder ähnliches finde ich schneller und beseitige es wenn ich es möchte, als eine der möglichen unzähligen variablen zu verfolgen....

hey mit enviroment.Exit funktionert es freu

Danke

genau sowas hab ich gesucht^^

das ist ebenfalls keine saubere lösung und auch recht licht zu entfernen.

ich weiss ja nicht was für eine Applikation du hast und welcher Code wo ausgeführt wird, aber ein "normaler" Benutzer der sich 3x vertippt hat (warum auch immer) würde unter Umständen Daten verlieren, oder nicht? (weil unter Umständen gewisse Funktionen eben nicht ausgeführt werden...)

mhh ich glaub ihr habtr die situation falsch gedeutet: ...

Ich weiß nicht, aber du solltest vielleicht deine Benutzersteuerung umbauen anstatt mit irgendwelchen Hacks zu versuchen dein Programm abzusichern:

Ich würde ein Wechseln des Profils nur zulassen wenn alle anderen Dialoge geschlossen sind.

Bei 3maliger Falscheingabe würde ich das Programm nicht beenden, sondern alle Menüpunkte deaktivieren.

Das Programm zu beenden bringt nämlich relativ wenig da clevere Bruteforcer das Programm einfach wieder öffnen würden.

Dazu kommt die Problematik das man C# Code dekodieren kann und somit sämtliche Hinderungsmaßnahmen unschädlich machen kann.

Wenn du was sicheres suchst, stellst du dir ein entfernten Server hin der die Logins mitzählt und den Login nach 3 Versuchen sperrt, so wie es im WWW gemacht wird.
Alles andere ist der Versuch die 'Knackzeit' zu verlängern.

gruß Sieben

wie wäre es mit geplanten unbehandelten exceptions um dem prog den exitus zu geben? ^^

Hallo Janchu88,

die Lösung liegt ja wie schon von anderen angesprochen nicht darin, wie man ein Programm an einer bestimmten Stelle hart abbricht, sondern dass man ein Design wählt, das einen solchen harten Abbruch gar nicht erfordert. Und das ist hier ohne weiteres möglich. Eine unbehandelte Exception halte ich daher für sehr ungünstig.

herbivore

eine geplante ausnahme ist ein widerspruch in sich.
das ist eines der ganz ganz großen designfehler.

niemals eine ausnahme zum normalen logischen ablauf eines programmes verwenden. und das 3malige eintippen eines falschen passworts ist eine normaler ablauf der software. da hat eine exception ncihts zu suchen.

Hallo JAck30lena,

hm, geplante Ausnahme. Sind nicht alle Ausnahmen gleichermaßen geplant oder ungeplant - wie man es eben gerade sieht? Wenn ich eine Datei öffnen will, die nicht vorhanden ist, bekomme ich eine Exception. Das ist natürlich in gewissen Sinne ungeplant. Aber die Programmier der Open-Methode werfen die Exception natürlich schon geplant, in einem bestimmte Fall, nämlich einer Ausnahmesituation. Was nun aber Normalfall oder Ausnahmesituation ist, hängt von der Betrachtungsweise ab. An sich ist es durchaus ok, eine Exception zu schmeißen, wenn eine bestimmte Berechtigung nicht vorliegt.

Ich denke also, dass dein Argument hier nicht zieht.

Im Ergebnis sind wir uns aber trotzdem einig. Hier hat sich jemand in seinem Design verwickelt und stellt deshalb unnötiger- und ungünstigerweise erst tief unten fest, dass etwas nicht geht und versucht nun einen Befreiungsschlag. Deshalb finde ich hier Exceptions, erst recht unbehandelte genauso schlimm (oder noch ein bisschen schlimmer) als Environment.Exit. Stattdessen sollte das Design geändert werden.

herbivore

wenn der entwickler eine file öffnen will, die nicht existiert, ist das eine ausnahme. die entwickler des frameworks haben deshalb die methode .Exists erschaffen, damit der entwickler prüfen kann, ob er das auch machen darf was er da vor hat. das selbige gilt für benutzerrechte.

die open-methode soll ja nur einen stream auf die file aufmachen. implizit anzunehmen, das die openmethode auch die existenz und rechte prüft, ist meiner meinung nach nciht optimal, da in einem fehlerfall (rechte nciht vorhanden oder file nichtexistent) als normaler weg dann nur noch die rückgabe von "null" möglich wäre. was aber zur folge hat, das man nciht weiß warum das nicht funktioniert hat.

speziell bei der open-methode erleichtert uns das framework vieles, nimmt uns aber doch nicht alles ab.

ps: ansonsten gäbe es ja eine TryOpen(...) methode.