[PHP/SQL] Bestaande data linken aan nieuw account

[Snippo]

Voor een programma met klantengegevens wil ik de bestaande data uit het klantenbestand linken aan de nog te creëeren account voor de specifieke klant. Ik kom er alleen niet uit hoe ik de nieuwe account (veilig) aan de bestaande data link, of dat dit uberhaupt mogelijk is.

Het is natuurlijk simpel te maken met een ID = ... veld, maar dit mag niet ingevuld worden door de klant. Mijn idee was om een link te maken waarbij dit veld al ingevuld is, maar waarbij de gegevens niet worden geaccepteerd als het ID veld veranderd is (dus geen verborgen of read-only velden die een slimme klant alsnog aan kan passen).
Ik kom er alleen niet uit hoe ik dit moet doen...
Kan iemand me in de goede richting wijzen als dit uberhaupt mogelijk is? Ik heb al gezocht op internet maar daar kom ik vooral oplossingen tegen voor niet-gevoelige data, wat in dit geval dus niet werkt (bijv. verborgen velden). Ik gebruik overigens het Laravel framework met een MySQL database.

[DiedX]

Ik ben geen programmeur, maar het lijkt mij toch dat je je klant in je huidige framework uniek kan identificeren? Die key naar de andere kant halen lijkt mij toch de oplossing?

[RobIII]

Zoals ik het begrijp wil je een klant account X aan account Y laten linken d.m.v. (bijvoorbeeld) het toesturen van een e-mail link?

Dan 'sign' je de link gewoon met een hash. Stel je link is iets als:

http://mijnsite.nl/link?from=X&to=Y

Dan neem je de hash van X + een geheime 'sleutel' (random string van, zeg, 20 random tekens):

code = hash("diTisEenGehEim3SleUt3l!VetteShitOuwE!" + X)

Waarbij de hash functie bijv. MD5/SHA1/SHA256 is of whatever (vermijd MD5 als het kan maar ook dat werkt prima). Vervolgens wordt de link die je toemailt dan iets als:

http://mijnsite.nl/link?from=X&to=Y&code=eaa015f2ff4398c141f05f1ecbae38328d93d219

Waarbij ik in dit voorbeeld SHA1(<sleutel> + <X>) heb gedaan, maar, zoals gezegd, zo'n beetje elke hash functie werkt.

Vervolgens controleer je bij submit of hash(<sleutel> + $_POST['from']) gelijk is aan $_POST['code'] en dan weet je (vrijwel) zeker dat er niet geknoeid is met de data. Uiteraard is 't wel belangrijk de sleutel geheim te houden. Je zou per klant/account een aparte sleutel kunnen gebruiken maar een enkele sleutel (mits goed en veilig opgeslagen) werkt in principe ook en scheelt je per klant/account een sleutel opslaan.

edit: Overigens, afhankelijk van hoe veilig je 't wil hebben kun je ook nog kiezen voor zwaardere hashes als Bcrypt/Scrypt, link expiratie (bijv. max x uur geldig) en de, al eerder genoemde, per klant unieke sleutel (of salt).

[ Voor 23% gewijzigd door RobIII op 09-01-2017 23:19 ]

[Snippo]

Ah, ik zat inderdaad al aan zo'n hash te denken. Ik kwam er alleen niet uit hoe ik uiteindelijk ging verifiëren of dat het ingevulde veld niet veranderd was. Voor de verificatie moet je natuurlijk weten wat de waarde moet zijn, maar daarvoor is een 'link' tussen de front-end en back-end nodig.
Ik denk dat het meesturen van de gehashte waarde (sleutel + X) dan inderdaad de oplossing is.

Voor mijn gevoel kon het ook niet ingewikkeld zijn, maar ik kwam er niet uit

Bedankt

DiedX schreef op maandag 9 januari 2017 @ 17:37:
Ik ben geen programmeur, maar het lijkt mij toch dat je je klant in je huidige framework uniek kan identificeren? Die key naar de andere kant halen lijkt mij toch de oplossing?

Ik begrijp niet helemaal wat je bedoelt. Ze zijn inderdaad uniek te identificeren, maar die identificatie dient wel door mij te gebeuren en niet door de klant zelf (want dat zou inhouden dat die alle gegevens van andere klanten ook in kan zien).

[ Voor 35% gewijzigd door Snippo op 09-01-2017 19:00 ]

[Cartman!]

RobIII schreef op maandag 9 januari 2017 @ 17:45:
<verhaal>

Ter aanvulling, dit beschrijft min of meer de werking van JWT en is misschien iets meer plug & play in gebruik

[webinn]

je zou nog een unieke salt kunnen toevoegen per klant (opslaan in je database) zodat je master key niet direct kan uitlekken.

(sorry, stond ook al bij Roblll)

[ Voor 12% gewijzigd door webinn op 09-01-2017 19:35 ]