Sorry, misunderstood your original post. I thought that this is what you were talking about. In any case, the encryption of params is still a good idea. Used in conjuncture with owner/edit assurance would be best. I don't know if the entire URL would have to be encrypted (as suggested). However, the readability of links with params is not high on my list of must-haves. The fact is that if I go through the trouble of encrypting params, this is not a page I consider to be bookmarkable or directly accessible. Therefore, any attempt to access such a page outside of some business process's context would redirect to some other (error/oops/login) page.
>The thing with obfuscation...sketchy. Obfuscation, in this case, would be achieved through encryption. On 11/12/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > The thing with obfuscation is that it always struck me as sort of > false security e.g. "oh, I use GUIDS for ID's and nobody can *guess* the > administrator's GUID" so it's safe. I know you're actually talking about > defensing against precisely this scenario by obfuscating the IDs so nobody > can tell what your key generation function is, but the underlying > principal > still strikes me as sketchy. > > The ultimate approach, of course, is to not bother with signing, but > instead simply encrypt every outbound URL, which would satisfy both our > requirements: A) obfuscated B) owner/edit assurance. I was actually > hesitant > to go down that road in this implementation though because it would > produce > *really* ugly URLs and I know a lot of folks on the mailing list think the > default Tapestry URLs are already too ugly and a Base64 encoded RSA > encrypted string make the existing URLs look downright welcoming :). > > --- Pat > > > -----Original Message----- > > From: Todd Orr [mailto:[EMAIL PROTECTED] > > Sent: Saturday, November 12, 2005 11:54 AM > > To: Tapestry users > > Subject: Re: Secure Direct Links > > > > Even if the owner/edit is enforced, it's still a good idea to obfuscate > > the > > ids passed through parameters. This lessens the likelihood of a curious > > observer who is attempting to get an idea of how your db schema is > > designed. > > Okay, maybe that's an exaggeration, but at a minimum nobody can > determine > > whether I'm using a sequential id generation scheme or a random (say > guid) > > scheme. I like the idea. > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
