Why API Security Is More Complicated Than You Think (and Why It’s Your #1 Priority)

1. API Security It’s Complicated. @dberlind

2. Disclaimers • I don’t necessarily have all the answers. I can and will make some recommendations. But ultimately, I’m a journalist. I interview people. I make observations. This presentation comes from those interviews and observations. • I think I’m pretty up to date. But, there may be new observations or information that make some of my information obsolete. It’s a huge ocean to boil. • Despite what I’m about to share with you, I do not consider myself a security expert. There may be some technical inaccuracies. • This presentation only scratches the surface. But it’s a good conversation starter • By the end, you may think the Internet is doomed. It could be. Unless you do something about it. • I’m terrible at PowerPoint

3. Anatomies of Recent API-related Attacks

4. Anatomy of Attack

5. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints

7. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords

8. Anatomy of Attack

9. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers

11. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords

12. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook

13. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords

15. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data

17. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen

18. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen • Hackers develop code that can pose as Buffer and cycle through all the tokens making posts to Facebook and Twitter via API.

19. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen • Hackers develop code that can pose as Buffer and cycle through all the tokens making posts to Facebook and Twitter via API. • 26-Oct-2013 • Adobe Database published on AnonNews.org

21. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen • Hackers develop code that can pose as Buffer and cycle through all the tokens making posts to Facebook and Twitter via API. • 26-Oct-2013 • Database published on AnonNews.org • Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts

22. Example of Attack

23. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen • Hackers develop code that can pose as Buffer and cycle through all the tokens making posts to Facebook and Twitter via API. • 26-Oct-2013 • Database published on AnonNews.org • Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts • More than likely malware, but too late to know

24. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen • Hackers develop code that can pose as Buffer and cycle through all the tokens making posts to Facebook and Twitter via API. • 26-Oct-2013 • Database published on AnonNews.org • Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts • More than likely malware, but too late to know • Buffer discloses

26. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code repository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen • Hackers develop code that can pose as Buffer and cycle through all the tokens making posts to Facebook and Twitter via API. • 26-Oct-2013 • Database published on AnonNews.org • Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts • More than likely malware, but too late to know • Buffer discloses • MongoHQ discloses (not as much)

27. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords • Hackers target Github accounts of Buffer’s developers • Hackers gain access to Github’s code respository through shared passwords • From source code, hackers discover Buffer’s API keys for Twitter and Facebook • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data • Via MongoHQ’s tech support app, hackers find Buffer’s users’ OAuth tokens for Twitter, Facebook, probably develop ScrAPI to harvest them 1000 records per screen • Hackers develop code that can pose as Buffer and cycle through all the tokens making posts to Facebook and Twitter via API. • 26-Oct-2013 • Database published on AnonNews.org • Tens of thousands of Twitter/Facebook accounts spammed with weight-loss posts • More than likely malware, but too late to know • Buffer discloses • MongoHQ discloses (not as much) • Nov-2013: Adobe sends out password reset emails

28. Adobe Password Reset Email

29. Other facts and notes ● Hackers also looked for Buffer’s AWS credentials on Github

30. Other facts and notes ● Hackers also looked for AWS credentials on Github ● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer logs showed the Twitter account associated with the IP address.. that account known to be associated with Anonymous.

31. Other facts and notes ● Hackers also looked for AWS credentials on Github ● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer logs showed the Twitter account associated with the IP address.. that account known to be associated with Anonymous. ● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github

33. Other facts and notes ● Hackers also looked for AWS credentials on Github ● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer logs showed the Twitter account associated with the IP address.. that account known to be associated with Anonymous. ● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github ● Other companies hacked due to Mongo breach: Sunrise Calender

34. Other facts and notes ● Hackers also looked for AWS credentials on Github ● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter. ● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github ● Other companies hacked due to Mongo breach: Sunrise Calender ● Could have been much worse: Buffer had Stripe credentials in their code as well. Hacker could have charged charges to Buffer’s customers.

35. Other facts and notes ● Hackers also looked for AWS credentials on Github ● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter. ● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github ● Other companies hacked due to Mongo breach: Sunrise Calender ● Could have been much worse: Buffer had Stripe credentials in their code as well. Hacker could have charged charges to Buffer’s customers. ● Able to identify incursions on Github by IP address (didn’t belong to anybody on the team).

36. Other facts and notes ● Hackers also looked for AWS credentials on Github ● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter. ● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github ● Other companies hacked due to Mongo breach: Sunrise Calender ● Could have been much worse: Buffer had Stripe credentials in their code as well. Hacker could have charged charges to Buffer’s customers. ● Able to identify incursions on Github by IP address (didn’t belong to anybody on the team). ● Buffer moved to Google-based 2FA across other services. But many of those services (eg: Dropbox) offer no way of managing that (eg: no enforcement.. You have to trust employees).

37. Other facts and notes ● Hackers also looked for AWS credentials on Github ● IP address in common across access of GitHub, MongoHQ, and Buffer… the Buffer logs showed the Twitter account associated with the IP address.. that account known to be associated with Twitter. ● That twitter account also tweeted a question about thwarting security after Buffer moved to Google-based Two-Factor Authentication on Github ● Other companies hacked due to Mongo breach: Sunrise Calender ● Could have been much worse: Buffer had Stripe credentials in their code as well. Hacker could have charged charges to Buffer’s customers. ● Able to identify incursions on Github by IP address (didn’t belong to anybody on the team). ● Buffer moved to Google-based 2FA across other services. But many of those services (eg: Dropbox) offer no way of managing that (eg: no enforcement.. You have to trust employees). ● Another issue: How do you store credentials that admins must share? Put them on Dropbox where you lack enterprise controls?

42. Pinterest Auto-Post Preference

44. The “Fappening” (Not All Details Confirmed By Apple) • Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user • Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are easy to reverse engineer • FMI API required only user name and password for authentication (no other forms of authentication like OAuth tokens) • FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is otherwise known in security circles as a brute force attack. • Just needed a bit of code that loops and loops and loops • They called that bit of code iBrute and published it to Github • For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the passwords for 14 million accounts that were compromised when the social gaming service was compromised in 2009 • Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published. • Within hours, Apple installed rate limiting on the API. • The phishing attacks preying on the media-induced fear started almost immediately • Apple claimed: – There was no breach of its systems – The hackers gained access through phishing or answering password recovery questions (but that involves rate limiting, no?) on targeted accounts – Advised all users to activate its two factor authentication (already known not to protect all entry points into the Apple kingdom)

50. Source Code to iBrute on Github

51. The “Fappening” (Not All Details Confirmed By Apple) • Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user • Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are easy to reverse engineer • FMI API required only user name and password for authentication (no other forms of authentication like OAuth tokens) • FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is otherwise known in security circles as a brute force attack. • Just needed a bit of code that loops and loops and loops • They called that bit of code iBrute and published it to Github • For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the passwords for 30M accounts that were compromised when that social gaming service was compromised in 2009 • Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published. • Within hours, Apple installed rate limiting on the API. • The phishing attacks preying on the media-induced fear started almost immediately • Apple claimed: – There was no breach of its systems – The hackers gained access through phishing or answering password recovery questions (but that involves rate limiting, no?) on targeted accounts – Advised all users to activate its two factor authentication (already known not to protect all entry points into the Apple kingdom)

53. The “Fappening” (Not All Details Confirmed By Apple) • Apple’s “cloud” (everything from iTunes to iCloud) relies on one Apple ID and password per user • Allegedly involved the undocumented Find My iPhone API (FMI API) – undocumented APIs are easy to reverse engineer • FMI API required only user name and password for authentication (no other forms of authentication like OAuth tokens) • FMI API had no rate limiting on it, allowing for an infinite number of attempts or what is otherwise known in security circles as a brute force attack. • Just needed a bit of code that loops and loops and loops • They called that bit of code iBrute and published it to Github • For passwords, hackers allegedly used the infamous RockYou database; a big sample listing the passwords for 30M accounts that were compromised when the social gaming service was compromised in 2009 • Once the passwords were discovered, they used Elcomsoft Phone Password Breaker (EPPB) to handle the bulk downloads and from there the photos are being published. • Within hours, Apple installed rate limiting on the API. • The phishing attacks preying on the media-induced fear started almost immediately • Apple claimed: – There was no breach of its systems – The hackers gained access through phishing or answering password recovery questions (but that involves rate limiting, no?) on targeted accounts – Advised all users to activate its two factor authentication (already known not to protect all entry points into the Apple kingdom)

59. Common Breach Patterns • Hackers seek potential for scale (APIs are sitting ducks!) • Original transgression often targeted and undetected • Leverages trusted relationships (the downside of social nets) • Publication or black market sale of content • Publication of source code • Media coverage, useless expert advice • Official company disclosure (sometimes) • News goes viral on social media (usually negative) • Partners get sucked inn • Phishing attack (the second wave), invariably malware • Additional transgressions • Additional “publications”

67. Common Breach Patterns • Hackers seek potential for scale (APIs are sitting ducks!) • Original transgression often targeted and undetected • Leverages trusted relationships (the downside of social nets) • Publication or black market sale of content • Publication of source code • Media coverage, useless expert advice • Official company disclosure (sometimes) • News goes viral on social media (usually negative) • Partners get sucked in • Phishing attack (the second wave), invariably malware • Additional transgressions • Additional “publications”

68. Common Breach Patterns • Hackers seek potential for scale (APIs are sitting ducks!) • Original transgression often targeted and undetected • Leverages trusted relationships (the downside of social nets) • Publication or black market sale of content • Publication of source code • Media coverage, useless expert advice • Official company disclosure (sometimes) • News goes viral on social media (usually negative) • Partners get sucked in • Phishing attack (the second wave), invariably malware • Additional transgressions • Additional “publications”

71. Consequences of Breaches • Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report). • Possible account suspensions (eg: Twitter, etc.) • Loss of developer confidence • Micro financial impact (loss of revenues, customers, partners, costly reconciliation) • Legal financial impact (lawsuits, fines, etc.) • Meta financial Impact (on stock of company, upcoming public offering, or on entire stock market) • Lives are forever changed • Business shutdown

