Qualität eines gegeben Passworts prüfen

Als Entwickler steht man in der Pflicht die Logins von Benutzer der Software abzusichern. Ein wesentlicher Baustein ist das Forcieren einer Kennwortrichtlinie, um die Qualität eines Passworts sicherzustellen.
Das folgende C#-Snippet bietet eine rudimentäre, für die meisten Anwendungen ausreichende Bewertung des Kennworts. Im Snippet verwende ich ein enum, um einen Passwort Score zu repräsentieren:

  • Blank – 0 Punkte
  • VeryWeak – 1 Punkt
  • Weak – 2 Punkte
  • Medium – 3 Punkte
  • Strong – 4 Punkte
  • VeryStrong – 5 Punkte

Bei der Prüfung des Passworts verwende ich folgendes Regelwerk:

Das Passwort ist eine Zeichenkette mit 0 Zeichen
Es wird der enum-Wert von Blank, also 0 Punkte zurückgegeben.
Das Passwort umfasst weniger als 4 Zeichen
Das Passwort ist als sehr schwach einzustufen, demnach wird der enum-Wert VeryWeak zurückgegeben. Selbst wenn das Passwort die nachfolgenden Kriterien hinsichtlich Sonderzeichen, Zahlen oder gemischter Groß- und Kleinschreibung erfüllen würde, wäre es aufgrund seiner Länge als unsicher einzustufen.
Das Passwort umfasst mindestens 8 Zeichen
Das Scoring wird um einen Punkt erhöht und die Prüfung fortgesetzt.
Das Passwort umfasst mindestens 12 Zeichen
Das Scoring wird um einen Punkt erhöht und die Prüfung fortgesetzt. Da hier bereits die Bediendung „mindestens 8 Zeichen“ erfüllt ist, beträgt das Scoring2 und das Passwort wäre als schwach einzustufen.
Das Passwort enthält mindestens eine Ziffer
Ein weiterer Punkt wird hinzuaddiert und die Prüfung fortgesetzt.
Das Passwort enthält sowohl Klein, als auch Großbuchstaben
Das Scoring wird um einen Punkt erhöht und die Prüfung fortgesetzt.
Das Passwort enthält mindestens 1 Sonderzeichen
Das Scoring wird in dieser letzten Prüfung um eins erhöht. Das Scoring kann nun maximal 5 Punkte betragen. Das Passwort stufe ich somit als sehr stark ein.

Ich möchte betonen, dass die Bewertung nur als grobe Richtlinie betrachtet werden kann. Das Passwort „rush2112“ wird von meinem Bewertungsschema als „medium“ eingestuft, ist jedoch in der von Symantec veröffentlichten Liste der 500 schlechtesten Passwörter enthalten und somit hochgradig unsicher.
Mögliche Ausbaustufen der Richtlinie bestünden darin solche Listen sowie generell Wörterbücher zu berücksichtigen.

Microsoft SQL-Server Verbindungsserver einrichten

In Unternehmen sind häufig Insellösungen anzutreffen, deren Datenhaltung auf verschiedenen Microsoft SQL-Servern erfolgt. Ein häufiges Beispiel hier ist ein Warenwirtschaftssystem und ein Webshop, die sich weder eine gemeinsame Datenbank noch einen gemeinsamen SQL-Server teilen.
Neben der Synchronisation der Daten ist vor allem die zusammenhänge Auswertung der Datenquellen im Controlling eine häufige Anforderung. Um Daten aus Datenbanken von verschiedenen Microsoft SQL-Servern zusammenhängend darzustellen und diese als Datenquelle zum Beispiel in Excel verwenden zu können, wäre die Implementierung eines Data-Warehouse zwar formell der richtige Ansatz, jedoch scheidet dieser in Hinblick auf die damit verbunden Kosten vor allem für kleinere Mittelständler oftmals aus. Ebenso wenn ad hoc Auswertungen gefragt
Also probate Lösung, um die Anforderung der gemeinsamen Auswertbarkeit zu erfüllen, kann ein Microsoft SQL-Verbindungsserver eingerichtet werden. Gehen Sie dazu wie folgt vor:

Expandieren Sie im SQL Server Management Studio im Objektexplorer den Knoten Serverobjekte. Rufen Sie am Unterknoten das Kontextmenü auf und klicken auf „Neuer Verbindungsserver…“.

