On Sun, 02 Jan 2011 18:58:05 -0000, Andraž Kos <[email protected]> wrote:
Everything in the user land can be changed/transformed/spoofed and can't be trusted.
I trust the user who invokes the bookmarklet, by definition (and shared secret is supposed to prove that it's the user sending the request). I don't trust webpage that bookmarklet is invoked on, so I need a robust way to distinguish user-initiated client-side action from webpage-initiated client-side action.
Why hide the key? Show it off. The only option you have any way, is to use back end database of randomly generated hashes, then you integrate the hash into the bookmarklet. This way you have a signature that can't be faked without access to the back end database. Because it is just random data it also can't be reverse engineered.
It's not a problem to make the secret unguessable. The problem is that the secret key could be captured when bookmarklet is used, or request generated by the bookmarklet could be modified by the page. Even use of one-time keys won't mitigate that.
Make the process of obtaining a working hash-signature hard, with captcha, email registration, stuff like that.
It's irrelevant how hard it's for user to get a new hash. I'm not defending against user's actions, but website's actions. -- regards, porneL -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
