The problem I'm wrestling with is how to scramble the timestamp and index so the user can't guess someone else's entry and then access that other person's data.
But the first response led to to wonder if I could encrypt the timestamp and index, and then test that with the encrypted (but not stored) data from the db. That would save having to store what is essentially the same data.
So, in a roundabout way, that helped!
In reference to the second response, I can see how what you suggest would work if you know the values. I'm trying to use two values that are added by mySQL, so I can't know them (as far as I know) at the time I'm running the insert. Maybe there's a variable that represents them?
Darn. When I went to try out that approach, I realized that the data I look for in the dB is the same data that I'm combining and encrypting. So I can't search for the unencrypted data if I only have a combined and encrypted version. (Yes, I could if I could unencrypt it, but mcrypt isn't compiled with my host's php.)
When things get this convoluted, I usually start poking around to see if there isn't a simpler solution!
That's interesting; thanks for looking it up. I can think of two ways to use it. The first I'm not happy with. Am I right to reject the first method?
I could give the user a "password" which is really an encrypted version of their line in the db's auto incremented id. Then when the user comes back to get their card data, mySQL would select the line where the (unencrypted) id is the same as the user's encrpyted id. That would require temporarily encrypting each line's id before testing.
That strikes me as really bloated, a bad method. Do you agree?
It seems to me the faster, more direct method is simply to store the encrypted id (indexed), and then test against it directly when the user returns. And I can use Last_Insert_Id to create the encrypted id--so I'm still in your debt!