{"API Encryption"}

An API For Encrypted Storage Of All Your Accounts, Data, Files, And Setting

I've been working on expand upon my API security research, but it can be difficult to find API focused security solutions. Exactly what is security when it comes to APIs can vary. Are you looking to secure your APIs? Are you looking to secure your data or content using an API? This is why I started a research projects so that I can turn on my keyword monitoring, and begin scouring the landscape in real-time--the more I conduct research in an area, the better I get at it.

The best part of my research is that sometimes when I write about things, companies just come to me. This happened the other week, with an encrypted database API provider called SecureDB. What this brand new API driven platform provides is default security for your accounts, data, files, and settings--exactly what we need in this cyber-insecure world we have created for ourselves.

I do not store any sensitive data, but if I did, I would not want to be in the business of storing it. Period! SecureDB gives you everything you need to manage your users account and identity, create the data stores you need, and store your appilcations files and settings in a secure environment. All identity data is encrypted by default, and you get to set the encryption levels for all your data stores, allowing you to make sure everything sensitive is not readable on the server, even if it is compromised.

SecureDB is just getting started, but they have a lot of things in the works, including on-premise, containerized implementations, version that run on Heroku, white label solutions, and much more. I will be working with them to help them craft a marketing and storyteling strategy around their encrypted database solution, and establishing a deeper partnership between them and API Evangelist.

I'm pretty stoked on my ability to attract these types of API service providers just by publishing my research regularly, and talking about the areas these companies are providing solutions in. I'm just telling the first story about SecureDB to let you know they are out there, and get them established in my monitoring system, and overall research--stay tuned for much more on SecureDB, and the security solutions they provide--I couldn't think of a better time for an API like this, we are so going to need it.

See The Full Blog Post


50 Building Blocks Of The API Economy

I spend a lot of time looking through the websites of API companies, trying to understand not just the way they do business, but their role in their overall industry, or possibly how they influence other industries.

I have been spending more time looking through the payment API space lately, and recently pulled together a list of key players in this space, as well as the common building blocks being used across the sector.

Much like other significant areas of APIs like cloud computing, messaging, geo, and social, I can’t help but consider the impact these payment APIs will have across all business sectors, and our government.

The 50 building blocks I identified as part of my payment API research will not just be the essential components of the payment API space, but will ultimately be some of the building blocks of the API economy itself--take a look.

Merchant Account - Creation, management and integration with merchant accounts that are required to process credit cards.
Bank Account - Integration with existing bank accounts, for linking with payment workflows.
Processor / Gateways - Access to multiple payent processors and gateways in multiple countries.
Currencies - Ability to conduct transactions in multiple currencies, handling all the conversions for developers.
Credit Card Transactions - The option to process major credit cards.
ACH Transactions - The option to process transactions over the ACH network.
Checks / Wire Transactions - The option to do bank to bank, wire and check transactions.
Cash Transactions - The option to accept cash payments at retail locations.
Virtual Transactions - The option to accept transactions for credits via virtual accounts.
Aggregate Transactions - Tools for performing multiple transactions at once.
Credit Card Reader - A physical credit card reading device.
Credit Card Scan / Picture - A mobile phone scan or picture of a credit card.
One Click / One Touch / Instant Buy - The ability to enable single action transaction
Recurring Payments - The ability to perform recurring or subscription based transactions.
Pre-Payments - The ability to setup payment(s) prior to designated payment date.
Metered Payments - Payments based upon some metered usage of a resource.
Estimates - Estimations of payments, with payment handling at designated time.
Invoices - Physical or online invoicing of customers as request for payment.
Mobile Billing - The ability to perform transaction against mobile users monthly phone bill.
Social Payments - An option for making and accepting payments via social platforms like Facebook and Twitter.
Email Payments - Tools for sending and receiving transactions via email.
SMS Payments - Tools for sending and receiving transactions via SMS.
Carts - Ready to go online shopping cart solutions to support payment services.
Checkout - Ready to go checkout pages, to support payment services.
Forms - Embeddable HTML and JavaScript forms to conduct transactions.
Buttons - Embeddable HTML and JavaScript buttons to initiate transactions.
Marketplace - The ability to facilitate marketplace style transactions between sellers and vendors.
Fraud Protection - Tools and services that assist developers in preventing payment fraud.
PCI Compliance - Tools and services that help developers achieve PCI compliance.
Encryption - Providing necessary encryption tools and services to protect communications.
Sandbox - A safe environment for developers to develop applications against, ensuring quality of service in production environments.
Webhooks - Registering of developer provider URLs for making HTTP calls when specific events occur.
Push Notifications - A push notification framework for developers to use when delivering push features in their applications.
Barcodes - The ability to generate barcodes that represent potential physical or virtual transactions.
Products - Separate systems for managing products that transactions will include.
Orders - Separate systems for managing orders in which transactions support.
Customers - Separate systems for managing customers who make transactions.
Coupons - Separate systems that issue coupons which can be applied against transactions and affect the balance.
Loyalty - Separate systems for managing customer loyalty programs.
Expenses - Separate systems or managing expenses that involve transactions.
Time Tracking - Separate systems for tracking time associated with transactions.
Cards - The ability to issue physical or virtual gift, membership and other types of cards.
JS Libraries - Supporting Javascript libraries that provide embeddable integration with payment services.
Mobile SDKs - Supporting mobile SDKs for iOS, Android, Windows and others, to facilitate mobile payments.
On-Premise - The ability to deploy payment services on-premise, keeping transaction local.
Cloud - The ability to deploy payment services in the clouds, with centralized security.
3rd Party Shopping Carts - Integration options for popular 3rd party shopping carts.
Platform as a Service (PaaS) Integration - Integration with popular PaaS platforms like Salesforce and Amazon.
Frameworks - Integration with popular programming frameworks like Backbone and Angular.
Automation - Integration with popular API automation platforms like Zapier and IFTTT.

