Kritikallergiker



  • otze schrieb:

    Wie gesagt, manchmal geht es nicht anders. Irgendwann muss sich das Programm bei einer Datenbank anmelden und dort das Passwort senden.

    Quatsch. Da kann die Datenbank auch gleich gar kein Passwort verlangen, ist ähnlich sicher. Insbesondere interessiert niemanden wie kompliziert das im Quellcode aussieht, ein Passwort das über's Netzwerk geschickt wird wird einfach mitgesnifft. Ich kann TyRoXx nur recht geben. Ich würde jetzt sagen der Artikel ist eine Schande für Codeproject, aber na ja, wie schon richtig angemerkt wurde, es ist eben Codeproject, was soll man da schon groß erwarten. Hätte er es auf security/crypto.stackexchange.com gepostet, sähen die Kommentare auch ganz anders aus. Kopierschutz ist im Übrigen ein völlig anderes Thema als Passwörter, nur mal so nebenbei.

    @TyRoXx Nein, deine Standards sind sicher nicht zu hoch. Dein Fehler war es, etwas auf Codeproject zu lesen. :xmas1:



  • Bei CodeProject gibts zwar viele schlechte Artikel, aber auch viele gute und nützliche Komponenten, allerdings vor allem für C#. So lang man weiß, was man tut, ist es eine sehr gute Seite.

    Ich muss otze Recht geben und nicht TyRoXx. Es gibt einfach "Strings", wo man nicht drum rum kommt, sie irgendwo zu speichern. Es geht doch gar nicht um Passwörter, die ein Benutzer eingeben kann. Es könnte z.B. die URL sein, von der das Programm die Updates bekommt (ja, die kriegt man dann spätestens mit einem Sniffer raus, schon klar), oder irgendwelche internen Benuternamen, Pfade, Algorithmennamen, Kategorien, Zertifikate, was weiß ich was. Ob man sie direkt in der exe speichert oder in einer Config Datei spielt keien Rolle. Ab und zu will man sowas eben verschleiern und mehr als Obfuscation geht da nicht. Und genau das beschreibt sein Artikel. Er schreibt ja auch genau, was es macht, nicht mehr und nicht weniger. Da macht es keinen Sinn, drauf rumzureiten, wie unsinnig es ist, Passwörter in einer exe zu speichern oder sonst was. Wenn ihr das nicht benutzen wollt, benutzt es halt nicht.



  • Ich bin offen für einen guten Artikel mit C|C++. Noch habe ich keinen gefunden. 😉
    Es läuft doch immer auf's Selbe hinaus. Der Aufwand sowas zu knacken geht gegen 0. Also kann man's auch gleich sein lassen. Oder, wenn schon, sowas wie xor nehmen. Da fangen dann Leute zumindest nicht an zu denken, sie hätten irgendeine Art von Sicherheit.

    Mechanics schrieb:

    Da macht es keinen Sinn, drauf rumzureiten, wie unsinnig es ist, Passwörter in einer exe zu speichern oder sonst was.

    Wenn ein "security expert" dieses Verfahren als sicher genug beschreibt um uU sensible Informationen auf diese Art in eine .exe einzubetten, führt das potentiell zu schlechter bzw. unsicherer Software von Leuten die dem Glauben schenken. Insofern macht es sehr wohl Sinn darauf herumzureiten.



  • Du hättest dich aber vorher besser mit dem Ziel der ganzen Aktion auseinandersetzen sollen. Es hat durchaus seinen Sinn, Strings vor den Benutzern verstecken zu wollen, natürlich nicht bei freier Software, aber bei allem, wo z.B. Lizenzschlüssel versteckt werden sollen. So hast du dein ganzes Pulver damit verschossen, das was du nicht verstehst anzugreifen, und ihm damit Gelegenheit gegeben, deine Kritik als unsachlich abzustempeln.

    Das ganze ist im Wesentlichen nicht besser als die Strings mit irgendwas zu verXORen, d.h. wer die Strings lesen will schafft das auch ohne größere Probleme. Die Idee, den AES-Key per rand zu generieren ist haarsträubend -- der Key hängt ja dann nur vom Seed ab (und woher kommt der Seed beim Decode?) Insgesamt habe ich den Eindruck (auch gerade wegen seines Insistierens, dass das total sicher sei wegen AES), dass es mit seiner Security-Expertise nicht weit her ist.



  • Aus meiner Sicht interpretiert ihr einfach zu viel in seine Aussagen hinein. Er billigt es nicht und er schlägt es auch nicht vor. Aber er akzeptiert es, dass es Fälle gibt, wo es sich nicht vermeiden lässt, und da ist seine Lösung besser als nichts.
    Und zwar viel besser. 99% der potenziellen "Hacker" durchsuchen die exe einfach nach lesbaren Strings. Es ist unglaublich viel mehr Aufwand erforderlich, das Programm erstmal zu disassemblieren, zu verstehen, die entsprechenden Stellen überhaupt zu finden. Das können schon sehr viel weniger Leute und den Aufwand wird sich auch ziemlich sicher niemand machen. Da brauchst du jetzt auch nicht wieder an irgendwelche Profi Cracker zu denken. Denk einfach an Konkurrenten oder auch Kunden, die keine Implementierungsdetails erfahren sollen. Es ist noch vorstellbar, dass die mal schnell nach lesbaren Strings in der exe suchen, aber da wird sich niemand gut genug auskennen, um seine Obfuskierung zu knacken, und die werden auch sicher niemanden beauftragen, das zu tun.
    Daher hat der Typ jetzt eine durchaus brauchbare Lösung für reale Problemfälle vorgeschlagen. Sie löst nicht viele Probleme, aber das eine Problem löst es ausreichend gut.



  • solche sachen beherrscht doch jeder halbewgs moderne kopierschutz. da muss man nicht an iwelchen strings in seinem code rumfrickeln, sonderen das wird meist automatisch gemacht.

    um die auszuhebeln brauchst dann erst mal als mindestausrüstung ein ollydbg mit plugins, die man auch erst suchen muss und dann ein speicherabbild des laufenden programms und selbst das haut es dir dann regelmäßig um die ohren (so war das zumindest bei mir).

    alles in allem kann ich mir nicht vorstellen, dass ieine software so toll wär, dass sie das nötig hätt (meine zumindest nicht 😉 ).



  • Das Hauptproblem dürfte sein, dass er seine Lösung als absolut anpreist.

    Wer hochkritische Daten verschleiern will (wenn auch nur für ihn hochkritisch) der könnte dadurch in falscher Sicherheit gewogen werden.

    Und vor allem ist das ja auch ein entsprechender Overhead, der wohl kaum bei jedem String notwendig sein wird



  • Mechanics schrieb:

    Aus meiner Sicht interpretiert ihr einfach zu viel in seine Aussagen hinein.

    Er schreibt doch eindeutig, dass man z.B. Datenbankpasswörter damit in eine .exe einbetten könnte. Da gibt es nichts zu interpretieren.

    Mechanics schrieb:

    Er billigt es nicht und er schlägt es auch nicht vor.

    Natürlich macht er das, sonst hätte man den Artikel ja nicht schreiben müssen.

    Mechanics schrieb:

    Aber er akzeptiert es, dass es Fälle gibt, wo es sich nicht vermeiden lässt,

    Wo wir schon mal beim Thema sind. Wann muss ein Programm eigentlich ein Passwort für eine Datenbank halten, auf die der Besitzer des Programms keinen Zugriff haben darf? Sinn? 🤡 (Ist eine ernst gemeinte Frage, vielleicht gibt es ja was, aber mir fällt auf Anhieb nichts ein.)

    und da ist seine Lösung besser als nichts.

    Und doch ist sie wahrscheinlich schlechter als der TMP-XOR Kram den Sone hier irgendwann mal verzapft hat. 😉



  • cooky451 schrieb:

    Wo wir schon mal beim Thema sind. Wann muss ein Programm eigentlich ein Passwort für eine Datenbank halten, auf die der Besitzer des Programms keinen Zugriff haben darf? Sinn? 🤡 (Ist eine ernst gemeinte Frage, vielleicht gibt es ja was, aber mir fällt auf Anhieb nichts ein.)

    Es ist vielleicht nicht das beste Beispiel. Auch dafür könnte ich mir aber was vorstellen. Vielleicht ist es ein Service Account auf den Servern des Anbieters. Es ist ein Programm für einen oder paar wenige Kunden, und das muss z.B. crash dumps oder ähnliches auf den Server hochladen, oder bug reports in der Datenbank des Herstellers speichern. Irgendwo müssen die Zugangsdaten ja gespeichert sein, heißt aber nicht, dass der Benutzer damit rumspielen soll. Das wäre hier eine Lösung, die sicher genug ist.
    Oder es werden bestimmte Optionen oder Keys geprüft, wo der Benutzer u.U. einfach draufkommen könnte, dass er einfach was in eine Config oder in der Registry eintragen muss und schon hat er einen Mehrnutzen davon. Man verkauft z.B. eine Lizenz, die es erlaubt, 500 000 Dateien zu importieren. Irgendwo muss man speichern, wieviele man schon importiert hat, und wenn der Pfad/Registry Key oder ähnliches im Klartext in dem Binary steht, könnte der Benutzer das vielleicht noch ändern, aber alles andere wäre dann viel zu kompliziert.
    So konstruiert sind solche Fälle nicht. Sowas kommt ständig vor. Es muss dann auch nicht unbedingt 1000% sicher sein, es muss nur ausreichend sicher und billig zu implementieren sein.

    Ob seine Lösung jetzt viel besser als XOR ist, wag ich jetzt auch zu bezweifeln. Auch XOR oder was ähnlich triviales wird für solche Fälle sicher genug sein. Dass er darauf besteht, dass es viel sicherer ist, weil es AES ist, macht vielleicht nicht den besten Eindruck. Trotzdem ist das alles kein Grund, sich dermaßen über ihn und seinen Artikel aufzuregen.



  • Mechanics schrieb:

    Irgendwo müssen die Zugangsdaten ja gespeichert sein, heißt aber nicht, dass der Benutzer damit rumspielen soll.

    Gegen Flooding und unberechtigtes Löschen von Dateien muss der Server ja eh gesichert sein (auch wenn das Passwort bekannt ist), und da kann man das Passwort irgendwie auch gleich in Klartext rein schreiben. Oder aber jedem Kunden einen Public-Key geben, dann kann man bestimmte Kunden zur Not aussperren.

    Mechanics schrieb:

    eine Lizenz, die es erlaubt, 500 000 Dateien zu importieren.

    Das wäre ja dann wieder eine Art Kopierschutz, was für mich wie gesagt ein anderes Thema ist. Aber ich denke mal was die Sicherheit der Aktion angeht sind wir uns einig - und dass selbst die Lösung nicht unbedingt optimal ist, darüber sind wir uns wohl auch einig. Nur die Frage, ob man sich darüber aufregen sollte, bleibt ungeklärt. Ich sage ja, zumindest in einem gewissem Maße. Es vermüllt das Internet (okay, ein Tropfen auf den heißen Stein), aber insbesondere denke ich, er hätte stärker darauf hinweisen sollen und als "security expert" auch müssen, dass das alles nichts weiter als ein kleines Katz- und Mausspiel ist und dass es keinerlei ernsthafte Sicherheit bietet. Stattdessen schreibt er

    can make it next to impossible to guess where the data is kept (encrypted), and even if the data is found, to obfuscate it using strong encryption.

    Dinge die genau das Gegenteil implizieren. Auch wenn "next to impossible" ein sehr dehnbarer Begriff ist, ist das für jemand etwas Unbedarfteren doch mehr als missverständlich, ist das Knacken von AES doch auch nur "next to impossible". Wie soll ein Anfänger denn jetzt daraus lernen, wenn sich niemand darüber aufregt? Indem ihm dann am Ende sein Server (dessen Passwort ja "next to impossible" zu finden war) auseinander genommen wird?

    PS: Ich warte immer noch auf einen brauchbaren C^C++ Artikel. 🤡 :xmas1:



  • Leute, ihr redet leider alle am Problem vorbei.

    Das Problem ist, das der Typ Ami ist und somit angelsächsischen Umgang gewohnt ist, alles was davon abweicht, wie eben TyRoXxs typische deutsche Direktheit wird als Angriff gewertet und deswegen meldet er deinen Beitrag den Admins, denn diese Art des Umgangs kennt er im Amiland nicht

    Du mußt ihm also klar machen, das du Deutscher bist und in Deutschland nicht um den Brei herumgeschönt wird, sondern direkt ohne Rücksicht auf die Emotionen des anderen gesagt wird, was Sache ist.

    Hier sind also Social Skills notwendig, du mußt ihm das schön blumig erzählen.
    Also erstmal loben und sagen, dein Code ist toll, ganz schön, wunderschön usw. so wie die Amis das halt auch machen wenn du im Klamottengeschäft in den USA bist und etwas anprobierst (mag es noch so scheiße aussehen) und die Verkäuferin dann IMMER sagt, dass du damit wunderschön aussiehst und das es perfekt paßt, obwohl es gar nicht stimmt.

    Da muss man also um die Ecke denken, im Ami land wird mehr geschönt und die Wahrheit mußt du indirekt zwischen den Zeilen herauslesen und weil das dort Gang und gäbe ist, mußt du auch als Kritiker so geschönt schreiben, so daß er das Problem, dass du also Deutscher gerne direkt ansprechen würdest, zwischen den Zeilen herauslesen kann.

    Du hast da also leider mit dem Rambock die Tür eingetreten und deswegen will er dich bannen und wirft dir harassment usw. vor, weswegen er dich gerne gesperrt sehen möchte.



  • Stand da nich' was von Israel? :xmas2:



  • Zum Thema Passwörter in der exe zu verschlüsseln: http://img820.imageshack.us/img820/1641/itsfinetrustme.png

    Aber damit ist eigentlich auch alles gesagt. http://xkcd.com/386/ :xmas1:



  • Irgendwie erinnert mich das alles gerade an das Programm Dr. Hardware 2012.^^

    00418162   > 6A 32          PUSH 32                 ; /Arg3 = 00000032
    00418164   . 6A 00          PUSH 0                  ; |Arg2 = 00000000
    00418166   . 68 C81A8800    PUSH DRHARD.00881AC8    ; |Arg1 = 00881AC8 ASCII "RIH4NKIB7IDNH"
    0041816B   . E8 700E4100    CALL DRHARD.00828FE0    ; \DRHARD.00828FE0
    

    🙄 Das war echt zu einfach ...

    Premium 4 free 😃

    :xmas1: :xmas2:

    lol die Comments in dem Artikel auf Codeproject find ich lustig, da wird jemand
    wohl etwas zornig.^^



  • cooky451 schrieb:

    otze schrieb:

    Wie gesagt, manchmal geht es nicht anders. Irgendwann muss sich das Programm bei einer Datenbank anmelden und dort das Passwort senden.

    Quatsch. Da kann die Datenbank auch gleich gar kein Passwort verlangen, ist ähnlich sicher. Insbesondere interessiert niemanden wie kompliziert das im Quellcode aussieht, ein Passwort das über's Netzwerk geschickt wird wird einfach mitgesnifft.

    Schonmal was von SSL/TLS gehört? Oder allgemein von Verschlüsselten Verbindungen?



  • hustbaer schrieb:

    cooky451 schrieb:

    otze schrieb:

    Wie gesagt, manchmal geht es nicht anders. Irgendwann muss sich das Programm bei einer Datenbank anmelden und dort das Passwort senden.

    Quatsch. Da kann die Datenbank auch gleich gar kein Passwort verlangen, ist ähnlich sicher. Insbesondere interessiert niemanden wie kompliziert das im Quellcode aussieht, ein Passwort das über's Netzwerk geschickt wird wird einfach mitgesnifft.

    Schonmal was von SSL/TLS gehört? Oder allgemein von Verschlüsselten Verbindungen?

    Verschlüsselung schützt nur vor Einsicht durch Dritte und nicht wenn ein Endpunkt der Verbindung vom Angreifer kontrolliert wird.



  • Marsi Motolami schrieb:

    hustbaer schrieb:

    cooky451 schrieb:

    otze schrieb:

    Wie gesagt, manchmal geht es nicht anders. Irgendwann muss sich das Programm bei einer Datenbank anmelden und dort das Passwort senden.

    Quatsch. Da kann die Datenbank auch gleich gar kein Passwort verlangen, ist ähnlich sicher. Insbesondere interessiert niemanden wie kompliziert das im Quellcode aussieht, ein Passwort das über's Netzwerk geschickt wird wird einfach mitgesnifft.

    Schonmal was von SSL/TLS gehört? Oder allgemein von Verschlüsselten Verbindungen?

    Verschlüsselung schützt nur vor Einsicht durch Dritte und nicht wenn ein Endpunkt der Verbindung vom Angreifer kontrolliert wird.

    Aber gerade der Sniffer ist der "Dritte".



  • @hustbaer Dein Beitrag passt überhaupt nicht zum Stand der Diskussion. Und ja. 🙄



  • @TyRoXx:
    Der Code tut ja schon vom Anblick weh. Fehlt bloß noch das ein Fehler drin ist, welches man dank Code Obfuscation nicht sieht. Fehlerbehaftet dank Code Obfuscation. 👍

    Übrigens: Kritikallergiker finde ich als schönes Kunstwort. 🙂

    Das Problem ist, das der Typ Ami ist und somit angelsächsischen Umgang gewohnt ist, alles was davon abweicht, wie eben TyRoXxs typische deutsche Direktheit wird als Angriff gewertet und deswegen meldet er deinen Beitrag den Admins, denn diese Art des Umgangs kennt er im Amiland nicht

    Hmm, ich glaube nicht dass das eine Amerika-Problem ist, sondern das eher die Person fachfremd ist, und sich wenig mit der aktuelle Materie auseinander gesetzt hat. Dank seines Lebenslaufs haben die Leute mehr Vertrauen in ihn, als in einen Informatik-Studenten. Nebenwirkungen von Social Skills ?

    Ich habe es schon in einem Forum erlebt dass ein Benutzer meckerte: "Mein Programm verhält sich komisch. Ich nutze es den ganzen Tag, öffne damit mehrere Dateien und abends wird mein Rechner immer langsamer, die Festplatte arbeitet wie verrückt und Windows meckert über zuwenig Arbeitsspeicher bei 4 Gbyte RAM." Mein Kommentar: "Bitte mal an den Support melden. Hört sich nach einem Programmierfehler (Speicherloch) an." Aber, meine Meinung wurde aber als NonSense abgetan, weil es ja nichts unüblich wäre das ein Program dieser Kategorie soviel RAM verschlingen würde. Das Ende des Liedes: es wurde empfohlen einen neuen Rechner mit mindestens 8 GByte RAM zu kaufen...



  • GPC schrieb:

    Marsi Motolami schrieb:

    Verschlüsselung schützt nur vor Einsicht durch Dritte und nicht wenn ein Endpunkt der Verbindung vom Angreifer kontrolliert wird.

    Aber gerade der Sniffer ist der "Dritte".

    ja, der Sniffer bringts auch nicht wenn die Daten verschlüsselt sind. Aber hier gehts ja um das Scenario, dass man die Exe selbst auf seinem PC laufen hat. Und die Exe die man doppelklicken kann, kann man auch im Debugger laufen lassen.

    Siehe auch nochmal das erste Bild was ich gepostet hatte.


Anmelden zum Antworten