Anwendung die sich selbst aktualisieren kann.

https://github.com/ProgTrade/nUpdate/blob/master/nUpdate.Administration/Core/AesManager.cs

Auch wenn "Profis" noch statische Salts verwenden? :-]
(Kommt es sehr drauf an? Nein. Ist es imperfekt? Ja.)
Gegenfrage: Was ist schon perfekt? In diesem speziellen Anwendungsfall ist ein statischer Salt für den PRNG durchaus in Ordnung, vorallem weil ja das Passwort hauptsächlich als Salt verwendet wird. Ja, ich fände es auch schöner, wenn man es konfigurieren könnte, aber es muss nicht. AES ist hier vollkommen ausreichend und aus Sicherheitstechnischer Sicht habe ich an der Klasse nichts auszusetzen.

Und das habe ich nach wenigen Minuten gefunden - abgesehen von der Verwendung von FTP, was fast noch schlimmer ist...
FTP ist leider eine Altlast, die man aber auch unterstützen muss, wenn man ein generisches Tool anbietet. Viele Dienste laufen immer noch über FTP, vorallem im Enterprise Umfeld. Da ist HTTPS oder FTPES schon eher die Seltenheit. Wichtiger ist da eher die Prüfung, ob das Paket auch wirklich von den Entwicklern kommt (Signatur) und auf dem Transportweg nicht verändert wurde. Das Framework zwingt dich ja nicht dazu plain FTP zu nutzen, es unterstützt es ja nur als Option. Steht auch als "not recommended" dabei, man sollte eher FTP mit TLS verwenden.

Was mich an dem Tool eher stört / was ich unschön finde: Der Zwang auf SHA512 (ok, das kann schon so sein) und RSA-8192. RSA ist extrem teuer, vorallem mit solchen Keygrössen. Ältere Geräte (Clients) dürften damit schnell überfordert sein. Ich würde es begrüssen wenn man die Grösse konfigurieren könnte, oder noch besser ECDSA verwenden könnte.

Und generell:
Jeder darf alles schreiben, anderenfalls kann man ja nie was lernen. Alleine vom Bücher lesen lernt man nicht alles, hierzu muss man selbst Code schreiben. Man braucht hier aber auch gesunden Menschenverstand und muss unterscheiden, was man wo und wie einsetzt. Meine Erfahrung habe ich genau daher. Selber schreiben, aber nur einsetzen wenn ich die Materie, Konzepte und das "warum genau so?" auch wirklich verstehe. Ein RFC umsetzen kann (fast) jeder, aber das ganze auch sicher zu machen ist eine andere Baustelle.

Wenns um Produktivcode geht das Rad nicht neu erfinden, sondern bestehende, etablierte und getestete Lösungen verwenden. Spart Zeit, Geld und Nerven.

Grüsse,
BK
 
Gegenfrage: Was ist schon perfekt? In diesem speziellen Anwendungsfall ist ein statischer Salt für den PRNG durchaus in Ordnung, vorallem weil ja das Passwort hauptsächlich als Salt verwendet wird.
Das Passwort wird als Input zur Generierung eines Hashwerts benutzt. Und eben UM Rainbowtables zuverhindern, unterstützt der PRNG einen Salt/IV-Input. Der Code nimmt aber immer den gleichen Salt für alle Benutzer.
Wenn nun genügend Leute die Bibliothek verwenden, lohnen sich Rainbowtables, der Sinn des Salt wurde also effektiv begraben.
AES ist hier vollkommen ausreichend und aus Sicherheitstechnischer Sicht habe ich an der Klasse nichts auszusetzen.
AES(-CBC), was bei .NET der Default ist, ist tatsächlich ziemlich stark, und das habe ich auch nie bezweifelt.
Am Wichtigsten ist hier die Unmöglichkeit der Invertierung, aber durch die schwache Key-Generierung (Rainbowtable) und die Annahme, dass ein Grossteil der Passwörter in Richtung "Passwort" gehen, gibt es durchaus ein Risiko von Brute-Force: Wenn man das richtige Passwort erraten kann, ist auch AES wirkungslos.

