grosses SQL Skript ausführen

Wieder mal DB-Notiz für mich selber: Die Ausführung eines grossen SQL Skripts über Management Studio kann wegen Memory unmöglich sein:

Screenshot 2015-11-05 17.22.37

TITLE: Microsoft SQL Server Management Studio
——————————

Cannot execute script.

——————————
ADDITIONAL INFORMATION:

Insufficient memory to continue the execution of the program. (mscorlib)

——————————
BUTTONS:

OK
——————————

Lösung: Skript per sqlcmd ausführen:

SQLCMD -i „C:\Temp\script.sql“


User kann nicht aus SQL Datenbank gelöscht werden

The database principal owns a schema in the database, and cannot be dropped

Zuerst muss geschaut werden, um welches Schema es geht:

SELECT s .name
FROM sys .schemas s
WHERE s .principal_id = USER_ID ('BENUTZERNAME');

Wenn hier z.B. db_owner zurückgegeben wird, kann man den owner des Schemas neu setzen:

ALTER AUTHORIZATION ON SCHEMA::db_owner TO dbo;


mysqldump

Reminder:
./mysqldump--add-drop-table -h win12vsv04.weblink.ch -u piwik -p affolterNET_piwik | bzip2 -c > /Users/martin/dumps/affolterNET_piwik.sql.bz2


Windows Time

Tool: w32tm

Manual Peerlist and update:
w32tm /config „/manualpeerlist:0.ch.pool.ntp.org 1.ch.pool.ntp.org 2.ch.pool.ntp.org 3.ch.pool.ntp.org“ /syncfromflags:manual /update

SuisseID – Wie sicher ist das Verfahren?

Derzeit finden sich täglich neue Meldungen über die SuisseID und deren Sicherheit im Internet. Je nach Perspektive und Hintergrund könnten die Positionen unterschiedlicher nicht sein.

Einerseits sind da diejenigen, die sich mit der Sicherheit der SuisseID und vergleichbarer Systeme beschäftigt und herausgefunden haben, wie sich die SuisseID und andere Systeme missbrauchen lassen: http://www.vimeo.com/15155073.

Andererseits finden sich da die Befürworter, die von „digitalen fälschungssicheren Signaturen“ sprechen. Besonders schön hier; es wird versucht, alles an der Demonstration gezeigte ins Lächerliche zu ziehen.

Meines Erachtens können hier ein paar Fakten nicht schaden:

  1. Das Verfahren das mit der SuisseID zur Anwendung kommt ist auf jeden Fall sicherer, als wenn eine Unterschrift eingescannt wird. Oder wenn bei einer E-Mail darauf vertraut wird, dass sie tatsächlich vom angegebenen Absender stammt.
  2. Die Verschlüsselung der SuisseID wird mit dem gezeigten Verfahren nicht geknackt. Sie ist auch nicht das Problem.
  3. Der Schwachpunkt ist der PC des Anwenders und dessen potentielle Unsicherheit.
  4. Das Problem, das sich mit der Sicherheit und digitalen Signaturen stellt, ist nicht neu. Banken waren und sind seit jeher damit konfrontiert, dass PC’s ihrer Benutzer nicht immer sicher sind.
  5. Es handelt sich nicht um ein Problem der SuisseID, sondern um ein allgemeines Problem im Zusammenhang mit der Identifikation von Personen im Internet. Es geht darum festzustellen, ob eine Erklärung oder Aktion tatsächlich von einer zweifelsfrei identifizierten Person stammt (und nicht von jemand anderem, der im Besitz des „Schlüssels“ ist).
  6. Ein potentieller Angreifer muss Zugriff auf den Rechner des Opfers gehabt haben, damit er für diesen Erklärungen abgeben kann. Ein zu unterschreibendes Dokument wird dann mit Hilfe der SuisseID des Opfers „unterschrieben“: Es wird mit Hilfe der SuisseID die Signatur des Opfers erstellt und mit dem Dokument verwendet.

Was heisst das nun:

  1. Dieses Problem ist seit über 10 Jahren bekannt: Es gibt gute Gründe, warum Banken seit jeher einen zweiten Kanal zur Identifikation ihrer Kunden einsetzen. Sei das nun eine Streichliste, eine SMS PIN oder einen Leser mit Chipkarte und Tastatur, der nicht am PC angeschlossen wird.
  2. Die SuisseID hat keinen zweiten Kanal und ist somit weniger sicher als Online-Banking.
  3. Es bedarf dazu nicht eines „völlig virenverseuchten PCs“, die Methoden um gezielt einen Benutzer anzugreifen ist eine Frage der richtigen Tools und allenfalls ein bisschen „ungewollter Mitarbeit“ des Opfers oder dessen nicht gepatchten Systems.
  4. In diesem Zusammenhang sei auf die Dissertation („Elektronische Signaturen“) von Schlauri verwiesen, der im Jahr 2002 unter dem Titel „Haftungsfragen“ (Seite 193) das Folgende ausführt:

    „Wie bei den herkömmlichen Legitimationssystemen trägt der Anbieter im Weiteren eine Pflicht zur sorgfältigen Auswahl des Systems. Dabei ist auf den Stand der Technik und die Wirtschaftlichkeit Rücksicht zu nehmen.“

    „Das geschilderte HBCI-Verfahren1151 der deutschen Banken, welches auf Klasse-1-Geräten oder gar Softwaresigniereinheiten basiert, erfüllt daher m.E. diese Anforderungen an ein sorgfältig ausgewähltes System nicht.“

Es kommt also auf die Klassifikation des Readers an, wie sicher ein Verfahren ist. Dazu findet sich in der Knowledgebase von Cryptoshop das folgende:

ZKA Klassifikation:

Klasse 1 Reader: Kontaktiereinheit ohne Tastatur und eine Schnittstelle wie z.B. USB
Klasse 2 Reader: Klasse 1 Reader und Tastatur (Pinpad),
Klasse 3 Reader: Klasse 2 Reader und Anzeige (Display) sowie sichere Nachladbarkeit für Zusatzanwendungen im Leser (z.B. für ZKA-IKT),
Klasse 4 Reader: Klasse 3 und Sicherheitsmodul mit RSA Funktionalität sowie eine VM (direkte Ausführbarkeit von Programmen im Leser) (vgl. FINREAD-Spezifikation)

Fazit:

Das Problem mit Klasse 1 Readern ist seit Jahren bekannt. Es ist nicht ein Problem der SuisseID, sondern ein Problem aller Systeme, die Klasse 1 Reader einsetzen. Die entscheidende Frage lautet, warum bei der SuisseID nicht aktuelle Sicherheit nach dem heutigen Stand der Technik eingebaut wurde, wenn das Hauptverkaufsargument „Sicherheit“ sein soll.