Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,802 views

Published on

Why API Security Is More Complicated Than You Think (and Why It’s Your #1 Priority)
David Berlind, Editor-in-Chief, ProgrammableWeb
In the last year, the users of various social media services have had their accounts compromised due to API security related issues. ProgrammableWeb’s investigations into these transgressions reveals a degree of hacker sophistication that could never have been anticipated. The attacks were layered and complicated and one can only guess at the final objectives (but we have our hunches). In this presentation, ProgrammableWeb editor-in-chief reveals the sophistication of these attacks with a step-by-step walkthrough of what the perpetrators did and then offers a a layered-security prescription for preventing your organization, APIs, and applications from being similarly compromised.

Published in: Technology

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

  1. 1. API Security It’s Complicated. @dberlind
  2. 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. 3. Anatomies of Recent API-related Attacks
  4. 4. Anatomy of Attack
  5. 5. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints
  6. 6. Anatomy of Attack • 03-Oct-2013: Adobe Database breached: 150M user IDs, password hashes, and hints • Oct-2013 • Hackers get busy “reverse engineering” passwords
  7. 7. Anatomy of Attack
  8. 8. 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
  9. 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 • Hackers gain access to Github’s code repository through shared passwords
  10. 10. 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
  11. 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 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
  12. 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 • Hackers target MongoHQ tech support personnel through shared passwords • Hackers gain access to MongoHQ tech support app which has access to Buffer’s data
  13. 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 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
  14. 14. 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.
  15. 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 • 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
  16. 16. 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
  17. 17. Example of Attack
  18. 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 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
  19. 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 • 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
  20. 20. 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)
  21. 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 • More than likely malware, but too late to know • Buffer discloses • MongoHQ discloses (not as much) • Nov-2013: Adobe sends out password reset emails
  22. 22. Adobe Password Reset Email
  23. 23. Other facts and notes ● Hackers also looked for Buffer’s AWS credentials on Github
  24. 24. 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.
  25. 25. 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
  26. 26. 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
  27. 27. 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.
  28. 28. 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).
  29. 29. 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).
  30. 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 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?
  31. 31. Pinterest Auto-Post Preference
  32. 32. 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)
  33. 33. 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)
  34. 34. 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)
  35. 35. 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)
  36. 36. 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)
  37. 37. 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)
  38. 38. Source Code to iBrute on Github
  39. 39. 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)
  40. 40. 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)
  41. 41. 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)
  42. 42. 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)
  43. 43. 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)
  44. 44. 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”
  45. 45. 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”
  46. 46. 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”
  47. 47. 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”
  48. 48. 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”
  49. 49. 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”
  50. 50. 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”
  51. 51. 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”
  52. 52. 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”
  53. 53. 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”
  54. 54. 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”
  55. 55. 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”
  56. 56. 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
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. 1 Tweet Sends Dow Down By 140
  64. 64. 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
  65. 65. 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
  66. 66. 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)
  67. 67. 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)
  68. 68. Malware Case Study: Pony BotNet
  69. 69. Malware Case Study: Pony BotNet
  70. 70. 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
  71. 71. 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
  72. 72. 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
  73. 73. 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
  74. 74. 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)
  75. 75. 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
  76. 76. 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
  77. 77. 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
  78. 78. Discoverable Password Recovery Information
  79. 79. 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
  80. 80. Horrendous Password Practices
  81. 81. Horrendous Password Practices
  82. 82. 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
  83. 83. Twitter Requires App Secret
  84. 84. Facebook Doesn’t
  85. 85. Keys and Secrets Sold/Published https://gist.github.com/rhenium/3878505
  86. 86. 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
  87. 87. Callback URL Not Always Required
  88. 88. 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
  89. 89. 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
  90. 90. It’s Expensive to Secure Secrets
  91. 91. 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
  92. 92. 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
  93. 93. 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
  94. 94. 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
  95. 95. 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
  96. 96. 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
  97. 97. 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
  98. 98. 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.
  99. 99. Indecent Disclosure? Could even more be done?
  100. 100. 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
  101. 101. 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?
  102. 102. https://isleaked.com/action/check/
  103. 103. https://www3.trustwave.com/support/labs/check-compromised-email.asp
  104. 104. Pwned? http://www.haveibeenpwned.com/
  105. 105. API Security < Internet Security

×