Ja, ich fände es auch schöner, wenn man es konfigurieren könnte, aber es muss nicht.
Gleichzeitig muss es ja nicht HTTPS sein, es muss auch kein Backup erstellt werden und man kann seinen Updater auch selbst schreiben.
Es ist eine unnötige (und vergleichsweise sinnlose) Einsparung an Komplexität / Datenmenge, was dem Anspruch, ein "sicherer" Updater zu sein, schlicht nicht Genüge tut. Wenn schon, denn schon.

FTP ist leider eine Altlast, die man aber auch unterstützen muss, wenn man ein generisches Tool anbietet.
"Wir sind besser, weil sicherer. Das Unsichere müssen wir nur verwenden, um funktional zu sein".
Ich habe kein Problem mit einer Bibliothek, die ein Updater sein will. Ich finde es nur bedenklich, einen Artikel zu schreiben, wie schlecht es ist, sowas selbst zu machen, und dann selbst Abkürzungen zu nehmen.

Was mich an dem Tool eher stört / was ich unschön finde: Der Zwang auf SHA512 (ok, das kann schon so sein) und RSA-8192.
Darüber bin ich auch gestolpert, aber sicherheitstechnisch lässt sich da nichts sagen (auch wenn es völlig überdimensioniert für seinen Zweck ist).

Jeder darf alles schreiben, anderenfalls kann man ja nie was lernen. Alleine vom Bücher lesen lernt man nicht alles, hierzu muss man selbst Code schreiben. Man braucht hier aber auch gesunden Menschenverstand und muss unterscheiden, was man wo und wie einsetzt. Meine Erfahrung habe ich genau daher. Selber schreiben, aber nur einsetzen wenn ich die Materie, Konzepte und das "warum genau so?" auch wirklich verstehe. Ein RFC umsetzen kann (fast) jeder, aber das ganze auch sicher zu machen ist eine andere Baustelle.
Ein Updater gehört definitiv nicht in die Kategorie "besser nicht selber machen".
Kryptographie (Algorithmen und Code) ist mir viel zu heiss, bei Netzwerkcode ist mir ein bisschen unwohl, und alles andere ist hauptsächlich aus Effizienzgründen besser mit einer existierenden Bibliothek zu vollbringen. Aber die wahre effiziente Eleganz von heutigen Computern sieht man auf Assemblyebene; man steckt einfach unverhältnismässig viel Zeit hinein. Aber Faktor 4-5 an Steigerung konnte ich schon ein paar mal durch solche Optimierungen erreichen, und Bibliotheken nehmen einem diese Möglichkeit.

Wenns um Produktivcode geht das Rad nicht neu erfinden, sondern bestehende, etablierte und getestete Lösungen verwenden. Spart Zeit, Geld und Nerven.
Gegenbeispiel: Microsoft's SSL Implementierung hat bei Heartbleed MS sehr viel Ärger erspart, da es diese Lücke dort nicht gab. (Die Motivation dafür war wohl eine ganz andere, aber naja...)
Umgekehrt war es beim TCP-Bug(?) ja so, dass man aufgrund desselben Fehlers in BSD-(?) und Windows-Code annahm, dass Microsoft Teile des BSD(?)-TCP-Stacks kopierte.

In der Informatik gibt es die Seuche, dass sich alles verklumpt: Es wird selten experimentiert (gerade in den grossen Firmen), hauptsächlich wegen der Erklärungsnot: Wenn etwas schiefgeht und man die Branchenübliche Software verwendet, ist selten der Chefeinkäufer / verantwortliche Informatiker schuld (oder die Schuld wiegt weniger schwer), da man ja den "Standard" verwendet hat.
Wenn jemand aber eine weniger oft verwendete Software einsetzt, dann stellt man schnell die Frage, ob das denn nicht die Schuld des Informatikers ist, da er ja etwas spezielleres/anderes als den Defacto-Standard verwendet hat.

Und viele Bibliotheken / Frameworks / dergleichen sind zwar sehr allgemeingültig und auf vielen Systemen einsetzbar, dafür aber nicht optimal auf das System abgestimmt. Ein gutes Beispiel dafür ist Vulkan / DX12, was gerade aus der Not entstanden ist, dass sich die Hardware geändert hat, sodass die Schnittstellen angepasst werden mussten. OpenGL dagegen ist noch immer sehr präsent, gerade auf älterer Hardware.