75. Post Intrusion Costs (Malware) “Breaches due to malware or spyware represented only 11% by number of breaches in 2013 and 2014, but they have been increasing, with the total number of breaches in this category growing by 20% between 2013 and 2014. Due to heavy forensics costs (money spent to find out exactly how the breach occurred) these breaches are on average 4.5 times more costly than the largest loss category, unintended disclosure.” (source: Beazley) * Malware is smallest group with biggest impact

79. 1 Tweet Sends Dow Down By 140

81. Consequences of Breaches • Of those individuals, 38 percent said they no longer did business with the organization because of the data breach. A larger number, 46 percent, said they ‘advised friends and family to be careful of sharing data with the organization (Economist Intelligence Report). • Possible account suspensions (eg: Twitter, etc.) • Loss of developer confidence • Micro financial impact (loss of revenues, customers, partners, costly reconciliation) • Legal financial impact (lawsuits, fines, etc.) • Meta financial Impact (on stock of company, upcoming public offering, or on entire stock market) • Lives are forever changed • Business scuttled

82. Reaches of Breaches • An Economist Intelligence Unit study conducted among consumers in 24 countries in March 2013 found that 18 percent of respondents had been a victim of a data breach (2014) • Adobe: 150 million userIDs, email addresses, pwd hashes, password hints(2013) • eBay: 145 million userIDs, email addresses, pwd hashes, birthdates, addresses, first, last, phone numbers, targeted eBay employees (2014) • RockYou: 30 million user IDs, Passwords (2009) • TJX: 90 million credit/debit cards • Target: 100 million credit/debit cards, PoS malware; “BlackPOS” a.k.a. Kaptoxa” (2013) • Home Depot: 56 million credit/debit cards, same (forked) malware as Target (2014)

