Will man in einem Programm sensible Informationen wie z.B. Passwörter schützen so sollte man diese beim Speichern nach Möglichkeit verschlüsseln. Um zu verhindern, dass fremde beim Zugriff auf den PC einfach die Daten kopieren und auf einem anderen PC entschlüsseln können gibt es seit Windows XP die DPAPI (Data Protection API) welche Daten so verschlüsseln kann, dass man diese nur entweder auf dem gleichen PC oder nur mit dem gleichen Benutzeraccount wieder entschlüsseln kann.

Für diese native API gibt es im .NET Framework eine Wrapperklasse mit dem Namen ProtectedData welche sich im System.Security.Cryptography-Namespace befindet. Dazu muss allerdings vorher das Assembly System.Security.dll eingebunden werden. Im folgenden ein kleines Beispiel:

Bei portablen Anwendungen welche auf mehreren Rechnern ausgeführt- und die gleichen Settings verwenden sollen würde ich allerdings auf eine andere Methode setzen, sonst führt das unweigerlich zu Problemen.

Seit dem Release von Stylizer 5 und der dort integrierten Produktaktivierung frage ich mich mal wieder über den Nutzen von solchen Methoden.

Auf der einen Seite steht der Hersteller, der nicht möchte, dass sein Produkt von Leuten verwendet wird, welche nicht über eine entsprechende Lizenz verfügen.
Auf der anderen Seite steht der Kunde der die Software erworben hat und diese zu jeder Zeit und im vollen Umfang nutzen möchte.
Dann gibt es noch eine kleine Gruppe von Leuten, die zu keiner Zeit dazu bereit sind für die Software Geld auszugeben und jede Möglichkeit nutzen die Software auch ohne gültige Lizenz zu betreiben.

Das Ziel des Herstellers ist es nun die letzte Gruppe so klein- und die mittlere Gruppe, die Kunden, so groß wie Möglich zu halten. Bei vielen Herstellern sieht man jedoch bei dem Versuch das gerade erklärte durchzuführen einen Effekt, der sich in die vollkommen andere Richtung entwickelt: Wo der zahlende Kunde noch die Seriennummer eingibt und auf die Gnade des Aktivierungsservers hofft, hat der Raubkopierer schon die Exe ausgetauscht und arbeitet ohne Einschränkungen mit dem entsprechendem Programm.

Als ultimative Sicherungsmethode greifen die Hersteller gerne auf eine Aktivierung über das Internet zurück. Dabei werden i.d.R. die einzelnen Kunden anhand einer Seriennummer identifiziert und diese mitsamt einer oder mehrerer Prüfsummen der Computerhardware (z.B.: MAC-Adresse, Festplatten-ID) auf den Servern des Herstellers gespeichert. Dies soll das mehrfache verwenden der gleichen Seriennummer auf unterschiedlichen Rechnern unterbinden. Im Endeffekt trifft das Onkel Otto der sein Acrobat mit seinem Neffen teilen möchte, jedoch nicht die oben genannte Gruppe von Benutzern die sowieso nicht für die Software zahlen möchten, denn das Aushebeln solch einer Sperre ist nicht mehr oder weniger Aufwändig als das umgehen einer Offlinelösung.

Neben der Notwendigkeit einer Interverbindung birgt solch eine Onlineaktivierung auch noch ganz andere Gefahren, speziell für den Entwickler/Vertrieb. Wer z.B. garantiert dem Käufer, dass es das Unternehmen in 5 Jahren noch gibt und er sein Produkt ordnungsgemäß aktiveren und benutzen kann? Was wenn der Aktivierungsserver nicht erreichbar- und so das Produkt nicht benutzbar ist? Im “besten” Falle verliert man einen Kunden, im schlechtesten Falle ist dem Kunden dabei ein Schaden entstanden und er macht bei dem Vertrieb seine berechtigten Regressansprüche gelten. Wie zu sehen ist, werden mit solch einer Methode dem zahlenden Kunden immer mehr Hürden aufgebürdet bevor er das Produkt benutzen kann wo hingegen der Raubkopierer durchs einfaches Patchen der Anwendung kaum einen Aufwand hat.