Und auch hier gilt: Irgendwer muss die Bibliotheken auch mal schreiben. Indem man dem "Nachwuchs" sagt, dass er Um Himmels Willen bitte ja mal gar nicht in Betracht ziehen solle, etwas selbst zu machen, vertriebt man die Experimentierfreude.
Ich selbst hatte nicht das Glück, die Anfänge der PCs mitzuerleben, aber die Geschichten vom "Hacken" des alten, weniger sicheren Internets und das mühsame einprogrammieren der IRQs für Steckkarten ohne Plug&Play sind Erfahrungen, die einem sehr viel beibrachten. Heutzutage ist alles "Aber bitte nicht anfassen", Windows & MacOS sagen "lass das mal besser, du verletzt dich doch nur".

Dass ein Anfänger nicht mit einer 23''-Kreissäge beginnen sollte, ist klar, aber warum sollte man jedes Messer und jeden scharfkantigen Gegenstand gleich wegschliessen, dem armen Kerl den Kopf tätscheln und sagen: "Fass das nicht an, das ist böse. Hier, nimm dieses Gummimesser mit Plüschüberzug, damit du dich ja nicht verletzt, und falls du die Funktionalität eines Messer brauchst, lass andere das machen".
Das ist schlicht nicht nachhaltig.

Meine Meinung.

Gruss
cwriter
 
Hi,

das ganze entwickelt sich zu einer meiner Meinung nach sehr interessanten Diskussion und genau dafür schätze ich tutorials.de so sehr :)

Das Passwort wird als Input zur Generierung eines Hashwerts benutzt. Und eben UM Rainbowtables zuverhindern, unterstützt der PRNG einen Salt/IV-Input. Der Code nimmt aber immer den gleichen Salt für alle Benutzer.
Wenn nun genügend Leute die Bibliothek verwenden, lohnen sich Rainbowtables, der Sinn des Salt wurde also effektiv begraben.
Soweit ich das auf die schnelle gesehen habe wird das Passwort lediglich für den RSA Schlüssel verwendet bzw. für das Administrations-Tool. Wer hier ein schwaches Passwort wählt dem gehört es nicht anders.

Gleichzeitig muss es ja nicht HTTPS sein, es muss auch kein Backup erstellt werden und man kann seinen Updater auch selbst schreiben.
Es ist eine unnötige (und vergleichsweise sinnlose) Einsparung an Komplexität / Datenmenge, was dem Anspruch, ein "sicherer" Updater zu sein, schlicht nicht Genüge tut. Wenn schon, denn schon.
Man muss hier halt immer zwischen sinnvoller Komplexität (und Sicherheit) und Paranoia unterscheiden. Wenn die Nutzlast "public" sein darf und Änderungen durch eine Signatur verhindert werden, why not? Worin genau besteht der Vorteil Binärdaten (die sowieso jeder sehen und herunterladen darf) zu verschlüsseln? Ich bin auch eher der "encrypt everything" Typ und habe auch überall HTTPS nach dem aktuellsten "best practise" am Laufen. Aber ich verstehe auch dass HTTPS auf einer hoch frequentierten Seite (wie dieses Forum hier) auch schnell zum Problem werden kann. Durch HTTP kannst du aber keine reine Signatur implementieren, das ist im Protokoll nicht vorgesehen. Selbiges gilt für FTP. Von daher bleibt dir in diesem Umfeld nur SSL/TLS um die Integrität der Daten zu gewährleisten. Bei einem Updater jedoch kannst du das als Aufsatz auf HTTP sehen für die Integrität, der Sicherheit der angebotenen Funktion schadet das nicht.

"Wir sind besser, weil sicherer. Das Unsichere müssen wir nur verwenden, um funktional zu sein".
Ich habe kein Problem mit einer Bibliothek, die ein Updater sein will. Ich finde es nur bedenklich, einen Artikel zu schreiben, wie schlecht es ist, sowas selbst zu machen, und dann selbst Abkürzungen zu nehmen.
Das Programm warnt davor normales FTP zu nehmen, wobei das einfach betrachtet eigentlich egal sein sollte. Wie gesagt, es geht hier um die Signatur und nicht das Verschlüsseln der Daten an sich. Das Tool nimmt hier auch keine Abkürzung, es schafft Kompatibilität um auch einem möglichst breiten Publikum einen sicheren Update-Algorithmus zur Verfügung zu stellen.

