PHP Verschlüsseln und entschlüsseln

[Konto gelöscht]

Hallo Leute,

ich habe da etwas „geerbt“ und möchte dies optimieren. Es geht dabei um eine Art Passwort-Manager im lokalen Netzwerk. Mein Vorgänger hat da ein kleines Modul programmiert das im Ticketsystem hängt. Die Passwörter speichert er dabei mit mcrypt verschlüsselt in der Datenbank.

Da ich nun PHP auf 7.4 aktualisieren muss, läuft das nicht mehr, da mcrypt nicht mehr wirklich existiert standardmäßig.
Wie kann ich das sicher und modern gestalten, so dass die Kennwörter nicht im Klartext in der Datenbank stehen? Gibt es da eine Alternative?
Ich muss die Daten ja irgendwie wieder umwandeln können und lesbar machen, wenn man sie mal braucht ☺️

 

[jonderson]

Also mir wäre es ehrlich gesagt zu heikel einen Passwort-Manager zu programmieren...

https://bitwarden.com/

 

[Bagbag]

Man speichert Kennwörter nicht in der Datenbank, auch nicht verschlüsselt. Man leitet davon mit einer "Schlüsselableitungsfunktion" einen Wert ab und speichert diesen. Vereinfacht ausgedrückt ist das ein Hash, den du nur in eine Richtung berechnen kannst.

Ohne Ahnung von der Materie sollte man sowas nicht selbst machen.

 

[Yuuri]

Entschlüsseln, mit einem 7.4 kompatiblen Modul verschlüsseln, upgraden.

 

[Konto gelöscht]

Ne ihr versteht das nicht ganz richtig. Es ist kein richtiger Passwort Manager so wie ihr ihn kennt. Die Kunden haben mit uns ein Wort oder eine Zahlenkombi ausgemacht, womit sie sich Legitimieren. Wenn dann jemand anruft und wir Änderungen vornehmen, muss der Kunde dieses Wort nennen. Das „Passwort“ möchte ich nun sicher speichern. Das Ticket kann nur eröffnet werden, wenn das „Passwort“ korrekt ist. So ist der Kunde sicher, dass die Änderungen unsererseits auch von Kunden wirklich kommen und andersherum kann kein Mitarbeiter irgendwas ändern ohne dieses Kennwort zu haben. Es sind keine Zugangsdaten für Software XY und so. ☺

Da muss es doch eine Alternative geben.

 

[Yuuri]

Wenn es nur eine Prüfung ist, hash es einfach via BCrypt/Argon (password_hash). Falls es falsch ist, setz es zurück/erstell ein Neues. Verschlüsselung benötigst du nur, wenn du wirkliche Daten hast und keine Abfragen, ob irgendwas stimmt.

Verschlüsselung in deinem Falle wäre nur sinnvoll, wenn anhand des Passworts die Kundendaten individuell verschlüsselt bei euch vorliegen würden. Aber selbst hier nutzt man eher eine andere Legitimation als ein "simples" Passwort.

Auf jeden Fall ist der Weg der Verschlüsselung wohl überflüssig. Und sag bitte nicht, dass du mit einem statischen Schlüssel verschlüsselst?! Dann kannst du es gleich plain text vorliegen lassen und es entspricht nur Security through Obscurity. Kannst es dann genauso auch via Base64 o.ä. zweckfreien "Verschlüsselungen" "verschlüsseln". Das ist so sinnvoll wie einen String mit ROT13 zu "verschlüsseln". Nennen wir es doch einfach mal obfuskieren...

 

[BeBur]

Also bei mir finde ich was in 5 Sekunden mit Google.
Davon ab sehe ich keinen Grund warum ihr nicht hashen könntet nach deiner Erklärung

 

[Konto gelöscht]

Ach Leute, anstatt mal auf die Frage einzugehen wird immer nur drum herum geblubbert...

Dann lassen wir es. Wie in vielen anderen Threads auch, kommt man nicht mehr zur wirklichen Lösung der Frage sondern diskutiert nur noch herum wer, was, wie und wo, warum und weshalb wann macht.

Macht keinen Spaß mehr hier und lernen kann man auch nichts mehr. Ich lösche meinen Account jetzt.

Danke an die, die wirklich produktiv versucht haben eine Lösung aufzuzeigen.

 

[jonderson]

Okay, bitte Thread schließen, TE möchte einfach nur eine schnelle Lösung haben, die ihm unverständlicherweise aber keiner auf dem Silbertablett servieren möchte..

 

[xep22]

ich nutze das :

Verschlüsseln:

$encryption_key='KEY_HIER';
$encryption_password='PASSWORT_HIER';
$encrypted=openssl_encrypt('TEXT_HIER'), 'AES-256-CTR', $encryption_password, 0, $encryption_key);

Entschlüsseln:

$decryption_key='KEY_HIER';
$decryption_password='PASSWORT_HIER';
$decrypted=openssl_decrypt('TEXT_HIER'), 'AES-256-CTR', $decryption_password, 0, $decryption_key);

 

[Konto gelöscht]

Okay, bitte Thread schließen, TE möchte einfach nur eine schnelle Lösung haben, die ihm unverständlicherweise aber keiner auf dem Silbertablett servieren möchte..

Scheint ja auch zu gehen, wie xep22 zeigt. Wenn ihr einfach nur keine Ahnung habt, postet halt nicht. Genau so wie xep22 schreibt ist ein Forum perfekt! Damit kann man was anfangen. Alles andere drum herum ist einfach nur Spam.

Danke @xep22 für die Alternative! 👌🏼

 

[BeBur]

Google halt nächste mal vorher.

 

[Yuuri]

Macht keinen Spaß mehr hier und lernen kann man auch nichts mehr.

Genau das haben wir dir gesagt! Aber du willst nicht lernen, du willst stumpf irgend nen Ersatz für ne Lösung finden, die vollkommen wirkungsklos ist.

Aber trotzdem nochmal: Verwendest du nen statischen Schlüssel?

 

[Kanibal]

AES im Counter-Mode ist hier explizit keine gute Idee, da es malleable ist. Das möchtest Du wahrscheinlich nicht. Lieber AEAD verwenden!

Will sagen: Man kann sich mit Copy-Paste Snippets gerade bei Crypto sehr schnell die Finger verbrennen.

 

[ayngush]

Nur fürs Google-Archiv, falls das mal jemand anderes ließt; dem TE ist es ja egal:

So wie die Situation beschrieben ist würde es auch technisch machbar sein die Legitimation gegen einen Hashwert zu fahren.

Dazu müsste das System dahingehend umgestellt werden, dass der Mitarbeiter das vereinbarte Kennwort (es ist kein Passwort, wenn man es jemand anderen erzählt!), welches ihm der Kunde am Telefon nennt, in ein Softwaremodul eingibt. Das Softwaremodul prüft dann die Eingabe gegen den gespeicherten Hashwert in der Datenbank und gibt dem Mitarbeiter "Go" oder "No-Go" zurück - ggf. kann man das direkt an das Softwaremodul zur Ticketerstellung ranprogrammieren, sodass das technisch sauber abgebildet ist.
Dazu muss dann kein Kennwort mehr im Klartext gespeichert oder angezeigt werden und ver- und entschlüsselt muss das Kennwort dann auch nicht werden. Wichtig ist es natürlich den Unterschied zwischen einer Verschlüsselung und einer Schlüsselableitung (dem generieren eines Hashwertes) zu verstehen, das muss man sich aber angeeignet haben, wenn man solche Systeme implementiert.

Verschlüsselt man das Kennwort, muss es ja bei der Benutzung (= Legitimation) entschlüsselt werden. Der Schlüssel dazu ist ja ebenfalls ein Geheimnis, mit den man ordentlich umgehen muss. Eigentlich darf man da auch nicht für jeden Kunden das gleiche Geheimnis verwenden um damit das Kundenkennwort zu verschlüsseln. Man darf so etwas auch nicht "Hardwired" in den Quelltext einer Anwendung schreiben usw. usf.

Spekulation: Wie findet die Legitimation denn aktuell statt? Sieht der Mitarbeiter das Kundenkennwort im Klartext und der Kunde nennt es ihm am Telefon? Legitimiert wird dann via "augenscheinlichen Abgleich"? Das wäre nach DSGVO eigentlich kein technisch und organisatorisch korrekter Umgang mit Kundenkennwörtern mehr...

"Knuddels" musste dafür mal 20.000 EUR bezahlen, weil sie mit Passwörtern technisch nicht ordnungsgemäß umgegangen sind (sie haben die Passwörter im Klartext gespeichert - Kritik war, dass sie diese nicht als Hashwert abgespeichert haben). Das war dann ein Verstoß gegen Artikel 32 der DSGVO (https://dsgvo-gesetz.de/art-32-dsgvo/)