Neuen Verbindungsserver anlegen
Neuen Verbindungsserver anlegen

Im nun folgenden Dialog geben Sie den Namen des Verbindungsservers ein, unter dem dieser im Netzwerk zu erreichen ist. Wählen Sie als Servertyp „SQL Server“ aus.

Auswahl des Verbindungsservers
Verbindungsserver auswählen

Wählen Sie nun rechts die Seite „Sicherheit“ aus. Hier können Sie entweder lokalen Anmeldungen Anmeldungen auf dem Verbindungsserver zu ordnen. Oder einen für alle Anmeldungen gültigen Sicherheitskontext angeben. Wie im nachfolgendem Screenshot zu erkennen, habe ich keine dedizierte Anmeldungszuordnung vorgenommen, sondern jede Anmeldung am lokalen Server mit dem sa-Sicherheitskontext verknüpft. In der Praxis sind hier selbstverständlich das vorliegende Berechtigungsmodell zu beachten, da sonst mit jedem Login ein uneingeschränkter Zugriff auf den Verbindungsserver möglich wäre.

Konfigurieren Sie die Berechtigungen, mit denen einzelne oder alle Anmeldungen auf den Verbindungsserver zugreifen
Konfigurieren Sie die Berechtigungen, mit denen einzelne oder alle Anmeldungen auf den Verbindungsserver zugreifen

CSV-Dateien als Datenquelle für MS-SQL-Server nutzen

Gilt es Daten aus anderen Quellen in eine SQL-Datenbank zu übernehmen, so ist das CSV-Format häufig der kleinste gemeinsame Nenner. Der Microsoft SQL-Server bietet seit der Version 2008 bereits die Möglichkeit über einen BULK-INSERT Daten aus CSV-Dateien zu lesen.

BULK INSERT Adressen
    FROM 'C:\Daten\AdressenExport.csv'
    WITH
    (
    FIRSTROW = 2,
    FIELDTERMINATOR = ';', 
    ROWTERMINATOR = '\n',   
    ERRORFILE = 'C:\Daten\AdressenImportFehler.csv', 
    TABLOCK
    )

Bei diesem Vorgehen ist es wichtig, dass die Anzahl und Reihenfolge der Spalten in der Datenbank der Reihenfolge der Spalten in der CSV-Datei entspricht.

Erklärung der Parameter:

FIRSTROW
Ab dieser Zeile beginnen die Datensätze. Es wird bei 1 begonnen zu zählen, wenn also die CSV-Datei die Überschriften der Spaltenköpfe beinhaltet, ist hier 2 anzugeben.
FIELDTERMINATOR
Hier ist das Trennzeichen zwischen den einzelnen Spalten in einfachen Hochkommas anzugeben, für gewöhnlich ‚;‘ oder ‚,‘.
ROWTERMINATOR
Mit dieser Angabe wird das Zeichen angegeben, dass einen Zeilenwechsel und somit einen neuen Datensatz einleitet. Auch Kombinationen wie ‚\n\r‘ sind möglich.
ERRORFILE
Mit diesen optionalen Parameter kann eine Datei angegeben werden, in der jene Datensätze gespeichert werden, die z.B. aufgrund der Überschreitung der Feldlänge oder der Auslassung eines Pflichtfeldes in der Datenbanktabelle nicht importiert werden können.
TABLOCK
Sperrt die Tabelle während des Imports, was vor allem Performancevorteile mit sich bringen kann.

MS Office Verknüpfung Dateitypen wiederherstellen

Dateitypenzuordnung Office

Unter gewissen Umständen, wie zum Beispiel durch die Parallelinstallation von Open Office, kann es vorkommen, dass die Office-Dateitypen (doc, docx, xls, xlsx, etc.) nicht mehr den Microsoft Programmen zugeordnet sind oder gar keine Zuordnung zu irgendeinem Programm mehr vorgenommen wurden. Da es sich um recht viele unterschiedliche Dateiendungen handelt, kann die manuelle Zuordnung ein mühsames Geschäft sein. Einfacher geht es, wenn die entsprechen Office-Programme mit dem Parameter -r aufgerufen werden. Dadurch erfolgt die automatische Zuordnung aller Dateitypen.