83. Eventually… Someone will build and publish a database that maps user IDs to actual people and all of their data (creating a bigger problem for shared passwords)

84. Malware Case Study: Pony BotNet

85. Malware Case Study: Pony BotNet

86. Pony summary stats • A total of nearly 650,000 website credential stolen, with the top sites being: • ~90,000 credentials for Facebook accounts • ~25,000 credentials for Yahoo accounts • ~20,000 credentials for Google accounts • And many more with lower individual numbers, but still amounting to the remaining 515,000 accounts • Next in numbers were email accounts, with 17,000 compromised • And for the frosting on this credential cake are 7,000 stolen FTP credentials. Source: http://blog.spiderlabs.com/2013/06/look-what-i-found-its-a-pony-1.html

87. Fork of Pony • Approximately 2MM total • ~1,580,000 website login credentials stolen • ~320,000 email account credentials stolen • ~41,000 FTP account credentials stolen • ~3,000 Remote Desktop credentials stolen • ~3,000 Secure Shell account credentials stolen Source: http://blog.spiderlabs.com/2013/12/look-what-i-found-moar-pony.html

89. More recently “Cyber criminals have also developed botnets that force enslaved computers to create, or "mine", digital currencies, which the fraudsters then claim as their own.” http://www.reuters.com/article/2014/02/24/us-bitcoin-security- idUSBREA1N1JO20140224

90. Challenges in API Security (work that we, the API industry must do) • Massive proliferation of APIs where security was after-thought or non-thought • User ID / password absurdity – Shared passwords (really no solution) – Weak passwords – Discoverable Passwords – Horrendous Best Practices • Non-uniform implementations of – App Secrets – Callback URLs • Good security is expensive – Talent – Resources like HSM • Administrative tools for key/OAuth management limited – Analytics – Revocation/Reissue • Unknown possibilities for 2FA with APIs • Internet of Things • Standards still in the works • Disclosure / Collaboration

