Monthly Archives: September 2015

The New API Transactions Dashboard


The new Transactions dashboard, launched recently, is also referred to as “API call history”. It provides histories of the transactions (API calls) made by applications in the sandbox and live environments. It provides details such as the date of the transaction, type of the transaction, status, amount, as well as the details of the API call, such as the request and response messages.

The new dashboard has many features:

  • Displays history of all PayPal REST APIs.
  • Shows API call details like HTTP status code, request, response and headers to help with diagnostics.
  • Provides the ability to browse and find details quickly through pagination and filters.
  • Has 10x better performance.

Live Transactions Dashboard

An example of the live transactions dashboard is shown below

Live Transactions Dashboard

The live dashboard displays the following:

  • HTTP status
  • Resource URI that was invoked
  • Transaction ID
  • Transaction Date

You can browse transactions for all your applications and filter transactions based on the application name. The dashboard also gives you the ability to view the details of a transaction. By clicking a transaction in the table above, you will see a popup like the below:

Live Transactions Metadata

It has the following fields:

  • Metadata – Metadata about the transaction Request
  • HTTP request, including headers Response
  • HTTP response, including headers

Sandbox Transactions Dashboard

An example of the sandbox transactions dashboard is shown below:

Sandbox Transactions Dashboard

The sandbox transaction dashboard is similar to the live transaction dashboard, except that you can also filter the transactions based on the sandbox account. Since a developer can have multiple sandbox accounts associated with multiple sandbox applications, filtering on the basis of either a sandbox account email or an application can help you quickly find the transaction you are looking for.

Miscellaneous Information

The new dashboard can be accessed via the following links:

Rahul PanjrathAuthor: Rahul Panjrath
About the author: I am Software Engineer @Braintree|PayPal since April 2014, part of the team responsible for Coding is my passion and I love to break things daily ;). I graduated from San Jose State University and I have been in the software industry coding for almost 9 years and I am still learning new things everyday. That’s the best part which makes me love the work I do. I specialize in web programming, REST APIs development, TDD etc.

I can be reached at:

TLS Version and Cipher Suites Order Matter: Here’s Why.


As with a great many things, when it comes to internet security, the only constant is change. While the framework for secure web communication has been around since the development of SSL in 1994, the specific protocols and ciphers continue to evolve. In order to keep up with the changes, the InfoSec community must continually evaluate new potential threats in the context of security and ongoing usability of older systems. Just as system patches and OS upgrades are regularly released to fix known issues, new and improved protocols and cipher suites are developed that correct inherent flaws and mitigate new threats. However, no matter how well designed they are, vulnerabilities and weaknesses will emerge during the lifespan of any protocol or cipher suite, so PayPal pays close attention to those threats as they could affect both our customers and us.

PayPal recently reevaluated the TLS cipher suites for its web site after assessing the numerous clients visiting the site (from legacy ones to the most modern configurations). We currently support TLS versions 1.2 to 1.0, prioritized in that order, and our cipher suites selection and prioritization is based on factors such as availability, business needs, security, and compliance requirements. Efficiency is also a factor, as some ciphers can slow down transactions because their algorithms are more demanding. In some cases, a company may opt for increased speed over a more secure connection. Since we are entrusted with your financial transactions and personal information, however, we lean toward security over speed.

In order to set up a secure connection between a server and a client via TLS, both parties must be capable of running the same version of the TLS protocol and have common cipher suites installed. To initiate the process, the client (e.g. a web browser) advertises, to the server, the TLS versions and cipher suites it supports. The server, when deciding on the cipher suite that will be used for the TLS connection, may give the priority to the client’s cipher suites list (picking the first one it also supports) OR it may choose to prioritize its own list (picking the first one in its list that the client supports). At PayPal we prefer the latter process as it allows us to ensure we set up the most secure communication channel possible.

