[Chicago] Handling secret stuff

Japhy Bartlett japhy at pearachute.com
Mon May 16 16:52:46 EDT 2016


Oh I see the other half of this thread.  Awkward, it will pretty much
always be insecure until you add a server that you/your client control.

On Mon, May 16, 2016 at 3:40 PM, Japhy Bartlett <japhy at pearachute.com>
wrote:

> Generally what you'd do is make the signed API calls from the server (via
> requests, or curl or whatever), and never, ever expose the private key to
> the browser.
>
> At that point, the key is only accessible by people who have access to the
> server or the codebase.  For the latter, there's quite a few tricks for
> keeping the key out of your repository; environment variables, separate
> files, etc.  For the former, it's assumed that your sysadmins are
> trustworthy!
>
> - Japhy
>
>
>
> On Mon, May 16, 2016 at 3:06 PM, Nick Timkovich <prometheus235 at gmail.com>
> wrote:
>
>> What is this "code trail"? Every time you start up a session (among other
>> things) on a Django site it's automatically hitting the SECRET_KEY to build
>> a token for the user. Despite knowing that, the key, for all intents and
>> purposes, is safe.
>>
>> Is your presumed attacker a malicious temp employee who has access to
>> your client? Are you exposing the key to the employee's client (ick), if
>> not, how does said employee get at it?
>>
>> On Mon, May 16, 2016 at 2:39 PM, Leon Shernoff <
>> leon at mushroomthejournal.com> wrote:
>>
>>> Thanks, Adam and Rob!
>>>
>>> I'm not worried about transmission -- yes, we have an SSL certificate
>>> etc. My concern is with storage of the API key on the client's website.
>>>
>>> The service provider in question does things a little differently from
>>> Braintree: it's a two-step process. The client has a secret API key that
>>> sort of serves as an authentication of last resort. The client sends
>>> financial data to service provider along with a public API key and the
>>> service provider sends back a one-time token that (hopefully) indicates
>>> that the proposed transaction has been checked out and can move forward.
>>> Client then returns that token along with the secret API key to service
>>> provider, and money then actually changes hands.
>>>
>>> The client is running a temp agency, with work being done over distance.
>>> The proposed architecture is that the temps log in to clients website
>>> (which is Wordpress), fill out the amount they are charging the customer,
>>> etc, and hits a button initiating this complete back-and-forth process.
>>>
>>> My concern is that if the whole process is automated and triggered by
>>> the temp hitting the button, this leaves a code trail to the secret API
>>> key. Sure, the page in question can be protected in various ways, but
>>> there's still a code trail that... well, if there's a programmatic sequence
>>> of steps that involves retrieving the key, those steps can also be traced
>>> by an outsider if they can get at the page somehow.
>>>
>>> My thought was to have the temp's page merely log the information
>>> (including the returned token) from the temp's payment request into the Wp
>>> database (I'm not worried about the security of Wordpress). I would then
>>> have a completely separate scheduled process go through these log entries
>>> and complete the second part of the back-and-forth for all of them at once.
>>> That way, the sequence of programmed events that retrieves the key doesn't
>>> need to have any involvement with the public interface at all. This seems
>>> more secure to me -- no code trail. But I don't know what SOP is in this
>>> sort of situation -- or if there is any. Like I said, I don't know if
>>> there's any best practices here or what. Any help appreciated! :-)
>>>
>>>
>>> Thanks!
>>>
>>> --
>>> Best regards,
>>>     Leon
>>>
>>> "Creative work defines itself; therefore, confront the work."
>>>      -- John Cage
>>>
>>>
>>> Leon Shernoff
>>> 1511 E 54th St, Bsmt
>>> Chicago, IL  60615
>>>
>>> (312) 320-2190
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160516/fa4b05b0/attachment-0001.html>


More information about the Chicago mailing list