Wie würde ich es denn lösen?
Meine Lösung bestünde aus einer Lizenzdatei, in welcher einige persönliche Daten des Lizenzinhabers im Klartext sowie eine RSA Signatur enthalten sind. Diese wird einmalig beim Kauf erstellt und dem Kunden ausgehändigt. Auf Grund der persönlichen Informationen in der Lizenzdatei steigt die Hemmschwelle diese Datei an fremde Leute zu verteilen. Die RSA Signatur schützt vor Manipulation an der Datei, denn ohne den privaten Schlüssel lässt sich keine Signatur erstellen die einer Überprüfung mit dem korrespondierendem öffentlichen Schlüssel in der Anwendung stand hält. Sicherlich lässt sich diese Sicherung auch Aushebeln, aber mit dem gleichen Aufwand der für das Umbiegen der Überprüfung mit dem Onlinedienst notwendig wäre. Nur funktioniert meine Lösung immer und ohne Internet.

Für die kommende Version 1.1 vom updateSystem.NET suche ich ein paar Betatester, welche vor dem offiziellen Release (geplant für Ende dieser Woche) einmal über die Software schauen sollen, um etwaige Patzer aufzuspüren die ich bei meinen Tests übersehen haben könnte.

Interessierte können sich die Betaversion hier herunterladen: updateSystem.NET.Setup.exe

Es bleibt zu erwähnen, dass diese Version nicht für den produktiven Einsatz bestimmt ist. Jede Art von Feedback ist zudem Willkommen.

Alle Änderungen in der Version 1.1 stehen in der Roadmap unter dem Punkt “Implementiert”.

Bisher habe ich bei meinem Anwendungen den Build-Part der Versionsnummer immer selber mit einer kleinen Kommandozeilenanwendung via dem PostBuild-Event im Visual Studio erhöht. Gestern bin ich über das VS Addin Build Version Increment gestolpert welches meine Anwendung Dank einfacher und komfortabler Handhabung abgelöst hat. Pro Projekt lässt sich komfortabel die gewünschte Konfiguration vornehmen, oder es können für alle Projekte die gleichen Einstellungen verwendet werden.

Dieses Addin für das Visual Studio 2005, 2008 und 2010 ermöglicht nicht nur das inkrementieren der Versionsnummer sondern auch das setzen eines TimeStamps. So sind zum Beispiel Versionsnummern in folgendem Format möglich: 1.0.4.614
Die vorletzte Stelle wird pro Buildvorgang um einen Zähler erhöht und die letzte Stelle beinhaltet einen Zeitstempel in Form des aktuellen Monats (6) und des Tages (14).

Auch bei diesem Addin gilt leider wieder: Benutzer der Express Editionen vom Visual Studio schauen in die Röhre, denn Addins werden erst mit den Bezahlversionen unterstützt.

Die Version 1.1 vom updateSystem.NET ist nun so gut wie fertig. Zeit ein wenig die Neuerungen zu erläutern.

Erweiterte Releaseinformationen

Die Informationen über den Releasestatus der Updatepakete wurden mit der neuen Version erweitert. Primär zählt natürlich immer noch die Versionsnummer. Zusätzlich dazu kann noch ein Status des Releases festgelegt werden, also entweder Final, Beta oder Alpha. Den letzten beiden können zu dem Nummern zugewiesen werden, was es ermöglicht zu der gleichen Versionsnummer z.B. mehrere Betaversionen zu veröffentlichen.

Etwas gelitten hat hier leider die Abwärtskompatibilität, da auf Grund der neuen Versionsinformationen die Updatepakete einen neuen Dateinamen benötigen, mit welchem ältere Versionen des updateControllers nichts anfangen können. Aus diesem Grund, ist diese neue Funktionalität bei älteren Projekten deaktiviert. Sie kann über den Menupunkt 'Projektversion upgraden' im updateDesigner nachträglich aktiviert werden, wenn sichergestellt ist, dass alle Clients über die neue Version 1.1 des updateControllers verfügen.

Bedingungen für Updates

In der neuen Version vom updateController gibt es ein neues Event mit dem Namen confirmUpdatePackage. Dieses hat Boolean als Rückgabetyp und wird jedes mal gefeuert, wenn die interne Suche im updateController ein neues Updatepaket gefunden hat, welches neuer ist als die lokale Version. Hier kann der Entwickler nun zusätzlich nach eigenen Gesichtspunkten prüfen ob er das Update dem Benutzer anbieten möchte (Rückgabe: True) oder nicht (Rückgabe: False).

Desweiteren habe ich den Dialog mit den Updatepaketeinstellungen etwas übersichtlicher gestaltet:

Dort sind alle Optionen nun etwas deutlicher erklärt. Wenn alles glatt läuft, ist die neue Version nächste Woche fertig.

