[Chicago] Handling secret stuff
Japhy Bartlett
japhy at pearachute.com
Mon May 16 16:40:12 EDT 2016
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/61b5d7f4/attachment.html>
More information about the Chicago
mailing list