One of these building blocks is the cloud, think about what you get when you take these API driven resources and combine them with the common building blocks of cloud computing? You start seeing being able to see the moving parts of the API economy.

I'm going to work to continue defining the other cornerstone areas I list in the history of APIs, like commerce, social, and mobile, and try to map out the building blocks like have with payments and cloud computing--see what I can learn.

See The Full Blog Post


Some Of The Common Building Blocks of Payment APIs

I'm taking a look at the world of payment APIs right now. As with all my other monitoring of the API space, I am only looking for the best approaches, by the most interesting companies in the space--I don't have time to track on everything, 

I am looking to take a snapshot of the payment API space, understand who the key players are, and how they are delivering valuable payment API resources that developers are actually using. Last week I puled together 38 payment APIs that I'm watching, and this week I am spending some time going through their sites, looking for what I'd consider to be some of the common building blocks of payment APIs. 

Currently I have 50 building blocks I found across these 38 payment providers:

Merchant Account - Creation, management and integration with merchant accounts that are required to process credit cards.

Bank Account - Integration with existing bank accounts, for inclusion in payment workflows.

Processor / Gateways - Access to multiple payment processors and gateways in multiple countries.

Currencies - Ability to conduct transactions in multiple currencies.

Credit Card Transactions - The option to process major credit cards.

ACH Transactions - The option to process transactions over the ACH network.

Checks / Wire Transactions - The option to do bank to bank, wire and check transactions.

Cash Transactions - The option to process major credit cards.

Virtual Transactions - The option to accept transactions for credits via virtual accounts.

Aggregate Transactions - Tools for performing multiple transactions at once.

Credit Card Reader - A physical credit card reading device.

Credit Card Scan / Picture - A mobile phone scan or picture of a credit card.

One Click / One Touch / Instant Buy - The ability to enable single action transactions.

Recurring Payments - The ability to perform recurring or subscription based transactions.

Prepayments - The ability to setup payment(s) prior to designated payment date.

Metered Payments - Payments based upon some metered usage of a resource.

Estimates - Estimations of payments, with payment handling at designated time.

Invoices - Physical or online invoicing of customers as request for payment.

Mobile Billing - The ability to perform transaction against mobile users monthly phone bill.

Social Payments - An option for making and accepting payments via social platforms like Facebook and Twitter.

Email Payments - Tools for sending and receiving transactions via email.

SMS Payments - Tools for sending and receiving transactions via SMS.

Carts - Ready to go online shopping cart solutions to support payment services.

Checkout - Ready to go checkout pages, to support payment services.

Forms - Embeddable HTML and JavaScript based forms to conduct transactions.

Buttons - Embeddable HTML and JavaScript buttons to initiate transactions.

Marketplace - The ability to facilitate marketplace style transactions between sellers and vendors.

Fraud Protection - Tools and services that assist developers in preventing payment fraud.

PCI Compliance - Tools and services that help developers achieve PCI compliance.

Encryption - Providing necessary encryption tools and services to protect communications.

Sandbox - A safe environment for developers to develop applications against, ensuring quality of service in production environments.

Webhooks - Registering of developer provider URLs for making HTTP calls when specific events occur.

Push Notifications - A push notification framework for developers to use when delivering push features in their applications.

Bar-codes - The ability to generate bar-codes that represent potential physical or virtual transactions.

Products - Separate systems for managing products that transactions will be part of.

Orders - Separate systems for managing orders in which transactions will be part of.

Customers - Separate systems for managing customers who perform transactions.

Coupons - Separate systems for coupons which can be applied against transactions

