Hallo,
überlege gerade welche Möglichkeiten es gibt, eine Datenbankdatei vor Zugriffen, durch Passwort und Verschlüsselung zu schützen.
Die Datenbank enthält Umsatzdaten von privaten Konten, ein gewisser Schutz ist also angebracht.
Gibt es eine Lösung mit der sich das realisieren lässt?
Gruß Christian
Zugriff auf Datenbankdatei verhindern
Hi CrackPod,
eigentlich wollte ich keinen eigenen Server dafür verwenden. Mir schwebt da etwas wie sqlite oder MS Access (mdb) vor.
Ein Ansatz von mir ist eine sqlite datei in einem mit Truecrypt verschlüsselten Laufwerk zu speichern. Mit den Truecrypt Kommandozeilenbefehlen, könnte man dies sogar von Python steuern.
Gruß Christian
eigentlich wollte ich keinen eigenen Server dafür verwenden. Mir schwebt da etwas wie sqlite oder MS Access (mdb) vor.
Ein Ansatz von mir ist eine sqlite datei in einem mit Truecrypt verschlüsselten Laufwerk zu speichern. Mit den Truecrypt Kommandozeilenbefehlen, könnte man dies sogar von Python steuern.
Gruß Christian
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Du kannst beispielsweise in die Datenbank die Daten verschlüsselt speichern (was zugegebenermaßen etwas arg blöd ist) oder die Datenbank verschlüsselt, beispielsweise mit GnuPG oder mit PyCrypto. Hängt aber auch ab, wie sicher du es haben willst.
Ein anderer Ansatz der mir einfällt, aber nur geht wenn die Datenbank ausreichend klein ist: Daten in Datenabnk verschlüsselt speichern, neue Datenbank in :memory: öffnen und dort die Datenbank unverschlüsselt wieder aufbauen. Hmm, wobei ich zugeben muss, dass ich diese Idee auch nicht für sonderlich sicher halte.
Ein anderer Ansatz der mir einfällt, aber nur geht wenn die Datenbank ausreichend klein ist: Daten in Datenabnk verschlüsselt speichern, neue Datenbank in :memory: öffnen und dort die Datenbank unverschlüsselt wieder aufbauen. Hmm, wobei ich zugeben muss, dass ich diese Idee auch nicht für sonderlich sicher halte.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Nette Idee, hat aber zwei Hacken. Zum einen mußt du das Laufwerk ja einbinden, wenn du die DB nutzten willst. In dem Zeitraum kann ein normaler User auf die DB Datei zugreifen.Byte hat geschrieben:Ein Ansatz von mir ist eine sqlite datei in einem mit Truecrypt verschlüsselten Laufwerk zu speichern. Mit den Truecrypt Kommandozeilenbefehlen, könnte man dies sogar von Python steuern.
Zum anderen must du IMHO irgendwo das TC Passwort gespeichert haben. Das kann ein User einfach aus deinem Skript auslesen...
Vielleicht ist es noch am einfachsten die Daten in der DB zu verschlüsseln. Aber auch das hat zwei Hacken: Die DB Zugriffe werden langsam (Man sollte evtl. nur die wichtigsten Daten verschlüsseln).
Aber auch hier mußt du irgendwo den Key/Passwort speichern.
- Sr4l
- User
- Beiträge: 1091
- Registriert: Donnerstag 28. Dezember 2006, 20:02
- Wohnort: Kassel
- Kontaktdaten:
Ich würde nicht die Daten in der Datenbank verschlüsseln. Ist zu aufwendig dann die Datenbankfunktionen zu nutzen.
Ich würde bei SQLite die Datei als ganzes mit einem Passwort verschlüsseln und bei Programmstart gibt man das Passwort ein mit dem wird die Datenbankdatei wieder entschüselt. Diese Technik ist mindestens so unsicher wie alle anderen, aber es ist die einfachste.
Die entschlüsselte Datei würde ich als virtuelle Datei in den Arbeitsspeicher legen.
Ich würde bei SQLite die Datei als ganzes mit einem Passwort verschlüsseln und bei Programmstart gibt man das Passwort ein mit dem wird die Datenbankdatei wieder entschüselt. Diese Technik ist mindestens so unsicher wie alle anderen, aber es ist die einfachste.
Die entschlüsselte Datei würde ich als virtuelle Datei in den Arbeitsspeicher legen.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ah. Hab mir nochmal das Eingangsposting durchgelesen. In dem Fall kann man ja wirklich ein Passwort vom User abfragen und damit dann die Entschlüsselung starten.
Es ist natürlich schon einfacher, wenn man eine SQLite Datei hat, diese dann in TEMP zu entschlüsseln und am ende wieder zurück verschlüsseln. Allerdings hat man ein Problem. Die entschlüsselte Variante könnte man recht einfach wieder herstellen
Wenn man nur die Buchungstexte verschlüsselt, kann man noch ganz normal die DB Abfragen benutzten. Wenn man mehr Schutz haben möchte, könnte man natürlich auch buchungs Datum und Betrag verschlüsseln. Dann kann man aber nicht mehr die DB Funktionen richtig nutzten um gezielt Daten basierend auf Datum/Betrag raus zu finden.
Evtl. gibt es ja die Möglichkeit die SQLite Datei nur im Speicher zu entschlüsseln und die dann dem SQLite-DB-Modul zu Verfügung zu stellen?
In dem Fall muß man natürlich die ganze Datei ins RAM passen
Es ist natürlich schon einfacher, wenn man eine SQLite Datei hat, diese dann in TEMP zu entschlüsseln und am ende wieder zurück verschlüsseln. Allerdings hat man ein Problem. Die entschlüsselte Variante könnte man recht einfach wieder herstellen
Wenn man nur die Buchungstexte verschlüsselt, kann man noch ganz normal die DB Abfragen benutzten. Wenn man mehr Schutz haben möchte, könnte man natürlich auch buchungs Datum und Betrag verschlüsseln. Dann kann man aber nicht mehr die DB Funktionen richtig nutzten um gezielt Daten basierend auf Datum/Betrag raus zu finden.
Evtl. gibt es ja die Möglichkeit die SQLite Datei nur im Speicher zu entschlüsseln und die dann dem SQLite-DB-Modul zu Verfügung zu stellen?
In dem Fall muß man natürlich die ganze Datei ins RAM passen
- Sr4l
- User
- Beiträge: 1091
- Registriert: Donnerstag 28. Dezember 2006, 20:02
- Wohnort: Kassel
- Kontaktdaten:
Ich habe gelesen das geht. Ich werde mal suchen...
Habs: http://python.org/doc/2.4.1/lib/module-StringIO.html
es gibt auch noch cStringIO ist die schnellee Variante, aber ich bleibe lieber bei pure Python wenns geht
Habs: http://python.org/doc/2.4.1/lib/module-StringIO.html
es gibt auch noch cStringIO ist die schnellee Variante, aber ich bleibe lieber bei pure Python wenns geht
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wieso? cStringIO ist schneller und hat quasi keine Nachteile (außer du willst den Quellcode patchen).Sr4l hat geschrieben:es gibt auch noch cStringIO ist die schnellee Variante, aber ich bleibe lieber bei pure Python wenns geht
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
`StringIO` gibt's auch ausserhalb von CPython. Solange ich keine Geschwindigkeitsprobleme habe, benutze ich bei `StringIO` und auch bei `pickle` die Pythonvarianten.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Kompromiss:BlackJack hat geschrieben:`StringIO` gibt's auch ausserhalb von CPython.
Code: Alles auswählen
try:
import cStringIO as StringIO
except ImportError:
import StringIO
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Unterbrechung:
Der Autor (?) von sqlite verweist darauf, dass Lese- und Schreibrechte seiner Datenbanken über die Lese- und Schreibrechte des OS organisiert werden können (dadurch, dass jeder Datenbank eben genau nur eine Datei zugeordnet ist). Das finde ich sehr praktisch und werde so vorgehen.
Der Autor (?) von sqlite verweist darauf, dass Lese- und Schreibrechte seiner Datenbanken über die Lese- und Schreibrechte des OS organisiert werden können (dadurch, dass jeder Datenbank eben genau nur eine Datei zugeordnet ist). Das finde ich sehr praktisch und werde so vorgehen.
[color=green][size=75]Never use idle.pyw, if you need sys.stdin[/size][/color]
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ja, das ist das normale "verhalten" von SQLite... Es öffnet die Datei selber... In diesem Fall, soll doch eine verschlüsselte DB von python aus geladen werden, im RAM entschlüsselt und dann SQLite vorgesetzt werden... Oder hab ich da was falsch verstanden?joost hat geschrieben:Unterbrechung:...
Hi,
danke für die vielen Antworten!
Eine Standardlösung gibt es scheinbar nicht. Beim Verschlüsseln der Datenbankdatei, sehe ich Probleme, wenn das Programm abbricht oder der PC unvorhergesehen abgeschalten wird. Wenn beim beenden das Programm die temporäre Datei nicht mehr verschlüsseln kann, führt das zu Datenverlust und die unverschlüsselte Datei bleibt erhalten.
Da werde ich wohl noch ein wenig grübeln müssen.
Christian
danke für die vielen Antworten!
Eine Standardlösung gibt es scheinbar nicht. Beim Verschlüsseln der Datenbankdatei, sehe ich Probleme, wenn das Programm abbricht oder der PC unvorhergesehen abgeschalten wird. Wenn beim beenden das Programm die temporäre Datei nicht mehr verschlüsseln kann, führt das zu Datenverlust und die unverschlüsselte Datei bleibt erhalten.
Da werde ich wohl noch ein wenig grübeln müssen.
Christian
Die Standardlösung ist in der Regel die Mechanismen vom Betriebssystem zu benutzen, in Verbindung mit der Benutzererwaltung der Datenbanksoftware.
Also im einfachsten Fall die Benutzerrechte vom Betriebssystem, oder Verschlüsselungstechniken dazwischen schalten wenn es noch sicherer sein soll.
Also im einfachsten Fall die Benutzerrechte vom Betriebssystem, oder Verschlüsselungstechniken dazwischen schalten wenn es noch sicherer sein soll.
-
- User
- Beiträge: 61
- Registriert: Freitag 7. März 2003, 19:28
- Kontaktdaten:
Könnte man das Problem einer temorären Tabelle nicht über eine ":memory:" Datenbank von SQLite lösen? Hierdurch würde keine Temporäre Datei entstehen, ich weis nur ne ob man ne :memory: DB dann nachträglich einfach so speichern kann
mfg Betz Stefan
mfg Betz Stefan
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Siehe meinen Post, früher. Das Problem kann ja immernoch das Swappen sein, dann landet der Speicher immernoch auf der Festplatte. Aber das ist immerhin sicherer als gar nichts.stefan_betz hat geschrieben:Könnte man das Problem einer temorären Tabelle nicht über eine ":memory:" Datenbank von SQLite lösen?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice