Alternatief voor base64
Ik stuur voor validatie-redenen een gecodeerde ID (reeks cijfers) mee met mijn contact formulier, daarvoor gebruik ik base64. Echter is deze functie niet toegestaan binnen het CMS wat ik gebruik (WordPress). Dus ik ben op zoek naar een alternatief. Nu kwam ik md5 tegen, alleen lees ik op diverse fora dat dit een one-way encryptie is en je dit niet kunt decrypten.. Kan iemand mij uitleggen hoe je de hash dan weer omzet naar een reeks cijfers, of hoe dit dan wel gebruikt moet worden? Een andere alternatief is ook welkom.
Guido
Verder is er niks met base64. Al vraag ik mij af hoe je bedoelt dat het niet toegestaan is?
base64 is niet toegestaan binnen WordPress omdat het vrij eenvoudig te misbruiken is.. zegt men.
Guido
https://www.php.net/manual/en/ref.hash.php
Maar het niets te maken met encryptie.
Wil je encryptie, kijk dan hier (o.a.) :
https://www.geeksforgeeks.org/how-to-encrypt-and-decrypt-a-php-string/
https://www.php.net/manual/en/book.openssl.php
https://www.scaler.com/topics/php-tutorial/php-encrypt-decrypt/
Guido - op 05/01/2024 21:51:11:
base64 is niet toegestaan binnen WordPress omdat het vrij eenvoudig te misbruiken is.. zegt men.
base64 is niet toegestaan binnen WordPress omdat het vrij eenvoudig te misbruiken is.. zegt men.
Wat is je bron? En op wat voor misbruik doel je precies?
Ik kies dan voor de hash() functie, maar kom terug bij een eerdere vraag: hoe on-hash ik dit? Ik lees dat dit one-way is. Maar hoe kan ik die versleutelde waarde dan gebruiken?
Adoptive Solution op 05/01/2024 21:19:01:
Een hash is geen encryptie, in welke richting dan ook.
Guido
Die vergelijk je dan met de ingevulde waarde die je op dezelfde manier hashed, en dan weet je dat ze gelijk zijn.
Logisch.. niet aan gedacht het zo te doen!
Je vroeg eerder naar de bron.. Het bezwaar is niet persé misbruik, maar verbergen van mogelijk verkeerde code of tekst:
https://www.pluginvulnerabilities.com/2017/10/30/base64-obfuscation-used-in-wordpress-plugins-code-that-emails-details-of-website-to-developer/
Guido
Wat houdt je tegen om het te gebruiken, als het in een andere context gebruikt cq. misbruikt wordt?
https://www.php.net/manual/en/function.openssl-encrypt.php en https://www.php.net/manual/en/function.openssl-decrypt.php gebruiken om de boel te coderen en later weer te decoderen.
Base64 is geen encryptie. Iedereen met een beetje verstand van zaken kan gokken dat die riedel een base64 gecodeerd stukje data is, het eens decoderen, en misschien de boel aanpassen om dingen voor elkaar te krijgen die je eigenlijk niet bedacht had. Het liefst geef je helemaal geen "belangrijke data" op deze manier mee, maar sla je die bijvoorbeeld gewoon op in de session. Anders kun je in ieder geval "pro" gaan bijvoorbeeld via We kunnen de vraag ook kort stellen: Mag de bezoeker weten wat je te te verbergen hebt in die string?
Hashing is éénrichtingsverkeer.
Stel je hebt de string "geheime tekst". Via encryptie maak je daarvan "ABCXYZ123" (fictief). Via decryptie maak je vervolgens van "ABCXYZ123" weer "geheime tekst". Dus aan de hand van de geëncrypte string "ABCXYZ123" kun je de originele string "geheime tekst" weer herleiden.
Bij een hash werkt het anders. De string "geheime tekst" verandert dan in "XZYDEF123" (fictief). Uit "XZYDEF123" kan je niks meer afleiden. Het is onmogelijk om te weten wat de originele string was. Om te weten of de gehashte string "XZYDEF123" bij "geheime tekst" hoort, ga je "geheime tekst" opnieuw hashen, en je kijkt of daar de string "XZYDEF123" uit komt. Zo ja, dan was het origineel "geheime tekst". Zo nee, dan was het origineel iets anders.
Ter info zal ik even uitleggen hoe het werkt bij mij.
Mijn formulier toont een willekeurige som captcha.
Ik voeg de uitkomst ook toe als hidden input.
Tijdens versturen wordt die uitkomst in database opgeslagen (dmv een WordPress "transient").
De invoer van invuller wordt vergeleken met uitkomst in database.
Daarna wordt de "transient" verwijderd uit database.
Doordat de "transient" niet meer bestaat, is de inzending niet bruikbaar voor een repeater bot die $_post hergebruikt.
(ik gebruik reeds de Post/Redirect/Get methode)
Guido
Guido - op 06/01/2024 12:35:02:
Ik voeg de uitkomst ook toe als hidden input.
Tijdens versturen wordt die uitkomst in database opgeslagen [...]
Tijdens versturen wordt die uitkomst in database opgeslagen [...]
Dan is de uitkomst uitsluitend opslaan in de sessie veiliger én efficiënter.
Guido
Waarschijnlijk begrijp ik je verkeerd, maar zeg je nu dat je de uitkomst (datgene wat de persoon die het formulier verstuurt als uitkomst moet invullen) ook meestuurt in het formulier zelf?
Als je inderdaad de uitkomst meestuurt in het formulier, dan is dat ongeveer hetzelfde alsof je je voordeur op slot draait en de sleutel onder de mat legt. :-)
Zo doe ik het wel, maar dus gecodeerd. Nav deze thread zal ik de uitkomst als hash meesturen. Maar zonder een transient (zie eerdere reply) is het onmogelijk om formulier succesvol te versturen.
Guido
Let op. Als je een 'bekende' manier van hashen gebruikt, dan heeft het weinig zin. Dan kan via een 'dictionary' (voor uitleg zoek via Google naar "hashing dictionary attack") alsnog makkelijk het juiste antwoord worden bepaald.
Ik zou, als je dan toch via een database werkt, het anders doen.
In het hidden input field van het formulier zou ik een random string opslaan. Die string sla je ook op in de database met daarbij een tweede veld waarin je de uitkomst opslaat.
Als je het op deze manier doet, is de uitkomt op geen enkele manier te herleiden uit je hidden input field.