Loyalty - Separate systems for managing customer loyalty programs.

Expenses - Separate systems or managing expenses that involve transactions.

Time Tracking - Separate systems for tracking time associated with transactions.

Cards - The ability to issue physical or virtual gift, membership and other types of cards.

JS Libraries - Supporting JavaScript libraries that provide embeddable integration with payment services.

Mobile SDKs - Supporting mobile SDKs for iOS, Android, Windows and others, to facilitate mobile payments.

On-Premise - The ability to deploy payment services on-premise, keeping transactions secured locally.

Cloud - The ability to deploy payment services in the clouds, with centralized security.

3rd Party Shopping Carts - Integration options for popular 3rd party shopping carts.

Platform as a Service (PaaS) Integration - Integration with popular PaaS platforms like SalesForce and Google Apps.

Frameworks - Integration with popular programming frameworks like Backbone and Angular.

Automation - Integration with leading API automation platforms like Zapier and IFTTT.

As with all of my research, this is ongoing. My hopes is to better educate myself (and you too), about the payment API sector, which I consider a pretty critical aspect of the overall API economy.

If there are any building blocks that you think should be included in my research, let me know at @kinlane, and I'll see about including.

See The Full Blog Post


Supporting Encrypted Cloud Storage for Modern Web Languages

As more of our lives move online, into the clouds, encrypted backup and storage of not just our vital data, but our personal photos, files and streams is becoming critical--this responsibility to provide secure cloud storage and backup solutions is up to developers of the software, people use every day.

IDrive is working to provide these solutions for developers by delivering two interfaces for developers to integrate encrypted storage into their applications:

  • Command Line Utility - Develop highly scalable, reliable and fast applications to manage your storage on IDrive EVS. Best for desktop applications and also ideal for CRON jobs.
  • REST APIs - An interface designed to allow developers to easily build web and mobile applications to manage storage on IDrive EVS.

To help support our REST APIs users, IDrive has developed three new libraries supporting modern web languages:

Using these libraries, web and mobile applications developers can provide secure cloud storage and back-up, that works with the IDrive platform. In addition to providing users with secure storage within their own apps, developers can also leverage the entire IDrive ecosystem of consumer web and mobile tools already developed for users to manage their data.

There is no reason to leave users data unencrypted, while storing in the cloud, something security experts warn everyone about, but developers can only do with IDrive. Take advantage of the IDrive web client libraries, and use a secure REST API for storing and backing up files in your PHP, Python or Ruby web application.

See The Full Blog Post


Encrypted Cloud Storage with Python

IDrive now has a set of Python samples complete with full library you can use when developing your encrypted, versioned cloud storage for your web application.

Python is one of the fastest growing, interpreted, interactive, object-oriented, extensible programming language--embraced by giants like Google. IDrive has added samples to each of the 19 REST API Methods:

 

You can also visit the download center, where you will find links to Github repositories containing entire Python libraries for integrating your web application with all the functionality available via the IDrive EVS REST API.

As more of our daily lives move online, encrypted backup and storage will be critical to Python developers, building the next generation of secure web applications in the cloud. Take advantage of the IDrive EVS platform for securing your users data storage and backup.

See The Full Blog Post


Build Secure, Encrypted Cloud Storage Solutions with PHP

IDrive now has PHP samples complete with full library you can use when developing your encrypted, versioned cloud storage for your software solution.

PHP is widely is in many web applications today, so it’s a language we couldn’t ignore. We’ve added samples to each of the 19 REST API Methods:

 

 

You can also visit the download center, where you will find links to Github repositories containing entire PHP libraries for integrating your web application with all the functionality available via the IDrive EVS REST API.

IDrive is the only fully encrypted cloud backup and storage provider, which is a huge opportunity for PHP developers to deliver secure storage and backup for their users.

See The Full Blog Post


Amazon Web Services Offers Server Side Encryption for Amazon S3

Amazon Web Services now offers Server Side Encryption (SSE) for Amazon S3, enablingthe ability to encrypt data stored in Amazon S3, by adding an additional request header when writing the object to Amazon S3, with decryptionoccurringautomatically when data is retrieved.

Amazon S3 Server Side Encryption employs multi-factor encryption, with each object encrypted with a unique key, and as an additional safeguard, this key is itself encrypted with a regularly rotated master key. Amazon S3 Server Side Encryption uses one of the strongest block ciphers available -- 256-bit Advanced Encryption Standard (AES-256).

You can start using Amazon S3 Server Side Encryption in the AWS Management Console:
  1. Under the Amazon S3 tab, use the upload dialog to add files to be uploaded.
  2. In the Set Details section of the upload dialog, set the Use Server Side Encryption checkbox property.
  3. Start Upload. The files will be encrypted and stored in Amazon S3.
