Ah, I see what you mean about sending things in plaintext over SSL. You're right, that would be a lot simpler.
That said, I think I can handle the API keys with one model plus less than a dozen lines of verification code, so it's not a huge burden. I just don't have a whole lot of experience devising security schemes, so wanted to make sure the concept was fundamentally sound. ;-) Thanks for all your help! On May 25, 10:26 am, Alex Robbins <alexander.j.robb...@gmail.com> wrote: > Yeah, I understand that the data doesn't need to be encrypted. I just > agree with you that SSL would be ideal. > > If you had SSL, then I don't think you'd need to work as hard with the > public/private key hashing stuff. If all the transmitted data was > encrypted (SSL) you could just send a clear-text password in the post > data. No hashing, no public/private key, just easy. > > Alex > > > > On Tue, May 25, 2010 at 9:17 AM, ringemup <ringe...@gmail.com> wrote: > > > By app-level solution you mean some sort of custom encryption / > > decryption scheme for the data dictionaries? > > > I'm still not convinced the data needs encryption -- I mean, it > > wouldn't hurt and in an ideal world I'd just push everything over SSL, > > but the worst thing that happens if someone gets hold of the data > > we're exchanging is a customer who has to call support because their > > activation key registers as already in-use, not any sort of identity > > theft or loss of financial credentials. > > > Mostly with this I'm just trying to make sure that I can prevent > > unauthorized users from using the API to make themselves free > > activation keys. > > > On May 25, 10:02 am, Alex Robbins <alexander.j.robb...@gmail.com> > > wrote: > >> It might be worth a try to see if the self-signed cert gets you into > >> trouble or not. Some url libraries might complain about it, but I > >> don't think that the behavior is universal. As I think about it, I > >> think it is normally browsers that whine about self-signed certs. > >> Maybe the other server wouldn't even mention it? Anyway, it'd be a lot > >> easier to setup an ssl cert than roll your own app level solution. > > >> Good luck! > >> Alex > > >> On May 24, 10:57 am, ringemup <ringe...@gmail.com> wrote: > > >> > Not a bad idea, actually, but the other site is on shared hosting, so > >> > I don't expect the host to be willing to add a self-signed cert as > >> > trusted. > > >> > On May 24, 10:07 am, Alex Robbins <alexander.j.robb...@gmail.com> > >> > wrote: > > >> > > Just a thought, but if you are the only person using the url, you > >> > > could make your own self-signed security cert. It would be free and > >> > > protect your data. It won't show up as trusted to users, but your > >> > > other server can be set to accept it. (Assuming the lack of ssl is a > >> > > budget issue, that wouldn't fix a technical issue.) > > >> > > Alex > > >> > > On May 23, 10:10 am, ringemup <ringe...@gmail.com> wrote: > > >> > > > Hi folks -- > > >> > > > I'm putting together a simple API to allow a separately-hosted but > >> > > > trusted site to perform a very limited set of actions on my site. > >> > > > I'm > >> > > > wondering whether the design I've come up with is reasonably secure: > > >> > > > - Other site gets an API key, which is actually in two parts, public > >> > > > key and private key, each of which is a uuid generated by Python's > >> > > > uuid module. > > >> > > > - The API key object in the DB references a User object, whose > >> > > > permissions determine what actions the API key owner may take > > >> > > > - Other site submits a POST request to a special URL on my site. > >> > > > POST > >> > > > request contains 3 vars: public_key, data (as JSON), hash. > > >> > > > - Hash is a SHA1 of the data concatenated with the private key > > >> > > > - I use the public key to search the database for the API key and > >> > > > permissions. > > >> > > > - I generate the SHA1 of the data concatenated with the private key > >> > > > from the DB, and check it against the submitted hash; only if they > >> > > > match do I decode the data dict and take the actions specified within > > >> > > > - I then return an HTTP response containing a JSON object of the > >> > > > format: > > >> > > > { > >> > > > return_data: [object containing success / failure codes, > >> > > > messages, > >> > > > any other data], > >> > > > hash: [SHA1 of return_data concatenated with private key] > > >> > > > } > > >> > > > - All data will be transmitted in the clear (no SSL currently > >> > > > available -- *sigh*), but there will be no sensitive data in the > >> > > > incoming data dict. return_data may contain values that aren't meant > >> > > > to be broadcasted, but aren't really sensitive (along the lines of > >> > > > activation keys for a game) > > >> > > > Do you see any major potential flaws in this plan? > > >> > > > Thanks! > > >> > > > -- > >> > > > You received this message because you are subscribed to the Google > >> > > > Groups "Django users" group. > >> > > > To post to this group, send email to django-us...@googlegroups.com. > >> > > > To unsubscribe from this group, send email to > >> > > > django-users+unsubscr...@googlegroups.com. > >> > > > For more options, visit this group > >> > > > athttp://groups.google.com/group/django-users?hl=en. > > >> > > -- > >> > > You received this message because you are subscribed to the Google > >> > > Groups "Django users" group. > >> > > To post to this group, send email to django-us...@googlegroups.com. > >> > > To unsubscribe from this group, send email to > >> > > django-users+unsubscr...@googlegroups.com. > >> > > For more options, visit this group > >> > > athttp://groups.google.com/group/django-users?hl=en. > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Django users" group. > >> > To post to this group, send email to django-us...@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > django-users+unsubscr...@googlegroups.com. > >> > For more options, visit this group > >> > athttp://groups.google.com/group/django-users?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Django users" group. > >> To post to this group, send email to django-us...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> django-users+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> athttp://groups.google.com/group/django-users?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.