More specifically, PayPal now prioritizes ciphers that leverage Elliptic Curves and the Diffie–Hellman key exchange mechanism over RSA (namely ECDHE based cipher suites). In addition, we prioritized ECDHE because it leverages the concept of forward secrecy. The last E in ECDHE stands for ephemeral. It means that the generated key pair is temporary and a new set will be generated during each handshake. This is an important property that prevents the decryption of previous TLS conversations even in the case of a stolen private (server) key. This makes it the most secure mode of key exchange to date. As more clients are supporting ECDHE, we prioritize it so that we connect at the most secure level possible.

Despite these advances, we do continue allowing older cipher suites to be used when a client can’t negotiate a more secure connection. We do so in order to support users running legacy platforms like Windows XP and IE6. Fortunately, the number of outdated client is dwindling and we’ll soon cut them off entirely. We’re currently ending support for outdated cipher suites such as RC4 that are only connecting at a rate of roughly one in one million; it’s just a matter of time before we make the next cut.

During our routine investigation of our TLS version and cipher suites order we learned a great deal about how many of our customers are currently able to support higher security TLS connections, helping us plan for future upgrades. This research not only helps increase security, but also minimizes disruption in the customer experience.

In the coming weeks we will publish more of our research on how we determined the optimal TLS version and cipher suites ordering. We hope to help others learn from our experience and improve security for everyone in the online ecosystem. Until then, remember to pay with PayPal to stay safe and secure!

PayPal Sponsors First of Its Kind Intel Capture the Flag Contest at DEFCON 23


DEFCON routinely presents the coolest and most thought provoking topics in the hacking community and this year did not disappoint, partially due to the first PayPal-sponsored Intel Capture the Flag (CTF) virtual manhunt contest. IntelCTF events challenge players to utilize their open source intelligence (OSINT) forensic skills in order to identify malicious actors intent on Internet mayhem. Players find strategically placed “flags” that are planted across the Internet as breadcrumbs, allowing them to solve the e-case of whodunit by simply connecting the virtual dots.

This contest, (rated Beginner/Intermediate) which is the first of several that are scheduled for release in the near future, tasked participants with identifying an actor who defaced a rather “popular” webpage. Team participants may use any means necessary to track and identify the perpetrator. It touted 17 flags of increasing difficulty and asked questions such as the timestamp of when certain posts were made, how a website was hacked, the owner of the proxy service the actor was using, and finally, the defacer’s real identity.

Various members of the PayPal Information Security team in Scottsdale, Arizona partnered with several alpha/beta testers to run the 6 hour, 24-team event. The event started a bit slowly as players adjusted to the gaming style but at around the 30-minute mark the competition heated up! The Attribution-Team and Killjoys were neck-in-neck for flags 11 and 12. The Attribution-Team ended up capturing the 13th flag before Killjoys in the final hour. After six long hours of competition, the scoring engine was shut down and the event concluded. The Attribution-Team submitted a write-up detailing their investigative process. It was then reviewed by the IntelCTF team confirming no cheating or flag brute forcing occurred. The IntelCTF team confirmed that the Attribution-Team was the winning team, capturing thirteen out of seventeen flags before the others and winning the $500 USD prize. Below is a snapshot of the top five contenders and the final scoreboard for all teams:

  1. Attribution-Team – 13 flags and $500 USD prize
  2. Killjoys – 13 flags
  3. BAMFBadgers – 12 flags
  4. I tried… but failed – 12 flags
  5. StenoPlasma – 11 flags

Screen Shot 2015-08-19 at 11.48.45 AM

This event was different than past contests because IntelCTF is the first of its kind! Traditional CTFs focus more on WebApp pentesting, reverse-engineering, forensics, and programming challenges where as IntelCTF immerses participants into simulated scenarios of tracking down information about the tools, techniques, capability, and identity of malicious individuals. It generated a lot of interest and excitement and feedback from participants was very positive. Not only did participants thoroughly enjoy the immersive challenge but also asked when IntelCTF would be running the next event and where.

Think you have what it takes to capture the flag? Check out these upcoming IntelCTF challenges and keep your eye out for more PayPal-sponsored information security events.