Wie versprochen gibt es nun ein Update von dem Ergebnis meines letzten Weekend Coding Stunts,  dem feedCarrier. Vorweg: Einiges was ich selbst auf meiner Todo-List hatte und was mir im nachhinein Vorgeschlagen wurde, konnte ich auf Grund von Zeitmangelns noch nicht umsetzen, aber das wird mit den nächsten Versionen seinen Weg ins Programm finden. Hier nun eine Übersicht aller Neuerungen:

• Im Benachrichtigungsfenster können neue Artikel mit der rechten Pfeiltaste geladen werden.
• Die neuen Artikel sind nun nach Veröffentlichungsdatum sortiert.
• Das Veröffentlichungsdatum wird im unteren Teil des Benachrichtigungsfensters angezeigt.
• Bei den Feedeinstellungen können Benutzerinformationen angegeben, so dass sich auch Feeds herunterladen lassen, welche eine Anmeldung erfordern, wie zum Beispiel die Twitter Timeline.
• Es kann eine Sounddatei ausgewählt werden, welche bei neuen Feeds wiedergegeben wird (derzeit werden nur Sounddateien im Wave (*.wav) Format unterstützt.
• Es gibt eine globale Fehlerbehandlung.
• Der lokale Cache der gelesenen Feeds kann automatisch bereinigt werden um Speicherplatz zu sparen. Diese können entweder nach Datum oder eine bestimmten Anzahl gelöscht werden.
• Die Suche nach neuen Artikeln kann unterbrochen werden wenn der Benutzer den PC nicht benutzt. (Hierzu besten Dank an Thomas der das Feature Vorgeschlagen hat sowie an Tommy der mir den Code für den IDLE-Modus zur Verfügung gestellt hat)
• Das Programm verfügt nun über eine Autoupdate Funktion die dafür sorgt, dass das Programm immer aktuell gehalten wird. Spätere Versionen sind auch über diese zu beziehen.
• feedCarrier kann wahlweise direkt beim Windowsstart gestartet werden.
• Credits im “Über…”-Bereich hinzugefügt.

Die aktuelle Version gibt es hier zum Download: feedCarrier_Beta2.zip

Und wie immer gilt: Featurevorschläge sind ausdrücklich Willkommen, Fehlermeldungen eher weniger aber was muss das muss.

Seit Windows 7 gibt es die sogenannten Jumplists, welche über einen Rechtsklick auf das Programmicon in der Tastbar erreicht werden können und Zugriff auf zum Beispiel oft genutzte Funktionen oder zuletzt geöffnet Dateien bieten.

Wirklich genutzt wird diese neue Funktion derzeit noch von wenigen Programmen. Hier kommt nun der kostenlose Jumplist Extender (alternativer Downloadlink) zum Einsatz: Dieser bietet die Möglichkeit die Jumplists beliebiger Programme zu manipulieren. So kann ich z.B. meinen Musikplayer XMPlay einen Jumplisteintrag zu meiner Lieblingsplaylist hinzufügen um diese mit wenigen Klicks erreichen zu können.

Neben beliebigen Dateien lassen sich auch Ordner öffnen, Tastenkombinationen an das geöffnete Programm senden sowie AutoHotkey-Scripte ausführen, für welche es sogar einen integrierten Editor gibt. [via]

Es ist mal wieder soweit. Nach knapp 5 Monaten habe ich mir wieder einen Weekend Coding Stunt überlegt welchen ich dieses Wochenende umsetzen werden.

Die Anwendung welche ich entwickeln möchte ist nichts besonderes und garantiert nicht einmalig, aber ich möchte mich gerne mit Linq2Xml auseinandersetzen und was  bietet sich da mehr an als ein Feed Reader? Denn wie man weiß sind RSS und ATOM Feeds ja auch nichts anderes als XML-Dateien. Ok, ich plane keinen kompletten Reader sondern viel mehr eine kleine Benachrichtigungsanwendung welche regelmäßig nach neuen Feedeinträgen sucht und eine Vorschau des oder der Artikel anzeigt und diesen bei Interesse dann zum lesen im Browser öffnet.

Bei der Planung habe ich dann festgestellt, dass ich mich zusätzlich zu LINQ noch mit den Observer Pattern auseinandersetzen muss, um zwischen UI- Application- und Feedcontroller interagieren zu können. Mal schauen ob ich das an diesem Wochenende alles unter bekomme, zumindest Linq2Xml sollte nicht so schwer sein, da ich mich in der Vergangenheit schon ein wenig mit LINQ-Queries auseinandergesetzt habe.

Mehr zum Fortschritt dann heute Abend oder Morgen.

Je mehr man im Internet unterwegs ist desto öfter wird man mit der Thematik von Passwörtern konfrontiert. Oft entscheidet man sich dann dafür, für jedes Portal das gleiche Passwort zu verwenden, welches sich auch noch leicht merken lässt. Wie fatal das ist, merkt man in der Regel erst, wenn es zu spät ist und das Passwort entweder durch z.B. ein Datenleck oder eine Unachtsamkeit bekannt geworden ist.

Daher empfiehlt es sich für jede Website bei welcher man sich anmelden muss ein anderes Passwort zu verwenden welches nach Möglichkeit zufällig generiert worden ist. Da einem dabei schnell die Übersicht flöten geht gibt es Passwortmanager wo man sich nur das Masterpasswort merken muss um Zugriff auf alle Passwörter zu erlangen.

Ein solcher Passwortmanager ist das kostenlose, ab der Version 2.0 auf dem .NET Framework 2.0 basierende, Programm KeePass.

Zum einloggen in die Passwortdatenbank bietet KeePass das schon erwähnte Masterpasswort, eine Schlüsseldatei und die Bindung an einen Windows Benutzeraccount an. Die drei Möglichkeit können nach belieben kombiniert werden. Die Passwörter selber lassen sich in Gruppen zur besseren Übersicht anordnen. KeePass kann zudem durch Plugins erweitert werden. Hier ist jedoch Vorsicht geboten, denn die Plugins haben auch Zugriff auf die Passwörter. Daher nur welche Installieren von Autoren den ihr Vertraut bzw. welche durch den Autor von KeePass überprüft wurden.
Die Datenbank selbst wird mit einem AES (128-Bit Blockgröße mit einer Schlüsselstärke von 256 Bit) Algorithmus verschlüsselt. Dieser ist derzeit der Standard unter den symmetrischen Verschlüsselungsalgorithmen und gilt als sehr sicher. Wer also ein starkes Masterpasswort verwendet, kann davon ausgehen das die Passwörter nicht ohne sehr hohen Aufwand wiederhergestellt werden können. Brut Force-Angriffe sind zwar immer möglich, aber bei ausreichender Passwortlänge und Komplexität dauert ein möglicher Angriff schnell Jahre und dies übersteigt in der Regel den Nutzen welchen man aus einem solchen Aufwand ziehen könnte.

Auch wenn derzeit etwas langsam, aber die Entwicklung vom updateSystem.NET geht voran. Aus diesem Grund möchte ich euch ein paar Einblicke geben, was es in dem demnächst erscheinendem Minorrelease so an neuen bzw. erweiterten Funktionen geben wird.

Ich habe beim Release der Version 1.0 einiges an Feedback bekommen. Aufgefalllen ist, dass einige mit dem neuen System der updateActions leicht überfordert waren. Deshalb werde ich zum einen mich hinter die Schnellstarttutorials klemmen und zum anderen wird es einen Assistenten geben welcher einen durch die meist genutzten Aktionen führt (Prozesse beenden –> Dateien kopieren –> Prozesse starten) und so den Umgang erleichtert. Nach Abschluß des Assistenten erscheint dann der normale Dialog zum bearbeiten eines Updatespaketes in welchem dann weitere Änderungen vorgenommen werden können.

Man soll es mit Assistenten zwar nicht übertreiben, aber einen wird es (wieder) geben. Und zwar den smartPackage Wizard, welcher bereits erstellte Updatepakete analysiert und daraus ein neues Paket generiert. Für Leute die die Updatepakete nicht über die Kommandozeile generieren ist es doch schon etwas nervig für jedes Update die gleichen Aktionen erstellen zu müssen wenn sich z.B. nur eine Datei geändert hat. Dort schafft dann das smartPackage abhilfe.

Desweiteren habe Ich irgendwie das Gefühl, dass ich die Änderungen pro Version etwas zu komplex aufgezogen habe. Prinzipiell würde doch auch ein simples Multiline-Textfeld pro Sprache die gleichen gestalterischen Möglichkeiten bieten wie die aktuelle Lösung. Nur nicht so umständlich. Da bin ich mir nur noch etwas unsicher. Mal sehen was mir dazu während der Entwicklung noch einfällt.

Für einen Releasetermin möchte ich mich eigentlich noch nicht festlegen, aber ich gehe davon aus das ich es noch vor meinem Geburtstag schaffe. Und noch was kleines in eigener Sache: Yay, dass war der 100te Beitrag :-)