<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 3:40 PM, Japhy Bartlett <span dir="ltr"><<a href="mailto:japhy@pearachute.com" target="_blank">japhy@pearachute.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Japhy</div><div><br></div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 3:06 PM, Nick Timkovich <span dir="ltr"><<a href="mailto:prometheus235@gmail.com" target="_blank">prometheus235@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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?</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 2:39 PM, Leon Shernoff <span dir="ltr"><<a href="mailto:leon@mushroomthejournal.com" target="_blank">leon@mushroomthejournal.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, Adam and Rob!<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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! :-)<div><div><br>
<br>
Thanks!<br>
<br>
-- <br>
Best regards,<br>
    Leon<br>
<br>
"Creative work defines itself; therefore, confront the work."<br>
     -- John Cage<br>
<br>
<br>
Leon Shernoff<br>
1511 E 54th St, Bsmt<br>
Chicago, IL  60615<br>
<br>
<a href="tel:%28312%29%20320-2190" value="+13123202190" target="_blank">(312) 320-2190</a><br>
<br>
_______________________________________________<br>
Chicago mailing list<br>
<a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/chicago" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/chicago</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Chicago mailing list<br>
<a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/chicago" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/chicago</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>