Discussion:
*.mdb mit Passwort schützen
(zu alt für eine Antwort)
Michaela Meier
2009-04-18 07:25:12 UTC
Permalink
Hi,

Ist es möglich, aus C# heraus einer access-Datenbank ein Passwort zu
verpassen (und ggf. wieder zu löschen)?
Und zwar unabhängig von Windows-Accounts/Usern.
Einfach nur ein schönes altmodisches Paßwort. Im optimalen Falle sogar
eine Passwort-Liste, so daß ein Master-Passwort im Falle eines
handelsüblichen Gedächtnisverlustes immer noch zur Datenrettung
herangezogen werden kann.

Theoretisch könnte ich auch einfach die Software mit einem Paßwort
schützen, denn ich bezweifle, daß den potentiellen Usern der Unterschied
zwischen Programm und Daten ausreichend klar ist und daß man die Daten
auch anders auslesen könnte.

Allerdings zöge ich ein Paßwort auf Datenbank-Level vor, da ich davon
ausgehe (die Software unterstützt dieses sogar), daß die Daten zwischen
mehreren Rechnern hin- und her kopiert werden.

Es sind keine Hochsicherheitsdaten und das Login soll nur einen gewissen
Schutz gegen "ach, gucken mer ma schnell, was XY so auf'm Rechner hat"
bieten.

Hat jemand Tips oder Gegenvorschläge? :-)

Danke
Peter Götz
2009-04-18 08:27:23 UTC
Permalink
Hallo Michaela,
Post by Michaela Meier
Ist es möglich, aus C# heraus einer access-Datenbank
ein Passwort zu verpassen (und ggf. wieder zu löschen)?
Eine Access.mdb kann auf zwei unterschiedliche Arten
geschützt werden.

1.) Mit Hilfe einer der *.mdb zuzuordnenden System.mdw.
Hiermit können mehrere, unterschiedliche Benutzer-
kennungen/Passwörter vergeben werden. Mit der
*.mdb muss auch immer eine passende System.mdw
geliefert werden.
Unter der Voraussetzung, dass die *.mdb mit einer
System.mdw assoziiert ist kann via SQL-Statement
ein Passwort für einen in der System.mdw eingetragenen
Benutzer geändert oder neu hinzugefügt werden:

SQL-String:
ALTER USER Benutzer PASSWORD NeuesKennwort AltesKennwort


2.) Mit einem einfachen internen Datenbankkennwort.
Hierzu ist keine zusätzliche System.mdw erforderlich.
Es wird einfach ein Passwort vergeben und nur mit
diesem Passwort im Connectionstring lässt sich die
so geschützte *.mdb später wieder öffnen.

SQL-String:
ALTER DATABASE PASSWORD NeuesKennwort AltesKennwort

Connectionstring zum späteren Öffnen einer mit internem
DB-Kennwort geschützten *.mdb im geteilten (Mehrbenutzer)
Modus:

Provider = MIcrosoft.Jet.OLEDB.4.0; _
Data Source = C:\Verzeichnis\DB.mdb; _
OLE DB Services = -4; _
Mode = "Share Deny None"; _
Jet OLEDB:DataBase Password = DasDbKennwort; _
Jet OLEDB:Database Locking Mode = 1


Beide Schutzmechanismen sind nicht übermässig sicher.
Im Internet gibt es haufenweise Tools, mit deren Hilfe sich
solche Passwörter herausfinden oder entfernen lassen.

Man kann aber z.B. die *.mdb in ein nur für eine bestimmte
Windows-Benutzerkennung freigegebenes Verzeichnis z.B.
auf einem Server legen. Die unter ihrer normalen Benutzer-
kennung ans System/Domäne angemeldeten Benutzer haben
damit erst mal keinerlei Zugriff auf eine solche *.mdb. Auch
nicht mit Access oder einem sonstigen (Hex-) Editor.
Das zugreifende Programm muss sich dann für DB-Zugriffe
per Impersonation mit eben dieser Benutzerkennung und
zugehörigem Passwort legitimieren.
Ein Beispiel für Impersonation gibt es unter

www.gssg.de -> Visual Basic -> VB.net
-> Impersonate / Benutzerwechsel

