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
