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 at 
> http://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.

Reply via email to