Aber die wahre effiziente Eleganz von heutigen Computern sieht man auf Assemblyebene; man steckt einfach unverhältnismässig viel Zeit hinein. Aber Faktor 4-5 an Steigerung konnte ich schon ein paar mal durch solche Optimierungen erreichen, und Bibliotheken nehmen einem diese Möglichkeit.
Nicht zwangsweise. Solange die Bibliotheken OpenSource sind kannst du auch per Pull-Requests Änderungen und Optimierungen vorschlagen. Aber ich verstehe deinen Punkt, eben diese Optimierungen hat man normalerweise nicht auf dem Schirm. Aber auch das ist eine relativ wichtige Erfahrung; Auch Bibliotheken sind nicht perfekt und können Fehler oder Opimierungspotenzial enthalten.

In der Informatik gibt es die Seuche, dass sich alles verklumpt: Es wird selten experimentiert (gerade in den grossen Firmen), hauptsächlich wegen der Erklärungsnot: Wenn etwas schiefgeht und man die Branchenübliche Software verwendet, ist selten der Chefeinkäufer / verantwortliche Informatiker schuld (oder die Schuld wiegt weniger schwer), da man ja den "Standard" verwendet hat.
Wenn jemand aber eine weniger oft verwendete Software einsetzt, dann stellt man schnell die Frage, ob das denn nicht die Schuld des Informatikers ist, da er ja etwas spezielleres/anderes als den Defacto-Standard verwendet hat.
Das ist in der Tat ein auch mir bekanntes Problem. Aber nur weil man es selber macht enthält die Software nicht weniger Fehler. Mit jeder geschriebenen Zeile Code steigt die Wahrscheinlichkeit einen Bug einzuführen. Gleichzeitig steigen die Kosten für die Wartung, weil die Firma mehr Code betreuen, entwickeln und Testen muss. Hierfür braucht man auch Personal, welches an anderen Stellen dringender benötigt wird. Bei einer weit verbreiteten / aktuellen Bibliothek hingegen kannst du dir sicherer sein, dass das Ding getestet wurde und das macht was es sagt. Natürlich können hier auch Fehler drin sein, aber die Wahrscheinlichkeit ist geringer. Heartbleed ist zwar ein Extrembeispiel, aber anders betrachtet würde ich keinem Kollegen zutrauen das Ding ohne Fehler zu schreiben.

Und auch hier gilt: Irgendwer muss die Bibliotheken auch mal schreiben. Indem man dem "Nachwuchs" sagt, dass er Um Himmels Willen bitte ja mal gar nicht in Betracht ziehen solle, etwas selbst zu machen, vertriebt man die Experimentierfreude.
Darauf wollte ich nicht hinaus; Der Nachwuchs soll auf alle Fälle selber Code schreiben, aber nicht "einfach so". Bei Hobby-Programmierern (und auch Studenten) habe ich immer öfter den Eindruck, dass diese oft einfach so drauf los programmieren und meinen genau zu wissen, was sie tun. Eventuell noch veraltete Tutorials aus dem Netz (besonders Schlimm: mysql + php) und kein Feedback von anderen, erfahrenen Entwicklern einholen. Natürlich muss man auch mal neue Wege gehen und rumspielen. Aber hierfür braucht man erst einmal Erfahrung mit der Sprache und ein Verständnis, wie das bisherige funktioniert. Nur wenn man versteht, wie genau und warum etwas bisher so funktioniert hat, dann kann man es auch besser machen. Beispiel OAuth2; Sieht auf den ersten Blick unnötig kompliziert aus. Versteht man aber die Hintergründe, warum das so designed wurde, dann sieht man dass es exakt das macht, was es soll.

