Application Programmer Interfaces - or APIs - are big things. This is how a service can allow other services to make use of its features and functions within a different website or program.

It's the magic behind things like IFTTT, otherwise known as "If This Then That" which allows users to effortlessly join disparate web services together. For example, whenever someone tags you in a Facebook photo automatically save it into Dropbox. IFTTT uses the APIs provided by these services to give users the power and flexibility to link actions and activities together.

It's how WordPress used to provide access to the Akismet anti-spam comment plugin.

It's how a plethora of Twitter apps could be created.

So, APIs are a big thing, and a good thing. Yet, I would argue too many web services are taking a gamble with your API keys by displaying them in plaintext, no matter if it is behind a login.

A very simple search "Where do I find my API key" reveals a load of web sites which provide API key facilities to users, including the very screens a user must go to in order to retrieve their forgotten API key.

This list includes WordPress, Campaign Monitor, MailChimp, GetResponse, Stripe, SendGrid and more.

Yet, if a rogue person or application finds your API keys they essentially have the capacity to use these services without restriction, under your account, and using your credit card.

This was the experience of DevFactor founder Andrew Hoffman who published his Amazon S3 keys along with his program code on GitHub.

He realised five minutes later and pulled the keys from public view, but that time was enough for a bot.

By the morning, Hoffman found he had 140 servers running on his AWS account performing Bitcoin mining, with an accompanying Amazon bill of $2,375. That's not the first, and by no means the last, such occurrence of the problem.

However, developers - and worse, service providers - continue making API keys available in plaintext.

Amazon publishes its best practice guidelines for managing keys but the most salient point is that Amazon simply does not display the secret access key to users. If the secret key is lost or forgotten, the user will need to create a new one.

Amazon's stance is the right one. Just as any secure operating system will store encrypted passwords and not provide any way to recover or decrypt the password, so too API keys ought to be treated with this respect and importance.

Just as we ought to be dismayed when a web service offers a 'recover password' facility that sends you a plaintext copy of your password - meaning it is not encrypted on their end - so too we ought to be dismayed when a web service offers a 'here is your API key' page.

Let us begin the push for service providers to put a higher emphasis on security and protecting customer's accounts, facilities and money from misuse.