<\/p>\n
Hält Ihre Access-Datenbank Datenschutzrichtlinien stand Eine gute Frage, die Sie beim Entwickeln von Anwendungen für Unternehmen oder Behörden zu hören bekommen werden. Sie werden dann etwa mit dem Access-Sicherheitssystem argumentieren, also der Geschichte mit den Arbeitsgruppen. Das wird den Datenschutzbeauftragten bei sensiblen Daten aber höchstwahrscheinlich nicht zufrieden stellen, denn Zugriff auf die Tabellen erhält man über den einen oder anderen Trick dennoch. Es gibt aber Techniken, die selbst den Einblick in die Tabellen wertlos machen können…<\/b><\/p>\n<\/p><\/div>\n Unsichere Datenbanken<\/p>\n Die Absicherung einer Access-Datenbank über eine Arbeitsgruppendatei (MDW) beschränkt zwar den Kreis der Zugriffsberechtigten auf Nutzer, die sich mit Benutzername und Kennwort einloggen müssen. Mit einigen zusätzlichen Vorkehrungen wie dem Ausblenden des Datenbankfensters, Erstellen einer MDE-Datenbank, Deaktivieren der Umschalttaste beim Start der Anwendung und dem Einsatz einer Access-Runtime statt der Vollversion scheint der Datenzugriff zwar auf die Präsentationsschicht, also Formulare und Berichte, begrenzt zu sein. Was aber sollte einen neugierigen Nutzer davon abhalten, sich eine Kopie des Backends und der MDW, auf die nun mal systembedingt alle User Vollzugriff haben müssen, zu erstellen und dann in Ruhe seine Access-Vollversion an die MDW anzuschließen und sich nach Eingabe seiner Anmeldedaten in aller Ruhe die Tabellen anzusehen<\/p>\n Sicher, es gibt noch ausgefeiltere Methoden, die Tabellen vor dem User zu schützen, etwa der Einsatz von WITH-OWNERACCESS-OPTION-Abfragen, die nur dem Entwickler (Owner) oder dem VBA-Code den Zugriff erlauben. Das nutzt aber alles nichts, wenn er ein Datenrettungs-Tool wie AccessRecovery <\/b>über das Backend laufen lässt, das im Stande ist, unter Umgehung der MDW-Absicherung die Tabellen binär auszulesen und ungeschützt wiederherzustellen.<\/p>\n Das ist auch der Grund dafür, dass viele Organisationen Access-Datenbanken prinzipbedingt als unsicher ablehnen. Es gibt aber auch Datenschutzbeauftragte, die eine Access-Datenbank akzeptieren, wenn sichergestellt ist und plausibel gemacht werden kann, dass die Daten verschlüsselt sind. Ohne einen speziellen Zugriffsschlüssel sind die Tabellen dann unbrauchbar. Das zu realisieren ist gar nicht so schwer.<\/p>\n Sicherere Datenbanken<\/b><\/p>\n Tabellenfelder, die etwa Namen und Adressen von Klienten enthalten, die nicht öffentlich einsehbar sein sollen, können Sie mit verschiedenen Algorithmen verschlüsseln. Die Tabelle enthält dann nur sinnlose Zeichenfolgen, mit denen keiner etwas anfangen kann. Schwieriger ist es, Felder anderer Datentypen wie Date<\/b> oder Long <\/b>zu verschlüsseln, denn das Ergebnis der Verschlüsselung muss ja dann den gleichen Datentyp aufweisen, damit es im Feld gespeichert werden kann. Oder man muss andere Felder wie Binärtypen einsetzen, um das Verschlüsselungsergebnis aufnehmen zu können. Da es jedoch für Zahlenwerte höchst selten einen Grund zur Verschlüsselung geben dürfte, beschäftigen sich die folgenden Techniken fast ausschließlich mit Strings und Textfeldern.<\/p>\n Texte verschlüsseln<\/b><\/p>\n Es gibt zahllose Methoden, um einen String zu verschlüsseln. Das Ziel ist zunächst, aus einem Text einen anderen zu machen, der keine Rückschlüsse auf den ursprünglichen Inhalt mehr zulässt. Umgekehrt muss aus dem verschlüsselten Text genauso wieder der Ursprungstext zu errechnen sein. Ein Beispiel für eine sehr simple Routine zeigt Listing 1.<\/p>\n Listing 1: Textzeichen durcheinanderbringen<\/p>\n Dabei wird jedes Zeichen des Strings in sChr<\/b> zwischengespeichert, daraus die Ordinalzahl ermittelt (iChr<\/b>) und diese mit der boolschen Operation Xor 255 <\/b>bearbeitet. Hieraus wird ein neuer String mit den Zeichen der neuen Ordinalzahlen iChr<\/b> erstellt, der anschließend noch mit der Funktion StrReverse <\/b>umgedreht wird. Heraus kommt, wenn Sie der Funktion beispielsweise den Text "Unternehmen“ übergeben, die Zeichenkette “ ‚š“-š’š<‚ª“. An diesem String lässt sich wohl nichts mehr erkennen, was auf die Ausgangszeichenkette „Unternehmen“ schließen ließe.<\/p>\n Der Clou an der Funktion ist, dass Sie ihr umgekehrt genauso den verschlüsselten String übergeben können, um wieder an den korrekten Text zu kommen: Aus “ ‚š“-š’š<‚ª“ wird dann wieder „Unternehmen“.<\/p>\n Dennoch ist die Methode zu einfach, um einem gewieften Hacker die Arbeit wirklich schwer zu machen. Beispielsweise wird jedes Zeichen im Quelltext in jeweils genau das gleiche Zielzeichen im verschlüsselten Text umgewandelt. Im Beispiel wird ein „n“ immer zu „š“. über stochastische Analyseverfahren etwa lässt sich für einen Krypto-Experten hieraus leicht das Verschlüsselungsverfahren ermitteln.<\/p>\n Deshalb haben sich verschiedene standardisierte Verfahren etabliert, nach denen Texte sicherer verschlüsselt werden können, wobei zur Verschlüsselung meist noch ein eindeutiger Key zum Einsatz kommt, ohne den man den Text nicht mehr zurückverwandeln kann. Diese Algorithmen tragen Namen wie RC2, RC4, DES, Blowfish, TEA, Serpent oder Gost und kennen jeweils mehrere Derivate. Sie unterscheiden sich im Grad der Verschlüsselung – quasi dem „Sicherheitsgrad“ – und auch im Berechnungsaufwand. Der Aufruf sieht in Pseudo-Code meist so aus:<\/p>\n Tabellenfelder verschlüsseln<\/b><\/p>\n In Datenbanken, wo etwa über Abfragen große Datenmengen auszuwerten sind, ist man auf einen Kompromiss zwischen Verschlüsselungsstärke und Verarbeitungsgeschwindigkeit angewiesen. Deshalb sollten hier Algorithmen zum Einsatz kommen, die relativ schnell arbeiten, aber ausreichend sicher sind. Das wohl am häufigsten eingesetzte Verfahren ist die RC4-Verschlüsselung. Ein Vorteil der Methode ist, dass Windows entsprechende API-Funktionen mitbringt, die flott zu Werke gehen. Man kann zweifellos jedes Verschlüsselungsverfahren auch in VBA-Code nachbauen; weil aber Stringverarbeitung unter VB eine etwas lahme Angelegenheit ist, kommt man mit Aufrufen auf Funktionen in separaten DLLs erheblich besser weg.<\/p>\n Die Beispieldatenbank zu diesem Beitrag enthält ein Modul mdlEncrypt<\/b>, in dem Sie die Prozeduren TestDeEncrypt <\/b>und TestDeEncryptVBA <\/b>ausführen können. Beide verschlüsseln und entschlüsseln nach dem RC4-Verfahren in einer Schleife 20.000 Strings. TestDeEncryptVBA <\/b>macht das aber über reinen VBA-Code, die andere bemüht dazu API-Funktionen der Windows-Bibliothek advapi32.dll<\/b>. Sie werden feststellen, dass die Crypto-Routinen der advapi32.dll <\/b>etwa dreimal so schnell sind wie die von VBA. Pro Sekunde lassen sich auf einem aktuellen Rechner damit etwa 100.000 Strings verschlüsseln.<\/p>\n Die RC4-Crypto-Methoden von advapi32 <\/b>kommen übrigens an vielen Stellen von Windows selbst zum Einsatz – und auch in Access: Die Verschlüsselung von Passwörtern im Sicherheitssystem von JET über die PIDs benutzt sie ebenfalls.<\/p>\n Der Code für die Verschlüsselungsmethoden ist in den zwei Klassenmodulen clsRC4 <\/b>(VBA pur) und clsCypto <\/b>(Verwendung der advapi32<\/b>) untergebracht. Die Ergebnisse sind nicht ganz kompatibel: Ein verschlüsselter Text der einen Klasse kann nicht mit den Routinen der anderen wiederhergestellt werden.<\/p>\n RC4 hat noch einen weiteren Vorteil: Die Ergebnis-Strings sind genauso lang, wie die Eingabe-Strings. Damit ist sichergestellt, dass die für Textfelder in den Eigenschaften eingestellte Feldgröße nicht überschritten wird, wenn ein Textinhalt darin verschlüsselt wird.<\/p>\n Die genaue Funktionsweise der beiden Klassen soll hier nicht weiter erläutert werden. Verschlüsselungsverfahren sind ein Thema für Vorlesungen eines ganzen Semesters.<\/p>\n <\/p>\n Was soll ich verschlüsseln<\/b><\/p>\n Das hängt wohl vom Einsatzzweck ab. Erwähnt wurden schon Adressfelder: Namen, Straßen- und Ortsbezeichnungen. Oder weitere Personendaten: Telefonnummern, E-Mail-Adressen oder auch Memofelder, die Anmerkungen zu den Personen enthalten. Falls die Datenbank ein programmiertes Berechtigungssystem enthält, mit dem etwa der Zugriff auf bestimmte Elemente je nach Benutzer gesteuert wird, kämen für die Verschlüsselung noch in Tabellen gespeicherte Benutzernamen und Kennwörter in Frage. <\/p>\n Vorhandene Tabellen ver- und entschlüsseln<\/p>\n Wie Daten nachträglich verschlüsselt werden können, zeigt die Beispieldatenbank anhand der Tabelle tblKunden<\/b> in zunächst unverschlüsselter Form. über die Anfügeabfrage qry_EncryptKunden <\/b>können Sie die Daten in die in identischem Aufbau vorliegende Tabelle tblKundenEncrypt <\/b>transferieren. Leeren Sie dazu die Tabelle zuerst mit der Löschabfrage qry_DelEncryptKunden<\/b>.<\/p>\n Nicht alle Felder der Ursprungstabelle werden dabei verschlüsselt. Es sind gerade so viele, dass die Datensätze anschließend nicht mehr nachvollziehbaren Inhalt wiedergeben. Sehen wir uns an, wie etwa das Feld Firma <\/b>mit der Abfrage verschlüsselt wird:<\/p>\n Das Feld Firma <\/b>der Tabelle tblKunden <\/b>wird der Verschlüsselung per öffentlicher benutzerdefinierter Funktion EncryptString <\/b>des Moduls mdlEncrypt <\/b>unterzogen. Sie erwartet als Parame-ter einerseits den Eingangs-String, andererseits den Verschlüsselungs-Key. Der wird hier aber nicht hartkodiert in die Abfrage geschrieben, sondern seinerseits über eine benutzerdefinierte Funktion GetCryptKey <\/b>erhalten, die so aussieht:<\/p>\n Das ist gleichsam der Generalschlüssel für die Datenbankverschlüsselung. Dies ist sicher nicht der Weisheit letzter Schluss und wurde der Einfachheit halber so eingesetzt. Der hartkodierte Schlüssel steckt hier im Code verborgen, indem der String „60TFOSssom“ mit der Funktion StrReverse <\/b>zu „mossSOFT06“ gemacht wird. Alle verschlüsselten Felder der Tabelle tblKundenEncrypt <\/b>sind also mit dem RC4-Key „mossSOFT06“ bearbeitet. <\/p>\n Um die verschlüsselte Tabelle komplett in entschlüsselter Datenblattansicht anzuzeigen, rufen Sie die Auswahlabfrage qry_DecryptKunden <\/b>auf. Das Feld Firma <\/b>wird in dieser so entschlüsselt:<\/p>\n Die benutzerdefinierte Funktion DecryptString <\/b>arbeitet analog zu EncryptString <\/b>und stellt die korrekten Texte wieder mit unserem supergeheimen Key „mossSOFT06“ her.<\/p>\n Die Tabelle tblKunden <\/b>können Sie anschließend aus der Datenbank entfernen – sie wird nun nicht mehr gebraucht.<\/p>\n Verschlüsselte Daten und Formulare<\/b><\/p>\n Wenn die Daten der Tabellen verschlüsselt sind, dann ist ein nicht unerheblicher Mehraufwand bei der Gestaltung der Formulare zu beachten. Schließlich können die Formularfelder nicht mehr einfach, wie gewohnt, an die Tabellenfelder gebunden werden. Sie würden ja dann nur den verschlüsselten Inhalt wiedergeben. Die entsprechenden Textboxen müssen deshab ungebunden vorliegen und ihnen sind Strings per VBA zuzuweisen. Das ist im Formular frmKunden <\/b>der Beispieldatenbank realisiert, zu dem Sie über das Intro-Formular gelangen, nachdem Sie eine ermüdende Login-Prozedur durchlaufen haben …<\/p>\n Login<\/b><\/p>\n Falls Sie die Umschalttaste beim öffnen der Beispieldatenbank nicht gedrückt halten, zeigt sich das Intro-Formular von Access-im-Unternehmen. Ein Klick auf „Start“ leitet Sie dann zu einem Eingabedialog, der Ihren Benutzernamen abfragt. Ist der korrekt, muss ein Kennwort angegeben werden. Falls das ebenfalls stimmt, wird das Formular frmKunden <\/b>geöffnet. Das fragt seinerseits nach dem Generalschlüssel, den Sie bereits kennen. Nach gültiger Eingabe können Sie endlich die Daten der Tabelle tblKundenEncrypt <\/b>unverschlüsselt ansehen und bearbeiten. Andernfalls werden Sie nur Kauderwelsch zu Gesicht bekommen.<\/p>\n Damit Sie nicht nachforschen müssen: Versuchen Sie es mit „Leser“ als Benutzername und Kennwort sowie dem Key „mossSOFT06“ für das Formular frmKunden<\/b>.<\/p>\n Das alles ist Spielerei, soll aber verdeutlichen, wie Anmeldeinformationen in verschlüsselten Tabellen verwendet werden können. Hier sind sie in der Tabelle tblLogin <\/b>gespeichert, wobei nur das Feld Passwort mit dem RC4-Key „mossSOFT06“ verschlüsselt wird.<\/p>\n Ungebundene Felder<\/b><\/p>\n Mit falschem Schlüssel am Formular frmKunden <\/b>angemeldet, erhalten Sie etwa das Ergebnis aus Bild 1.<\/p>\n Bild 1: Verschlüsselte Daten im Formular bei falschem Schlüssel<\/span><\/b><\/p>\n<\/p><\/div>\n Anfangen kann man damit gar nichts und gesperrt sind die Datensätze außerdem. In einer Produktivumgebung würde man natürlich das Formular in dieser Form erst gar nicht anzeigen, sondern einen Hinweis auf den ungültigen Schlüssel liefern. Ist der aber korrekt, dann sieht das Ganze wie in Bild 2 aus.<\/p>\n Bild 2: Entschlüsselte Daten im Formular bei gültigem Schlüssel<\/span><\/b><\/p>\n<\/p><\/div>\n Wenn Sie Daten in diesem Formular modifizieren oder hinzufügen, dann werden Sie bemerken, dass nichts davon gespeichert wird. Dazu muss für jeden Datensatz erst die Schaltfläche Speichern <\/b>betätigt werden. Es wurde bereits gesagt: Die Felder in diesem Formular sind ungebunden und werden jeweils im Ereignis Beim Anzeigen <\/b>per VBA nach Entschlüsselung gefüllt. Damit werden änderungen der Feldinhalte nicht automatisch in der zugrunde liegenden Tabelle gespeichert. Auf den Speichern<\/b>-Knopf könnte man verzichten, wenn es ein Ereignis in Access gäbe, das „Vor Datensatzwechsel“ oder ähnlich lautete und in dessen Ereig-nisprozedur man dann das explizite Speichern des Datensatzes veranlassen könnte. Das gibt es aber leider nicht (man könnte dafür zweifellos einen Workaround programmieren, das Beispiel sollte jedoch nicht zu kompliziert werden).<\/p>\n Nicht ganz selbsterklärend ist, wie mit den Daten im Formular verfahren wird. Die folgende Beschreibung bezieht sich auf die in Listing 2 abgedruckte Prozedur, die beim öffnen des Formulars ausgelöst wird:<\/p>\n Listing 2: Abfragen des Kennworts und Umwandeln der gebundenen in ungebundene Steuerelemente<\/p>\n Zunächst wird der RC4-Schlüssel mit einer Inputbox abgefragt und in der privaten Variablen m_Key <\/b>angelegt. Sie vergleicht ihn mit dem Generalschlüssel aus der Funktion GetCryptKey<\/b>. Bei übereinstimmung wird die Formularvariable bMayEdit <\/b>auf True <\/b>gesetzt; sie wird in den anderen Prozeduren noch benötigt.<\/p>\n Bei falschem Schlüssel in m_Key <\/b>wird also eine Meldung ausgegeben, der Speichern<\/b>-Button deaktiviert und die Möglichkeit zum Anfügen von Datensätzen gesperrt (AllowAdditions = False<\/b>). Anschließend werden die Textfelder im Formular bearbeitet.<\/p>\n Dies bedarf weiterer Erläuterungen: Wenn Sie das Formular im Entwurf öffnen, dann werden Sie feststellen, dass die Textfelder gebunden sind und das Formular auch die Datenherkunft tblKundenEncrypt<\/b> besitzt. Somit lassen sich die Textfelder leichter anlegen. Zur Laufzeit sollen die Felder aber ja ungebunden sein. Und das erledigt die Schleife im unteren Teil von Listing 2. Alle Felder, die in ungebundene verwandelt werden sollen, haben in der Marke<\/b>-Eigenschaft (Tag<\/b>) den Wert -1 <\/b>stehen.<\/p>\n Die Schleife setzt nun für alle Textfelder (acTextbox<\/b>) bis auf KundeID <\/b>die Eigenschaft ControlSource <\/b>auf einen Null-String. Damit sind sie anschließend ungebunden. Gleichzeitig wird die Tag<\/b>-Eigenschaft der Felder als Zwischenspeicher auf den bisherigen Steuerelementinhalt gestellt, damit man später noch weiß, zu welchem Tabellenfeld die Textbox gehört.<\/p>\n Für alle verschlüsselten Felder wird zudem ein „:“ vor den Feldnamen gestellt, damit sie anschließend als zu ent-\/verschlüsselnde Felder gekennzeichnet sind. Ob das Feld zum Bearbeiten gesperrt ist, wird über die Locked<\/b>-Eigenschaft vom Ergebnis der Schlüsselüberprüfung (bMayEdit<\/b>) anhängig gemacht.<\/p>\n Die nun ungebundenen Felder werden im Ereignis Beim Anzeigen <\/b>mit Daten gefüllt (s. Listing 3):<\/p>\n Listing 3: Leeren der Felder beim Anlegen eines neuen Datensatzes und Anzeigen der Inhalte bei vorhandenen Datensätzen<\/p>\n Hier wird zunächst die Recordset<\/b>-Variable rst <\/b>auf eine Kopie des Formular-Recordsets gesetzt (RecordsetClone<\/b>). Warum wird nicht direkt mit dem Formular-Recordset gearbeitet Der Grund ist, dass die Feldinhalte sich beim Springen zwischen den Datensätzen per Navigationsleiste nicht immer synchron zu den Feldinhalten des Formular-Recordsets verhalten, sondern der Navigation nachhinken. Erstaunlich, aber wahr, und das für alle Access-Versionen! Möglicherweise kommen hier Cache-Effekte ins Spiel. Darum wird also der aktuelle Datensatz mit der Kopie des Recordsets und der Methode FindFirst <\/b>auf KundeID <\/b>eingestellt.<\/p>\n In einer Schleife werden dann, ähnlich wie in Listing 2, alle Textfelder durchlaufen und ihnen in Abhängigkeit davon, ob sie entschlüsselt werden müssen – der Feldname in Control.Tag <\/b>enthält ein führendes „:“ – oder nicht, entweder der RC4-entschlüsselte Wert (DecryptString<\/b>) oder der direkte Wert des Kopie-Recordsets (rst(sField).Value<\/b>) verpasst.<\/p>\n Eine Spezialbehandlung erfahren noch neue Datensätze, identifiziert durch Me.NewRecord = True<\/b>. Da die Textfelder ungebunden sind, wird ihr angezeigter Inhalt nicht automatisch gelöscht, wenn ein neuer Datensatz angelegt wird.<\/p>\n Die Inhalte des vorigen Datensatzes bleiben stehen. Deshalb müssen sie in dieser Routine explizit auf Null gesetzt werden:<\/p>\n Datensatz speichern: Die durch Betätigen der Speichern<\/b>-Schaltfläche ausgelöste Prozedur cmdSave_Click <\/b>ist ähnlich wie die in Listing 3 aufgebaut. Der einzige Unterschied besteht darin, dass die Feldinhalte hier umgekehrt dem Formular-Recordset zugewiesen werden und dass gegebenenfalls ver- und nicht entschlüsselt wird:<\/p>\n oder<\/p>\n Integer-Werte verschlüsseln<\/b><\/p>\n Die Tabelle tblKundenEncrypt <\/b>enthält nur verschlüsselte Textfelder. Wollte man auch andere Datentypen einer Verschlüsselung unterziehen, etwa das Long<\/b>-Feld Kundencode<\/b>, dann wird die Sache komplizierter: Ein Long<\/b>-Datentyp besteht nur aus 4 Bytes. Soll das Ergebnis der Verschlüsselung ebenfalls nur 4 Bytes aufweisen, damit es in ein entsprechendes Tabellenfeld gespeichert werden kann, dann lässt sich die RC4-Verschlüsselung nicht mehr ohne Weiteres anwenden.<\/p>\n Hier können andere Algorithmen zum Einsatz kommen, die statt Zeichen zu verschlüsseln die einzelnen Bits des Long<\/b>-Werts verarbeiten.<\/p>\n Ein mögliches Vorgehen zeigen die Prozedur TestLongEncrypt <\/b>des Moduls mdlEncrypt <\/b>und die enthaltenen Methoden EncryptLong <\/b>und DecryptLong <\/b>der Klasse clsRC4<\/b>. Diese errechnen aus den Ordinalwerten der Zeichen des Keys einen Verschiebefaktor, um den die Bits des Long<\/b>-Werts rotiert werden.<\/p>\n Beispiel für das Linksrotieren eines Integers um drei Stellen: <\/p>\n Aus 13576 wird in diesem Fall 43073.<\/p>\n Beim Entschlüsseln wird dieser Vorgang dann wieder rückgängig gemacht.<\/p>\n Zusammenfassung<\/b><\/p>\n Mit der Verschlüsselung von Daten können Sie Ihre Access-Datenbanken sicherer machen. Dieser Beitrag zeigt nur einen kleinen Ausschnitt aus der Welt der Kryptografie, nämlich die RC4-Verschlüsselung von Textdaten.<\/p>\n Wenn Sie Interesse an weiterem Material haben sollten, dann finden Sie unter [1] eine sehr umfangreiche Sammlung von Visual Basic-Projekten, die sich leicht für VBA umschreiben oder direkt übernehmen lassen. Hervorzuheben sind dabei die Projekte von David Midkiff, die alle erdenklichen Methoden bereitstellen.<\/p>\n Quellen<\/p>\n [1] http:\/\/www.vb.kiev.ua\/code\/crypt\/<\/p>\n Enthaltene Beispieldateien:<\/p>\n demo_encrypted.mdb<\/p>\n\nFunction ScrambleString(sIn As String) As String\r\n Dim i As Long, lLen As Long, \r\n Dim sChr As String, iChr As Integer\r\n lLen = Len(sIn)\r\n ScrambleString = String(lLen, 0)\r\n For i = 1 To lLen\r\n sChr = Mid(sIn, i, 1)\r\n iChr = Asc(sChr)\r\n sChr = Chr$(iChr Xor 255)\r\n Mid(ScrambleString, i, 1) = sChr\r\n Next i\r\n ScrambleString = StrReverse(ScrambleString)\r\nEnd Function<\/pre>\n
Verschlüsselter Text = KryptoFunktion (UrsprungsText, Schlüssel)<\/pre>\n
INSERT INTO tblKundenEnrypt (Firma)\r\nSELECT EncryptString([tblKunden].[Firma],GetCryptKey())\r\nFROM tblKunden<\/pre>\n
Function GetCryptKey() As String\r\n GetCryptKey = StrReverse("60TFOSssom\")\r\nEnd Function <\/pre>\nSELECT DecryptString([tblKundenEnrypt].[Firma],GetCryptKey()) AS Firma\r\nFROM tblKundenEnrypt<\/pre>\n
\n ![\"frmKundenNotOK.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/Verschluesselung-web-images\/frmKundenNotOK_opt.jpeg\")
\n <\/div>\n\n\n ![\"frmKundenOK.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/Verschluesselung-web-images\/frmKundenOK_opt.jpeg\")
\n <\/div>\n\nPrivate Sub Form_Load()\r\n m_Key = InputBox("Bitte authentifizieren Sie sich mit ihrem Passwort\" & vbCrLf & _\r\n "Ohne Authentifizierung können Sie geschütze Daten\" & vbCrLf & _\r\n "weder einsehen noch bearbeiten.\", "Auth\", "\")\r\n If m_Key <> GetCryptKey Then\r\n MsgBox "Passwort nicht korrekt!\" & vbCrLf & _\r\n "Sie können die Daten nicht editieren und\" & vbCrLf & _\r\n "geschütze nicht einsehen.\", vbExclamation\r\n Me!cmdSave.Enabled = False\r\n Me.AllowAdditions = False\r\n Else\r\n bMayEdit = True\r\n MsgBox "Passwort akzeptiert\", vbInformation\r\n End If\r\n Dim ctl As Access.Control\r\n Dim sField As String\r\n For Each ctl In Me.Controls\r\n If (ctl.ControlType = acTextBox) And (ctl.Name <> "KundeID\") Then\r\n ctl.Tag = IIf(ctl.Tag = -1, ":\", "") & ctl.ControlSource\r\n ctl.ControlSource = ""\r\n ctl.Locked = Not bMayEdit\r\n End If\r\n Next ctl\r\nEnd Sub<\/pre>\nPrivate Sub Form_Current()\r\n Dim ctl As Access.Control\r\n Dim sField As String\r\n Dim rs As DAO.Recordset\r\n If Me.NewRecord Then\r\n For Each ctl In Me.Controls\r\n If (ctl.ControlType = acTextBox) And (ctl.Name <> "KundeID\") Then\r\n ctl.value = Null\r\n End If\r\n Next ctl\r\n Exit Sub\r\n End If\r\n Set rs = Me.RecordsetClone\r\n rs.FindFirst "[KundeID]=" & Me!KundeID\r\n For Each ctl In Me.Controls\r\n If (ctl.ControlType = acTextBox) And (ctl.Name <> "KundeID") Then\r\n sField = ctl.Tag\r\n If bMayEdit Then\r\n If Left(sField, 1) = ":" Then\r\n sField = Mid(sField, 2)\r\n ctl.value = DecryptString(rs(sField).value, GetCryptKey())\r\n Else\r\n ctl.value = rs(sField).value\r\n End If\r\n Else\r\n ctl.value = rs(Replace(sField, ":", "")).value\r\n End If\r\n End If\r\n Next ctl\r\n Set rs = Nothing\r\nEnd Sub<\/pre>\n
If Me.NewRecord Then\r\n For Each ctl In Me.Controls\r\n If (ctl.ControlType = acTextBox) _
And (ctl.Name <> "KundeID\") Then\r\n ctl.Value = Null\r\n End If\r\n Next ctl\r\nEnd If<\/pre>\nMe.Recordset(sField).Value = Nz(ctl.value) <\/pre>\n
Me.Recordset(sField).Value = _
EncryptString(Nz(ctl.Value), GetCryptKey())<\/pre>\n0011 0101 0000 1000 > 1010 1000 0100 0001<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n