Ich selbst hatte nicht das Glück, die Anfänge der PCs mitzuerleben, aber die Geschichten vom "Hacken" des alten, weniger sicheren Internets und das mühsame einprogrammieren der IRQs für Steckkarten ohne Plug&Play sind Erfahrungen, die einem sehr viel beibrachten. Heutzutage ist alles "Aber bitte nicht anfassen", Windows & MacOS sagen "lass das mal besser, du verletzt dich doch nur".
Leider bin ich auch zu spät hierfür geboren, war sicherlich eine sehr interessante Zeit.

Grüsse,
BK
 
das ganze entwickelt sich zu einer meiner Meinung nach sehr interessanten Diskussion und genau dafür schätze ich tutorials.de so sehr :)
Gleichfalls. :)

Soweit ich das auf die schnelle gesehen habe wird das Passwort lediglich für den RSA Schlüssel verwendet bzw. für das Administrations-Tool. Wer hier ein schwaches Passwort wählt dem gehört es nicht anders.
Wie gesagt: Selbst ohne variierendem Salz ist es nicht gerade sehr billig, Rainbowtables zu erstellen, aber der Aufwand steigt ins Unermessliche, wenn man für jede Nutzergruppe neue Tabellen anlegen muss, während der Implementierungs- und Laufzeitaufwand minimal sind. Es ist schlicht am falschen Ende gespart.
Und "lediglich" für den privaten, hochgeheimen Schlüssel? :D

Man muss hier halt immer zwischen sinnvoller Komplexität (und Sicherheit) und Paranoia unterscheiden. Wenn die Nutzlast "public" sein darf und Änderungen durch eine Signatur verhindert werden, why not? Worin genau besteht der Vorteil Binärdaten (die sowieso jeder sehen und herunterladen darf) zu verschlüsseln?
Eine öffentliche Nutzlast muss aus Sicht des Servers (bzw. der Partei, die die Daten zur Verfügung stellt) nicht geheim sein, nein.
Aber aus Sicht des Clients kann ich mir schon einige Szenarien vorstellen, wo das von Interesse sein kann, z.B. wenn man nicht will, dass jemand weiss, was heruntergeladen wird. Das Problem ist natürlich sehr viel komplexer als eine einfache Verschlüsselung, da statistische Analysen auf Datenmengen u.ä. möglich sind, aber es wäre ein erster Schritt.
Und AES ist durch breite Hardwareunterstützung schon fast gratis geworden; RSA ist da wesentlich teurer, wird aber auch nicht für grosse Datenmengen, sondern praktisch nur für den Schlüsselaustausch verwendet.

Aber ich verstehe auch dass HTTPS auf einer hoch frequentierten Seite (wie dieses Forum hier) auch schnell zum Problem werden kann. Durch HTTP kannst du aber keine reine Signatur implementieren, das ist im Protokoll nicht vorgesehen. Selbiges gilt für FTP. Von daher bleibt dir in diesem Umfeld nur SSL/TLS um die Integrität der Daten zu gewährleisten. Bei einem Updater jedoch kannst du das als Aufsatz auf HTTP sehen für die Integrität, der Sicherheit der angebotenen Funktion schadet das nicht.
Auf dem Applicatiion-Layer schon nicht - aber IPSec kann Computer authentizieren, sodass auch HTTP-Verbindungen "sicher" sein können.

Das Programm warnt davor normales FTP zu nehmen, wobei das einfach betrachtet eigentlich egal sein sollte. Wie gesagt, es geht hier um die Signatur und nicht das Verschlüsseln der Daten an sich. Das Tool nimmt hier auch keine Abkürzung, es schafft Kompatibilität um auch einem möglichst breiten Publikum einen sicheren Update-Algorithmus zur Verfügung zu stellen.
Ich dachte eher an die serverseitige Problematik. Dann hat man die Daten auf dem Server, hat sein Passwort, ist ein bisschen unachtsam und greift aus der Ferne auf den Server zu und schon hat jemand das Passwort.
Dann ist es besonders praktisch, wenn man noch den privaten Schlüssel auf dem Server hat:
https://www.golem.de/news/https-private-schluessel-auf-dem-webserver-1707-128860.html

Ja, es müsste relativ viel zusammenkommen, aber ein bisschen Regen, Reifen ohne Profil und eine ruckartige Lenkbewegung reichen auch. Warum nicht gute Reifen verwenden, statt das ganze Auto zu Schrott zu fahren?