Ein Rest von Unsicherheit bleibt natürlich auch dabei,
da diese Benutzerkennung mit zugehörigem Passwort
im Programm selbst (verschlüsselt) abgelegt werden
muss.
Was welcher Benutzer mit der DB darf oder nicht darf,
kann dann immer noch durch eine Programminterne
Benutzer- u. Rechteverwaltung geregelt werden.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
Frank Dzaebel
2009-04-18 08:52:20 UTC
Permalink
Hallo Peter,
Post by Peter Götz
Provider = MIcrosoft.Jet.OLEDB.4.0; _
Data Source = C:\Verzeichnis\DB.mdb; _
da die Frage nach C# Syntax ging ...:
Unterstriche braucht man in C# nicht,
bzw. ergäben Fehler.
Post by Peter Götz
Visual Basic -> VB.net-> Impersonate / Benutzerwechsel
machen wir auch da mal C# draus, ist für
den, der sonst C# macht immer einfacher:

[Code mit anderen Rechten ausführen]
http://dzaebel.net/LogonUser.htm

BTW: für die User sind direkte Links einfacher IMHO,
anstatt mit -> ABC -> DEF -> GHI ...


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Michaela Meier
2009-04-19 15:35:05 UTC
Permalink
Post by Peter Götz
1.) Mit Hilfe einer der *.mdb zuzuordnenden System.mdw.
Das hört sich so an, als wäre es in meinem Fall die bessere Lösung.
Werde ich mal mit rumspielen.
Macht es etwas aus, wenn sich bei Kopieren der absolute Pfad der Dateien
verändert oder läuft das unabhängig davon, solange sich mdb und mdw im
selben Verzeichnis befinden?
Post by Peter Götz
Beide Schutzmechanismen sind nicht übermässig sicher.
Macht nichts. Das Programm läuft weder im Umfeld von Hacker-Communities
noch in schützenswerten Firmen. Für die meisten Benutzer dürfte der PC
der Monitor sein und das Betriebssystem der Desktop. Was nicht über
Icons zu erreichen ist, existiert de facto nicht :-)
Peter Götz
2009-04-20 07:33:13 UTC
Permalink
Hallo Michaela,
Post by Michaela Meier
Das hört sich so an, als wäre es in meinem Fall die
bessere Lösung.
Schutz via System.mdw ist etwas sicherer als ein
einfacher Schutz via intern. DB-Kennwort, aber
bedeutet eben auch mehr Aufwand bei der
Weitergabe *.mdb und *.mdw.
Mit der *.mdw können für unterschiedliche
Benutzer unterschiedliche Rechte vergeben werden,
was beim internen DB-Kennwort nicht möglich ist.
Post by Michaela Meier
Werde ich mal mit rumspielen.
Macht es etwas aus, wenn sich bei Kopieren der
absolute Pfad der Dateien verändert oder läuft
das unabhängig davon, solange sich mdb und
mdw im selben Verzeichnis befinden?
Bei *.mdb und *.mdw im gleichen Verzeichnis
sollte es keine Probleme geben.
Änderungen von Berechtigungen sind halt bei
einer *.mdw etwas umständlich zu handhaben.

Ich nutzte bei meinen Anwendung die Windows-
Sicherheit, da es bei meinen Anwendern immer
einen oder mehrere Dateiserver gibt. Auf einem
dieser Server wird ein Verzeichnis mit einer
speziellen Benutzerkennung/Passwort vergeben
und die *.mdb dort hineingelegt. Das jeweilige
Clientprogramm meldet sich dann per Impersonation
mit dieser spez. Benutzerkennung, die nicht identisch
mit der des jeweils am System angemeldeten
Windowsbenutzers ist, um auf die *.mdb zuzugreifen.
Die Rechteverwaltung geschieht in meinen Programmen
selbst. Ein solches mit spez. Benutzerkennung
gesichertes Verzeichnis lässt sich natürlich auch
auf dem eigenen Rechner nutzen. Ein Installations-
programm mit Admin-Rechten könnte dieses
Verzeichnis samt Benutzerkennung u. Passwort
selbst erstellen, bedeutet halt einigen Programmier-
aufwand fürs Setup-Programm und wäre auch nur
dann sinnvoll, wenn die späteren Benutzer nicht
selbst Admin-Rechte auf ihrem Rechner haben.
Post by Michaela Meier
Post by Peter Götz
Beide Schutzmechanismen sind nicht übermässig
sicher.
Macht nichts. Das Programm läuft weder im Umfeld
von Hacker-Communities noch in schützenswerten
Firmen. Für die meisten Benutzer dürfte der PC
der Monitor sein und das Betriebssystem der Desktop.
Was nicht über Icons zu erreichen ist, existiert de facto
nicht :-)
Bei sehr geringen Sicherheitsanforderungen wäre
dann aber evtl. ein einfaches internes DB-Kennwort
schon ausreichend und eben die am einfachsten
zu handhabende Variante bei der Programm- /
DB-Verteilung.