If you prefer to manage your own encryption keys, you can also make use of the client libraries for encryption provided by Amazon. To learn more, visit the Amazon S3 Encryption client page.

See The Full Blog Post


The Battle for Your API Proxy

Every Web API is designed to receive requests from and respond to the outside world.

Every day an API can receive thousands or potentially millions of calls. Before the API can process these requests and returns a response, it has to potentially tackle a huge laundry list of functionalities:
  • Identity / Authentication
  • Traffic Controls
  • Rate Limiting
  • Performance
  • Security
  • Scalability
  • Filtering
  • Encryption
  • Logging
Once all these items are handled, then the API can do what it is designed to do -- process its payload and return a response.

Many API owners tackle all these layers of the API themselves. But there are also several service providers out their looking to do this for them.

The first group of API service providers in this area use what I call the Proxy Flow Through, and this includes Mashery and Apigee. Mashery and Apigee deliver these service by routing all calls to an API through their proxy. Each call actually is made to Mashery and Apigee, then they route the request to the actual API for a response.

The second group of API service providers in this area, use what I call the Proxy Connector, and this includes 3Scale and Mashape. 3Scale and Mashape deliver these services by providing a connector your API can use to communicate with the proxy during each call.

All of these service providers end up delivering a similar set of services. This proxy, whether flow through or connector tackle the needs listed above, but then also provide much needed data on API operations. Apigee, Mashery, and 3Scale provide you with tools for monitoring and analyzing this operational data.

There is a lot at stake here. The next wave of Internet growth will pass through these proxies. More API owners are turning to these providers to deliver this layer, where all usage of the API from web apps, mobile apps, and other devices developed internally, by partners and the public will pass through these proxies.

These proxies are becoming brokers in the API economy. Each service provider is competing, for the ability to proxy your web API and be your broker in this new economy.

Mashery, Apigee, and 3Scale all provide some very robust services via their proxy, Apigee even offers their proxy technology as an on-premise appliance.

Newcomer Mashape does not provide a full suite of services via their proxy, like the others, but Mashape is taking a different approach, by introducing an add-on layer within their proxy. There are only two add-ons available (billing, rate limit) currently, but this concept opens up an entirely new type of marketplace for the entire API industry, not just a single API. Developers can now build specialized tools to sell, and push forward whats possible within a proxy. This proxy add-on layer also has potential for allowing a more a la carte set of services available to API owners.

The demand for API proxies is growing, and each service provider is pushing the definition of what it means to proxy your API. Mashery, Apigee, 3Scale, Mashape and others are working hard to define the space, push it forward, while also winning market-share.

One might compare this playing field to the competition between database service providers of the last two decades, where companies like Microsoft and Oracle battled it out for market share. There are many differences for sure, but with the amount of information and value running through APIs, the parallels to database choices are there -- except I still don't see the MySQL of API proxies as of yet.

See The Full Blog Post


Google APIs Now Support SSL

Google will start supporting the use of SSL in many of their APIs.

SSL will improve API security by encrypting all data communications between 3rd party applications and Google, protecting data from interception by a malicious third party.

Google Web Search, Google Maps, Gmail and Google docs all currently support SSL for API access.

They are working to introduce SSL support in other APis as well as update existing client libraries and code samples to support SSL.

Beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests.

SSL will further legitimize the integration of Google APIs into third party applications.

As applications become more distributed, SSL will become a must have layer to all APIs.

See The Full Blog Post


Encrypted Connections with Amazon Relational Database Service (RDS)

Amazon published today that Relational Database Service (RDS) now supports SSL encrypted connections. You can now generate an SSL certificate for each database instance.

Here are a few of the details about Relational Database Service (RDS) SSL connections:
  • SSL encrypts the data transferred "over the wire" between your DB Instance and your application. It does not protect data "at rest." If you want to do this, you'll need to encrypt and decrypt the data on your own.
  • SSL encryption and decryption is a compute-intensive task and as such it will increase the load on your DB Instance. You should monitor your database performance using the CloudWatch metrics in the AWS Management Console (pictured at right), and scale up to a more powerful instance type if necessary.
  • The SSL support is provided for encryption purposes and should not be relied upon to authenticate the DB Instance itself.
  • You can configure your database to accept only SSL connections by using the GRANT command with the REQUIRE SSL option. You can do this on a per-user basis so you could, for example, require SSL requests only from users connecting from a non-EC2 host.
I have just started using Amazon Relational Database Service (RDS) for a couple of blogs and a real-time data harvesting tools I am working on for fun, so probably won't get a chance to try out the SSL encrypted connections for a while. I'm sure it will help make people concerned about cloud security feel a little better.

See The Full Blog Post