Aber nur weil man es selber macht enthält die Software nicht weniger Fehler. Mit jeder geschriebenen Zeile Code steigt die Wahrscheinlichkeit einen Bug einzuführen.
Dem ist so. Kann man aber auf alles beziehen: Mit jedem gefahrenem Kilometer steigt die Wahrscheinlichkeit, einen Unfall zu haben. Mit jedem getrunkenen Bier steigt das Risiko, gesundheitliche Schäden davonzutragen.
Es ist kein Problem, das sich auf die Informatik beschränkt.

Gleichzeitig steigen die Kosten für die Wartung, weil die Firma mehr Code betreuen, entwickeln und Testen muss.
Aufgrund mangelhafter Datenlage: Wie oft muss alter Code (> 1 Jahr) nochmals betrachtet werden? Wie oft muss er umgeschrieben werden?

Hierfür braucht man auch Personal, welches an anderen Stellen dringender benötigt wird.
Ja, bei Bibliotheken ist es so wie bei der Sicherheit: Man sieht keine neuen Features und es kostet nur Geld :)
Wenn es funktioniert, dann nimmt man es nicht wahr, wenn nicht, bricht die Hölle los.

Darauf wollte ich nicht hinaus; Der Nachwuchs soll auf alle Fälle selber Code schreiben, aber nicht "einfach so". Bei Hobby-Programmierern (und auch Studenten) habe ich immer öfter den Eindruck, dass diese oft einfach so drauf los programmieren und meinen genau zu wissen, was sie tun. Eventuell noch veraltete Tutorials aus dem Netz (besonders Schlimm: mysql + php) und kein Feedback von anderen, erfahrenen Entwicklern einholen.
Das ist interessant, meine Erfahrung ist eher umgekehrt: Es wird eher kein Code geschrieben, weil es entweder nur sehr eingeschränkt von der Uni verlangt wird oder schlicht als "zu mühsam" erachtet wird.
Aber du erwähnst einen wichtigen Punkt: Feedback von anderen, erfahrenen Entwicklern einholen.
Genau das ist immer wichtig, wenn man herumspielen will. Immer hinterfragen, und wenn man die Antwort nicht kennt, nachfragen.
Aber das "Anfänger sollen das nicht" und "Anfänger sollen dies nicht" führt nicht zum Ziel.
Die Schwierigkeit ist natürlich, das Verantwortungsbewusstsein zu wecken. Wenn die Erfahrenen warnen und Hinweise geben, und diese dann schlicht ignoriert werden, dann ist es tatsächlich besser, zu sagen, dass das kein Thema für Anfänger ist.
Allerdings wurde das "Unter Aufsicht" plötzlich zu "Unter keinen Umständen", was nicht sinnvoll ist. Lasst die Leute ins Messer laufen, lasst sie die Erfahrung machen, solange sie lernen, idealerweise in kontrollierter Umgebung.
Der Code im Netz ist häufig Müll, gerade die erweiterten "Lernvideos" usw. Kürzlich habe ich eines gesehen, wo sowas stand:
C:
if(a == 0 || 3)
Aber, um ehrlich zu sein, ist das ja kein neues Phänomen. Wer nur Bücher liest, ohne sich mit anderen darüber zu unterhalten, der wird sich zwangsläufig einige Marotten aneignen. Aber da die Forenkultur ja verschwindet und von der Kommentarkultur abgelöst wird, bezweifle ich, dass es sich in nächster Zeit bessern wird.

Natürlich muss man auch mal neue Wege gehen und rumspielen. Aber hierfür braucht man erst einmal Erfahrung mit der Sprache und ein Verständnis, wie das bisherige funktioniert. Nur wenn man versteht, wie genau und warum etwas bisher so funktioniert hat, dann kann man es auch besser machen. Beispiel OAuth2; Sieht auf den ersten Blick unnötig kompliziert aus. Versteht man aber die Hintergründe, warum das so designed wurde, dann sieht man dass es exakt das macht, was es soll.
Ja, und genau diese Einblicke bekommt man richtig gut, wenn man so etwas selbst zu schreiben versucht.

Gruss
cwriter
 
Zurück