Diese Version des Citrix Receivers unterstützt die ausgewählte Verschlüsselung nicht

Ich verwende den Citrix Receiver, um mich zu einem Server eines Kunden zu verbinden. Tatsächlich funktioniert die Lösung erstaunlich stabil und zuverlässig, jedoch noch einem Update der Softwareversion auf dem Server, brach mein Receiver den Aufbau der Verbindung mit folgender Meldung ab:

Diese Version des Citrix Receivers unterstützt die ausgewählte Verschlüsselung nicht.

Keine Frage, wenn die Version des Servers und Receivers nicht mehr kompatibel zueinander sind, darf die Software auch ihren Dienst quittieren. Allerdings führte die Deinstallation und Installation der aktuellen, kompatiblen Version zu keinen Erfolg.

Die vollständige Deinstallation muss manuell erfolgen:

  1. Citrix Receiver deinstallieren
  2. Ein eventuell vorhandenes Citrix-Browserplugin deinstallieren
  3. Neustarten
  4. Den kompletten Ordern „ICA Client“ unter Programme\Citrix bzw. Programme (x86)\Citrix löschen
  5. Im AppData Ordern des eigenen Benutzerprofils Unterordner Local\Citrix (%userprofile%\AppData\Local\Citrix\) den Ordner Receiver löschen
  6. In der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Citrix den gesamten Zweig „ICA Client“ löschen. Auf 64-bit Systemen findet sich der Ordner unter HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432\Citrix
  7. Neustarten
  8. Aktuelle bzw. zum Server kompatible Version des Citrix Receivers installieren.

T-SQL Zeichenkette mit Datentyp text vergleichen

Je nachdem, wie eine Datenbank aufgebaut ist, kann es vorkommen, dass ein als varchar oder nvarchar geführtes Feld mit einem Feld vom Typ text verglichen werden muss.

Ein trivialer Versuch wie der folgende

SELECT * FROM Zeiterfassung WHERE UserName = 'TF'

wird mit nachfolgender Fehlermeldung quittiert:
The data types text and varchar are incompatible in the equal to operator.

Soll ein solcher Vergleich zu einem Resultat führen, so muss ein Datentyp in den anderen konvertiert werden, dabei ist jedoch darauf zu achten, dass der zu konvertierenden Datentyp die Feldlängen nicht überschreitet. Für gewöhnlich sollte jedoch ein convert(varchar(max),datenfeld) ausreichend sein.

SELECT * FROM Zeiterfassung 
WHERE CONVERT(varchar(max),UserName) = 'TF'

T-SQL Primärschlüssel zurücksetzen

Mit Hilfe des DBCC CHECKIDENT Befehls des MS SQL Servers lässt sich der Primärschlüssel mit Identitätsspezifikation einer Tabelle neu vergeben und steuern. Neben wir an, in einer Tabelle „Adresse“ sind hundert Datensätze enthalten, mit dem Primärschlüssel beginnend bei 1 und endend bei 100. Möchten wir nun, dass der nächste eingefügte Datensatz den Schlüssel 250 enthält, können wir dies mit folgenden Befehl erreichen:

DBCC reseed: id  bei 250 fortsetzen
DBCC reseed: id bei 250 fortsetzen

Wenn man sich zum Beispiel innerhalb eines Unit-Tests auf Datensätze aus einer Datenbank beziehen muss, ist sicherzustellen, dass spezifische Datensätze über die gleichen Schlüssel zu erreichen sind. Wenn eine Tabelle nicht über TRUNCATE zurückgesetzt werden kann, bleibt nur ein einfacher DELETE. Mit einem anschließendem DBCC CHECKIDENT Befehl, können dann die Schlüssel zurückgesetzt werden, um wie im Beispiel wieder ab Datensatz 250 fortfahren zu können.

Primärschlüssel zurücksetzen nach DELETE
Primärschlüssel zurücksetzen nach DELETE

iCloud Fotos: Sync extrem langsam