91. Challenges in API Security "There are far too many APIs being cranked out in such a short period of time... there is no way that they have all been properly secured and built. There will definitely be new attack vectors in an API-centric Internet, but we are still too early to know the pervasiveness of such attacks." - Evident.io founder and former Adobe Creative Cloud Architecture & Security Team Lead Tim Prendergast (http://twitter.com/auxome)

95. Discoverable Password Recovery Information

97. Horrendous Password Practices

98. Horrendous Password Practices

100. Twitter Requires App Secret

101. Facebook Doesn’t

102. Keys and Secrets Sold/Published https://gist.github.com/rhenium/3878505

104. Callback URL Not Always Required

106. Challenges in API Security (work that we, the API industry must do) • Massive proliferation of APIs where security was after-thought or non-thought • User ID / password absurdity – Shared passwords (really no solution) – Weak passwords – Discoverable Passwords – Horrendous Best Practices • Non-uniform implementations of – App Secrets – Callback URLs • Good security is expensive – Talent – Resources like HSM (Hardware Security Module) • Administrative tools for key/OAuth management limited – Analytics – Revocation/Reissue • Unknown possibilities for 2FA with APIs • Internet of Things • Standards still in the works • Disclosure / Collaboration

107. It’s Expensive to Secure Secrets

112. The IoT Exacerbation • 50 billion devices by 2020 • Proliferation of miniaturized but battle-untested platforms and operating systems • Security and usage patterns barely understood • Non-standard protocols involving less-evolved security • Endpoints sprinkled across devices, proxies, and the cloud • Involving massive amount of sensitive data

115. Challenges in API Security (work that we, the API industry must do) • Massive proliferation of APIs where security was after-thought or non-thought • User ID / password absurdity – Shared passwords (really no solution) – Weak passwords – Discoverable Passwords – Horrendous Best Practices • Non-uniform implementations of – App Secrets – Callback URLs • Good security is expensive – Talent – Resources like HSM (Hardware Security Module) • Administrative tools for key/OAuth management limited – Analytics – Revocation/Reissue • Unknown possibilities for 2FA with APIs • Internet of Things • Standards still in the works • Documentation / Disclosure / Collaboration

116. Lax Docs stated here https://developer.linkedin.com/documents/getting-oauth-token "You now have an access token and can make LinkedIn API calls. Please ensure to keep the user access tokens secure, as agreed upon in our APIs Terms of Use." But the terms of use: http://developer.linkedin.com/documents/linkedin-apis- terms-use Do not say or suggest that tokens must be stored or encrypted and how to do that.

117. Indecent Disclosure? Could even more be done?

118. Protect Your API & Adjacencies • API security not just about securing the API itself • Do not rely on user credentials (user ID / password) for authentication • When issuing tokens, refresh frequently • Require app key and secret (not a silver bullet, but a barrier) • Require call-back URLs to go with application keys and secrets • Secure as much as possible via HSM or reasonable alternatives • Encrypt data in transit and at rest • Require 2FA-based authentication for all developers • Develop and regression test against known security patterns (make Apple’s problem your problem) for all APIs (documented/undocumented) • Require/Reject User Settable Recovery Questions (where credentials are required) • Include Email address of record for recovery workflow? • Better more prescriptive documentation • Developer and end-user testing • Better Disclosure (for your users/customers, for the industry) • Monitor OAuth WG Proof of Possession (PoP) Standard

119. Protect Yourselves • Only use password protected WiFi • Use a VPN if possible • Use 2FA-supported Federated Login when Possible (reduce reliance on user ID/password combinations) • Examine email links before clicking through • Force token resets on a regular basis: – Example: go to Twitter settings revoke client app access (eg: Buffer), grant it access again (forces re-issue of token) • Check known sites for PWNage • Setup a Google Alert?

121. https://isleaked.com/action/check/

122. https://www3.trustwave.com/support/labs/check-compromised-email.asp

124. Pwned? http://www.haveibeenpwned.com/

125. API Security < Internet Security

Why API Security Is More Complicated Than You Think (and Why It’s Your #1 Priority)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Why API Security Is More Complicated Than You Think (and Why It’s Your #1 Priority)

Semelhante a Why API Security Is More Complicated Than You Think (and Why It’s Your #1 Priority) (20)

Mais de ProgrammableWeb

Mais de ProgrammableWeb (20)

Último

Último (20)

Why API Security Is More Complicated Than You Think (and Why It’s Your #1 Priority)