12
Durch PHP verschlüsselte Daten (mcrypt) in Access entschlüsseln
Hallo Forengemeinde,
mein erster Beitrag in diesem Forum ist eine Frage an die Access- / VBA-Experten.
Ich habe eine MySQL-Datenbank, die durch PHP-Skripte mit Leben gefüllt wird. Ein Teil der Daten wird mittels mcrypt (ofb) vor dem Eintragen in die Datenbank verschlüsselt. Das und auch das spätere Entschlüsseln funktioniert mit der Kombination PHP-MySQL wunderbar.
Nun habe ich das Problem, dass ich mit Access 2003 auf diese verschlüsselten Daten zugreifen und sie auch bearbeiten muss. Access ist per ODBC mit der MySQL verbunden und holt / schreibt auch alle unverschlüsselten Daten. Wie kann ich nun die verschlüsselten Daten in Access lesbar machen? An ein Zurückschreiben in die MySQL-Datenbank denke ich dabei zunächst noch gar nicht.
Der PHP-Code zum Verschlüsseln sieht so aus:
Zum Entschlüsseln entsprechend:
Bin für jeden Lösungsansatz offen und dankbar!
Gruß
pagerank0
Nun habe ich das Problem, dass ich mit Access 2003 auf diese verschlüsselten Daten zugreifen und sie auch bearbeiten muss. Access ist per ODBC mit der MySQL verbunden und holt / schreibt auch alle unverschlüsselten Daten. Wie kann ich nun die verschlüsselten Daten in Access lesbar machen? An ein Zurückschreiben in die MySQL-Datenbank denke ich dabei zunächst noch gar nicht.
Der PHP-Code zum Verschlüsseln sieht so aus:
<?
$key_value = "irgendeinschluessel";
$data = "Daten im Klartext";
$crypted_data = mcrypt_ofb(MCRYPT_DES, $key_value, $data, MCRYPT_ENCRYPT);
?>Zum Entschlüsseln entsprechend:
<?
$key_value = "irgendeinschluessel";
$data = "die_kryptischen_zeichen_aus_der_datenbank";
$decrypted_data = mcrypt_ofb(MCRYPT_DES, $key_value, $data, MCRYPT_DECRYPT);
?>Bin für jeden Lösungsansatz offen und dankbar!
Gruß
pagerank0
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 128367
Url: https://administrator.de/contentid/128367
Printed on: April 24, 2024 at 11:04 o'clock
12 Comments
Latest comment
Zitat von @pagerank0:
Ein Teil der Daten wird mittels mcrypt (ofb) vor
dem Eintragen in die Datenbank verschlüsselt. Das und auch das
spätere Entschlüsseln funktioniert mit der Kombination
PHP-MySQL wunderbar.
Ein Teil der Daten wird mittels mcrypt (ofb) vor
dem Eintragen in die Datenbank verschlüsselt. Das und auch das
spätere Entschlüsseln funktioniert mit der Kombination
PHP-MySQL wunderbar.
Schön.
Nun habe ich das Problem, dass ich mit Access 2003 auf diese
verschlüsselten Daten zugreifen und sie auch bearbeiten muss.
verschlüsselten Daten zugreifen und sie auch bearbeiten muss.
Wer bist Du in Deiner Firma?
Praktikant?
Access ist per ODBC mit der MySQL verbunden und holt / schreibt auch
alle unverschlüsselten Daten. Wie kann ich nun die
verschlüsselten Daten in Access lesbar machen?
alle unverschlüsselten Daten. Wie kann ich nun die
verschlüsselten Daten in Access lesbar machen?
Mit der Funktion mcrypt.
An ein
Zurückschreiben in die MySQL-Datenbank denke ich dabei
zunächst noch gar nicht.
Zurückschreiben in die MySQL-Datenbank denke ich dabei
zunächst noch gar nicht.
Würde aber auch gehen.
Lonesome Walker
Hallo Lonesome Walker,
vielen Dank für Deine überaus hilfreiche Antwort, aber ich warte doch lieber auf jemanden, der interessiert ist, nützliche Tipps zu geben.
Gruß
pagerank0
vielen Dank für Deine überaus hilfreiche Antwort, aber ich warte doch lieber auf jemanden, der interessiert ist, nützliche Tipps zu geben.
Gruß
pagerank0
Na hoffentlich bringst Du Geduld mit...
Lonesome Walker
Lonesome Walker
Geduld habe ich und -wenn die Lösung so einfach ist, dass man gar nicht danach fragen darf- auch die Hoffnung auf eine Antwort, die mich weiter bringt.
Moin pagerank0,
zugegeben, ich muss da (im Gegensatz zu LSW) mangels Erfahrung ein bisschen den gesunden Menschenverstand bemühen bzw -ehrlicher ausgedrückt- im Nebel stochern.
Aber im Finden von Workarounds habe ich mittlerweile schon etwas Übung.
Also Anmerkung 1)
Wenn ich schon meine DB-Daten verschlüsseln wollte oder müsste, dann würde ich eher lachend in die Kreissäge springen als das mit irgendeinem Codeschnipsel außerhalb der jeweiligen DB-Möglichkeiten machen.
Das Konzept einer Datenbank ist doch gerade, dass ich die Daten unabhängig von irgendeinem Programm interpretieren können möchte.
Jedes halbwegs zeitgemäße DB-Blech bringt Verschlüsselungsmöglichkeiten mit, so auch MySQL ( siehe mySQL-Encryption-Functions ).
Abgesehen davon raten ja selbst eingefleischte PHP-Vertreter von der buggybuggybuggy-Funktion mcrypt-ofb() ab.
---> wenn du da mitziehen könntest, dass die DB-eigenen Verschlüsselungskrücken benutzt werden, dann spricht doch nichts dagegen, den Krams verschlüsselt zu speichern in der Tabelle und anderen Interessenten, z.B. Fremd-Frontends anzubieten unverschlüsselt in einem Eins-zu-Eins-View.
Im View kannst Du doch wieder die DB-Internen Decrypt-Routinen ansprechen.
Merkt doch keiner, der den View anzieht und berechtigt ist das Programm ja ohnehin zum Lesen der Daten.
Mal sehen, ob LSW mich jetzt auslacht... *gg
Grüße
Biber
zugegeben, ich muss da (im Gegensatz zu LSW) mangels Erfahrung ein bisschen den gesunden Menschenverstand bemühen bzw -ehrlicher ausgedrückt- im Nebel stochern.
Aber im Finden von Workarounds habe ich mittlerweile schon etwas Übung.
Also Anmerkung 1)
Wenn ich schon meine DB-Daten verschlüsseln wollte oder müsste, dann würde ich eher lachend in die Kreissäge springen als das mit irgendeinem Codeschnipsel außerhalb der jeweiligen DB-Möglichkeiten machen.
Das Konzept einer Datenbank ist doch gerade, dass ich die Daten unabhängig von irgendeinem Programm interpretieren können möchte.
Jedes halbwegs zeitgemäße DB-Blech bringt Verschlüsselungsmöglichkeiten mit, so auch MySQL ( siehe mySQL-Encryption-Functions ).
Abgesehen davon raten ja selbst eingefleischte PHP-Vertreter von der buggybuggybuggy-Funktion mcrypt-ofb() ab.
---> wenn du da mitziehen könntest, dass die DB-eigenen Verschlüsselungskrücken benutzt werden, dann spricht doch nichts dagegen, den Krams verschlüsselt zu speichern in der Tabelle und anderen Interessenten, z.B. Fremd-Frontends anzubieten unverschlüsselt in einem Eins-zu-Eins-View.
Im View kannst Du doch wieder die DB-Internen Decrypt-Routinen ansprechen.
Merkt doch keiner, der den View anzieht und berechtigt ist das Programm ja ohnehin zum Lesen der Daten.
Mal sehen, ob LSW mich jetzt auslacht... *gg
Grüße
Biber
@Biber:
Du hast ihm seine Frage nicht beantwortet, sondern lediglich einen Workaround geliefert, wie er es besser machen könnte :-p
Stellt sich die Frage, wie er es jetzt macht, MySQL über PHP(ODBC) mit Access zu verbinden (ODBC Access<->MySQL wird da ja leider nix bringen; vielleicht sieht er das ja mal ein...)
Oh, und dann könnte es EVENTUELL zu Problemen kommen, wenn Access mit PHP angesprochen werden soll...
(je nachdem, WIE man das macht, könnten da lustige Ergebnisse rauskommen...)
Aber deswegen habe ich ja gefragt, welche Position er in seinem Unternehmen bekleidet...
Ist er Praktikant -> Chef sagen, geht nicht (schnell, schmerzlos, einfach)
Ist er leitender Angestellter -> sagen, kostet viel Geld (erledigt sich auch sehr schnell)
Ist er aber Cheffe -> der Firma, die diesen Murks verbogen hat, sagen, sie sollen das fristgerecht wieder stramm ziehen
Wie Du ja schon treffend angemerkt hast, war der URGEDANKE von Datenbanken Unabhängigkeit.
Wenn man sich dann aber freiwillig geißeln läßt, dann darf man sich nicht über seine masochistische Ader in einem öffentlichen Forum beschweren :-p
@threadstarter:
einer Deiner Befehlsfreunde wird:
werden, nicht vergessen...
Lonesome Walker
Du hast ihm seine Frage nicht beantwortet, sondern lediglich einen Workaround geliefert, wie er es besser machen könnte :-p
Stellt sich die Frage, wie er es jetzt macht, MySQL über PHP(ODBC) mit Access zu verbinden (ODBC Access<->MySQL wird da ja leider nix bringen; vielleicht sieht er das ja mal ein...)
Oh, und dann könnte es EVENTUELL zu Problemen kommen, wenn Access mit PHP angesprochen werden soll...
(je nachdem, WIE man das macht, könnten da lustige Ergebnisse rauskommen...)
Aber deswegen habe ich ja gefragt, welche Position er in seinem Unternehmen bekleidet...
Ist er Praktikant -> Chef sagen, geht nicht (schnell, schmerzlos, einfach)
Ist er leitender Angestellter -> sagen, kostet viel Geld (erledigt sich auch sehr schnell)
Ist er aber Cheffe -> der Firma, die diesen Murks verbogen hat, sagen, sie sollen das fristgerecht wieder stramm ziehen
Wie Du ja schon treffend angemerkt hast, war der URGEDANKE von Datenbanken Unabhängigkeit.
Wenn man sich dann aber freiwillig geißeln läßt, dann darf man sich nicht über seine masochistische Ader in einem öffentlichen Forum beschweren :-p
@threadstarter:
einer Deiner Befehlsfreunde wird:
odbc_close($connection);werden, nicht vergessen...
Lonesome Walker
@lonesome Walker
<OT>
Das erlebe ich ja auch jeden Tag in "Batch & Shell", wenn jemand mit Tunnelblick seine Frage auf ein "Wo ist der Tippfehler in meinem Skript?" reduziert
Abgesehen davon - du beschränkst dich ja auch gottseidank nicht nur auf die buchstabengetreue Abarbeitung der Frage...
Grüße
Biber
</OT>
<OT>
Zitat von @16568:
@Biber:
Du hast ihm seine Frage nicht beantwortet, sondern lediglich einen Workaround geliefert, wie er es besser machen könnte
Meiner Einschätzung nach greift aber auch oft das wortwörtliche Beantworten der gestellten eigentlichen Frage zu kurz.@Biber:
Du hast ihm seine Frage nicht beantwortet, sondern lediglich einen Workaround geliefert, wie er es besser machen könnte
Das erlebe ich ja auch jeden Tag in "Batch & Shell", wenn jemand mit Tunnelblick seine Frage auf ein "Wo ist der Tippfehler in meinem Skript?" reduziert
Abgesehen davon - du beschränkst dich ja auch gottseidank nicht nur auf die buchstabengetreue Abarbeitung der Frage...
Grüße
Biber
</OT>
Hallo Biber und Danke für die ausführliche Antwort!
Ein Weg, wie ich es besser machen kann, ist mir natürlich noch lieber. Da nunmal die Kombination aus mcrypt und MySQL da war, stellte sich natürlich erstmal die Frage, ob man daraus in Verbindung mit Access was machen kann (die Daten per WebRequest über eine PHP-Datei zu holen oder eben die mcrypt-Funktion in VBA etc.), aber sinnvoller scheint es da wirklich zu sein, die SQL-eigene Funktion zu nutzen.
Habe das PHP-Script also mal abgeändert, sodass nicht mehr mcrypt genutzt wird, sondern die Daten über den SQL-Befehl mit AES_ENCRYPT / AES_DECRYPT ver-/entschlüsselt werden. Funktioniert beim Schreiben und Lesen der Daten mit PHP auch ohne Probleme. Wenn ich nun die Tabelle mittels ODBC mit Access verknüpfe und dort die SQL-Abfrage SELECT AES_DECRYPT(data, 'irgendeinschluessel') ausführe, meckert Access "Undefinierte Funktion 'AES_DECRYPT'. Wie Du merkst, arbeite ich sonst auf einem anderen Gebiet und hatte diesbezüglich mit Access nie großartig Berührungspunkte, wäre da also für einen Tipp dankbar.
Gruß
pagerank0
Ein Weg, wie ich es besser machen kann, ist mir natürlich noch lieber. Da nunmal die Kombination aus mcrypt und MySQL da war, stellte sich natürlich erstmal die Frage, ob man daraus in Verbindung mit Access was machen kann (die Daten per WebRequest über eine PHP-Datei zu holen oder eben die mcrypt-Funktion in VBA etc.), aber sinnvoller scheint es da wirklich zu sein, die SQL-eigene Funktion zu nutzen.
Habe das PHP-Script also mal abgeändert, sodass nicht mehr mcrypt genutzt wird, sondern die Daten über den SQL-Befehl mit AES_ENCRYPT / AES_DECRYPT ver-/entschlüsselt werden. Funktioniert beim Schreiben und Lesen der Daten mit PHP auch ohne Probleme. Wenn ich nun die Tabelle mittels ODBC mit Access verknüpfe und dort die SQL-Abfrage SELECT AES_DECRYPT(data, 'irgendeinschluessel') ausführe, meckert Access "Undefinierte Funktion 'AES_DECRYPT'. Wie Du merkst, arbeite ich sonst auf einem anderen Gebiet und hatte diesbezüglich mit Access nie großartig Berührungspunkte, wäre da also für einen Tipp dankbar.
Gruß
pagerank0
Moin pagerank0,
na ja, Teil 1 der Ansprache war das Verwenden der Built-In-Functions AES_Decrypt() etc.
Teil 2 war eigentlich das Bereitstellen eines "unverschlüsselten" Views für die ACCESS-Lese-Belange.
Ich hatte es so verstanden, dass dieser Zugriff via Access vorrangig zum Lesen gedacht war.
Also sollte doch irgendetwas a la
dafür reichen.
Selbst das Suchen nach Werten sollte ja keine Probleme machen, da jede/r User/In natürlicherweise nach lesbaren, unverschlüsselten Werten Ausschau hält.
Für den zweiten Fall, dass Du auch INSERTs und UPDATEs benötigst --- hmm, sicherlich gibt es da bestimmt auch einfache Lösungen, aber da verweise ich auf LSW.
Ich würde (vollkommen naiv und ohne Erfahrung mit dieser Konstellation) das Schreiben von "neuen" Daten entweder via Stored Procedure abfackeln oder mit einer Zwischentabelle und Triggern.
Also so oder so Serverseitig auf dem DB-Blech und nicht irgendwie mit geliehenen Schlüsseln auf der Frontend-Access-Seite.
Access sollte im Idealfall ja eben keinen Schlüssel für AES_Decrypt() o.ä. "kennen" müssen. Die Access-Appz hat das Leserecht, ist authentifiziert dadurch, dass sie überhaupt eine Connection gegen das mySQl-Blech aufmachen darf und welcher User das auf Clientseite starten darf, das habt ihr ja in der Hand.
Aber da halte ich mich erstmal zurück und warte ab, ob denn bei dir bzw. deiner Appz mehr als LESEN nötig ist.
Grüße
Biber
na ja, Teil 1 der Ansprache war das Verwenden der Built-In-Functions AES_Decrypt() etc.
Teil 2 war eigentlich das Bereitstellen eines "unverschlüsselten" Views für die ACCESS-Lese-Belange.
Ich hatte es so verstanden, dass dieser Zugriff via Access vorrangig zum Lesen gedacht war.
Also sollte doch irgendetwas a la
CREATE VIEW ReadView4Access (meineSpalte1, ...meinespalteN)
AS
SELECT AES_DECRYPT(data1, 'irgendeinschluessel') ,
....
SELECT AES_DECRYPT(dataN, 'irgendeinschluessel') , Selbst das Suchen nach Werten sollte ja keine Probleme machen, da jede/r User/In natürlicherweise nach lesbaren, unverschlüsselten Werten Ausschau hält.
Für den zweiten Fall, dass Du auch INSERTs und UPDATEs benötigst --- hmm, sicherlich gibt es da bestimmt auch einfache Lösungen, aber da verweise ich auf LSW.
Ich würde (vollkommen naiv und ohne Erfahrung mit dieser Konstellation) das Schreiben von "neuen" Daten entweder via Stored Procedure abfackeln oder mit einer Zwischentabelle und Triggern.
Also so oder so Serverseitig auf dem DB-Blech und nicht irgendwie mit geliehenen Schlüsseln auf der Frontend-Access-Seite.
Access sollte im Idealfall ja eben keinen Schlüssel für AES_Decrypt() o.ä. "kennen" müssen. Die Access-Appz hat das Leserecht, ist authentifiziert dadurch, dass sie überhaupt eine Connection gegen das mySQl-Blech aufmachen darf und welcher User das auf Clientseite starten darf, das habt ihr ja in der Hand.
Aber da halte ich mich erstmal zurück und warte ab, ob denn bei dir bzw. deiner Appz mehr als LESEN nötig ist.
Grüße
Biber
Hi Biber,
prinzipiell würde erstmal ein View reichen, die Einträge, die von Access zurück zur MySQL-DB gehen, betreffen im Grunde nur unverschlüsselte Tabellen, nur beim Lesen sind einige verschlüsselte dabei. Werde es morgen so versuchen, wie Du geschrieben hast. Nochmals vielen Dank für die schnelle Hilfe!
Gruß
pagerank0
prinzipiell würde erstmal ein View reichen, die Einträge, die von Access zurück zur MySQL-DB gehen, betreffen im Grunde nur unverschlüsselte Tabellen, nur beim Lesen sind einige verschlüsselte dabei. Werde es morgen so versuchen, wie Du geschrieben hast. Nochmals vielen Dank für die schnelle Hilfe!
Gruß
pagerank0
Hallo nochmal,
wolte nur kurz Bescheid geben, dass das Problem gelöst ist, also Danke nochmal.
Gruß
pagerank0
wolte nur kurz Bescheid geben, dass das Problem gelöst ist, also Danke nochmal.
Gruß
pagerank0
Moin pagerank0,
danke für die Rückmeldung und freut mich natürlich, wenn es so klappt, wie ich es als Theoretiker angegangen wäre.
Fairerweise: ich weiss wirklich nicht, ob es einen besseren, stabileren oder einen breiter ausgetretenen Pfad zu einer Lösung gibt.
Falls also irgendjemand bei dir vorbeschaut und fragt :"Wieso hast du es nicht einfach so und so gemacht...?" ,
dann bitte ihn doch, die Alternative noch hier zu ergänzen.
Grüße
Biber
danke für die Rückmeldung und freut mich natürlich, wenn es so klappt, wie ich es als Theoretiker angegangen wäre.
Fairerweise: ich weiss wirklich nicht, ob es einen besseren, stabileren oder einen breiter ausgetretenen Pfad zu einer Lösung gibt.
Falls also irgendjemand bei dir vorbeschaut und fragt :"Wieso hast du es nicht einfach so und so gemacht...?" ,
dann bitte ihn doch, die Alternative noch hier zu ergänzen.
Grüße
Biber