Problem bei internem DB-Kennwort wie auch bei
Schutz via *.mdw ist, dass man die DB-Datei (*.mdb)
trotzdem mit jedem anderen Programm, wie z.B. WordPad
oder einem beliebigen Hex-Editor öffnen und auch verändern
kann. Es gibt halt immer wieder neugierige Benutzer,
die gar keine böse Absicht haben, aber eben doch mal
mit dem Editor in so eine *.mdb schauen und dann
versehentlich ändern und damit evtl. unbrauchbar machen.
Dagegen hilft letztlich nur der Schutz via Windows-Sicherheit
in einem entspr. geschützten Verzeichnis.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
Michaela Meier
2009-04-20 19:56:57 UTC
Permalink
Post by Peter Götz
Bei sehr geringen Sicherheitsanforderungen wäre
dann aber evtl. ein einfaches internes DB-Kennwort
schon ausreichend und eben die am einfachsten
zu handhabende Variante bei der Programm- /
DB-Verteilung.
Der Nachteil davon ist jedoch, daß man nur _ein_ PW vergeben kann. Ein
zweites Master-PW wäre jedoch optimal.

Wenn die mdw-Lösung allerdings _ausschließlich_ über Win-Accounts läuft,
dann ist das tatsächlich zu aufwendig.

Ach, ist schon ein Kreuz, den DAUs einen Schritt voraus zu sein :-)
Da es aber wirklich viele schöne Recovery Tools zu geben scheint, kann
ich ja im Ernstfall auch damit eine Datei wieder zugänglich machen.
Es soll halt nur den spontanen Fremdbrowser abschrecken, wenn jemand
z.B. auf der Jahresversammlung der ohrlosen Kaninchenzüchter seinen
Laptop während des Sturms aufs kalte Buffet rumstehen läßt.

thx

Peter Doering
2009-04-20 13:10:22 UTC
Permalink
Hallo,
Post by Michaela Meier
Post by Peter Götz
1.) Mit Hilfe einer der *.mdb zuzuordnenden System.mdw.
Das hört sich so an, als wäre es in meinem Fall die bessere Lösung.
Werde ich mal mit rumspielen.
Je nachdem, wie weit die Loesung in die Zukunft reichen soll, sei noch
angemerkt, dass das Access-Sicherheitssystem ab Access 2007 fuer das neue
DB-Format (accdb bzw. accde/accdr) nicht mehr unterstuetzt wird. Fuer
mdb/mdw bleibt die Funktionalitaet aber erhalten und beide koennen auch
weiterhin geoeffnet und bearbeitet werden. Fuer mdw sind die Assistenten
ueber das UI allerdings nicht mehr erreichbar, nur aus VBA heraus:
DoCmd.Runcommand acCmdUserAndGroupAccounts bzw.
acCmdUserAndGroupPermissions (Konstantenwerte: 104 bzw. 103).

Gruss - Peter
--
Peter Doering [MVP Access]
Frank Dzaebel
2009-04-18 08:28:40 UTC
Permalink
Hallo Michaela,
Post by Michaela Meier
Ist es möglich, aus C# heraus einer access-Datenbank ein Passwort zu
verpassen (und ggf. wieder zu löschen)?
ja:

private void PasswortUmsetzen( /* ... */ )
{
string aktuellesPasswort = ""; // wenn "" : kein Passwort
string deinMdbPfad = @"C:\XYZ\Test.mdb"; // Beispiel-Pfad
OleDbConnection conn = new OleDbConnection(
"Provider=Microsoft.Jet.OLEDB.4.0;" +
"Data Source=" + deinMdbPfad + ";"+
"Jet OLEDB:Database Password=" + aktuellesPasswort + ";" +
"Mode=Share Exclusive");
conn.Open();
OleDbCommand cmd = new OleDbCommand(
"ALTER DATABASE PASSWORD `deinNeuesPasswort` `" +
aktuellesPasswort + "`", conn);
int ret = cmd.ExecuteNonQuery();
// ...
}
______

Im Command sind die speziellen "`" Zeichen zu beachten.
Möglich wäre aber auch, die Passwörter in eckigen
Klammern einzurahmen.

[ALTER USER or DATABASE Statement (Microsoft Access SQL) [Access 2007
Developer Reference]]
http://msdn.microsoft.com/en-us/library/bb177884.aspx

[ACC2000: wie Ändern des Datenbank-Kennworts über ADO]
http://support.microsoft.com/kb/304915


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Lesen Sie weiter auf narkive:
Loading...