Die iCloud von Apple scheint meines Erachtens ein gutes Angebot zu sein, wenn man seine Fotos auf diversen mobilen Geräten wie iPad oder iPhone und seinem Mac synchron halten möchte. Es macht schon Spaß eine Fotosammlung jenseits der 200GB immer dabei zu haben, ohne diese große Datenmenge tatsächlich auf den Gerät vorrätig halten zu müssen. Über die Preise der iCloud lässt sich gewiss streiten, ich persönlich empfinde das Staffelmodell jedoch als fair. Die Preise für Dropbox sind vergleichbar, doch insbesondere die Integration von Fotos ist beim Apple-Pendant zur Dropbox meines Erachtens deutlich schlechter gelungen.

Meine seit den frühen 2000er-Jahren aufgebaute digitale Fotosammlung umfasst mittlerweile rund 220GB und der Upload erfolgt über kriechend langsame 500 kbit/s, so dass bei voller Bandbreite in aufgerundet 41 Tagen alle Fotos und Videos in die iCloud übertragen sein sollten. Gewiss wäre es vermessen zu glauben, die volle Bandbreite stünde stets zur Verfügung, so dass ich  pessimistisch 60 Tage zum Synchronisieren eingeplant hatte.

Zu meinem Bedauern musste ich nach 50 Tagen feststellen, das gerade einmal 59,8GB übertragen wurden; und dass, obwohl durch den Power Nap die Synchronisierung mit der iCloud trotz Energiesparmodus klappen sollte.Bildschirmfoto 2015-08-06 um 22.49.13

 

Leider bieten weder Foto App noch OS X Yosemite ein detailliertes Protokoll, welche Dateien wann übertragen wurden.  Doch mittels des Kommandozeilen-Programms opensnoop lässt sich verfolgen, welcher Prozess auf welche Dateien Zugriff nimmt. Durch einen einfachen grep-Filter auf den Prozess CloudSync kann ich mir einen Überblick verschaffen, welche Dateien derzeit übertragen werden.

sudo opensnoop | grep CloudSync

Bildschirmfoto 2015-08-06 um 22.54.04

Durch Umleitung in eine Protokolldatei mit Timestamp war es mit so möglich in etwa zu ermitteln, wie lange die Übertragung einer einzelnen Datei benötigt. Das Ergebnis ist ernüchternd: Im Power Nap Modus scheint OS X nur einen Bruchteil der Bandbreite zu nutzen, um die Fotos zu synchronisieren. Überdies legt der Sync-Prozess nach jeder Datei eine Pause von einen Minuten ein, bis er mit der nächsten Datei fortfährt.

Abhilfe lässt sich hier zum Beispiel durch Caffeine schaffen, um den Energiesparmodus zu übersteuern – doch von einer zufriedenstellenden Lösung ist der Workaround weit entfernt. Nicht nur, dass mein Mac viel zu viel Storm für eine eigentlich triviale Aufgabe benötigt, sondern die Fotos werden nicht signifikant schneller übertragen.

Die Synchronisierung mit Dropbox war zuvor hingegen in etwa innerhalb er errechneten Übertragungsdauer möglich.

Eigentlich würde ich gerne die Vorteile der iCloud nutzen, um nicht nur ein dezentrales Backup meiner Fotos zu haben (das hatte ich zuvor schon mit Dropbox und das sogar noch in einem verschlüsselten Container), sondern vor allem, um in den Genuss zu kommen überall auf meinem iPad durch meine Fotosammlung Browsen zu können.

Derzeit überwiegen der Nachteile die erhofften Vorteile bei weitem und ich überlege bereits meinen Speicherplan bei Apple zu verändern. Schade, dass es nicht besser klappt. Vielleicht hat jemand ja noch eine rettende Idee.

Meine Optimierungen beschränken sich derzeit auf folgende, auf Beobachtungen gestützte Maßnahmen:

  1. Mit Caffeine oder vergleichbaren Apps den Energiesparmodus umgehen.
  2. Wenn möglich große Dateien wie etwa Videos von der Synchronisation ausnehmen.
  3. Keine weiteren Geräte mit der iCloud verbinden.
  4. Wenn möglich die Fotos in Alben mit weniger als 150 Bildern organisieren.

Diese Maßnahmen haben bei mir zu kleinen Performancesteigerungen geführt.

Nach nunmehr 50 Tagen heißt es für mich: 60GB übertragen, 160GB stehen noch aus. Sollte also nur noch 134 Tage dauern – mit ein bisschen Glück klappt es also bis Weihnachten. 😉