« Back to Flocknote API Documentation home
Flocknote is very serious about member data security, especially with regard to sensitive information like member passwords. Major security breaches in recent years have reminded the online community how important it is to store user passwords in a secure manner.
While there are few things we can do to help people create more secure passwords (and create a unique password for each service they use), short of buying everyone on the planet a license for a password management platform like 1Password, we can do our best to make sure we protect their password from being discovered, and to encourage others to do the same.
How Flocknote stores passwords
Flocknote uses salting, hashing, and stretching, along with very secure one-way cryptography to convert a user's password string into a virtually uncrackable string of characters. This means that neither Flocknote, nor anyone who could potentially access any Flocknote user information (in the rare circumstance of a security breach), could ever retrieve a user's password (that is why Flocknote requires a password reset when a user forgets his password).
Any application whose primary user interaction is via a web interface should store passwords in such a way (irretrievably), otherwise hackers could easily access user's passwords in the case of a security breach and potentially ruin a user's entire array of online services, since most users use the same password across multiple services.
API applications and password storage
Flocknote's API, however, requires a member's username and password to be transmitted via encrypted SSL with every API request. This means that applications and services that access Flocknote's API must store member passwords in such a way as to preserve the passwords' security, but be able to retrieve the password string to authenticate an API request.
There are many mechanisms for storing user passwords in a retrievable and secure fashion, but these mechanisms are inherently less secure than one-way encryption. It is our goal to help you store member passwords in as secure a fashion as possible to prevent unauthorized access to user accounts.
Here we will discuss some common mechanisms on different platforms for the storage and retrieval of member password information:
iOS and Mac OS X – Keychains
When building an application for iOS or Mac OS X using Cocoa, you should use the built-in Keychain system for storing and retrieving user credentials. The Keychain system stores data securely, and if used correctly, ensures that only your application and the correct user can access the user's credentials.
View Apple's Keychain Services Programming Guide.
Android – SharedPreferences or AccountManager
Android is a bit more of a mixed bag; there's no built-in system for storage and retrieval of user credential information, though some suggest that storing data inside your application's directory should be secure. While this may be so, please read through Android's Permissions and Security Architecture pages to get a firm grasp over what kind of things you should worry about with regard to user data security and privacy.
Additionally, you may be interested in reading about Android's AccountManager class, or see this answer on Stack Overflow which offers a simple solution to storing encrypted information in your application's SharedPreferences store.
Windows – CryptProtectData & CryptUnprotectData
Windows doesn't have an application credential storage mechanism like iOS, Mac OS X or Android, but Microsoft recommends using something like CryptProtectData and CryptUnprotectData to encrypt and decrypt sensitive information (like user passwords) for secure storage.
Web Applications
If you're building a web application, you will need to implement your own retrievable storage solution for user credentials. It is recommended that you use an encryption key that is stored in a separate location from the actual encrypted account passwords. For example, if you store encrypted passwords in a database table, store the key you use for encrypting and decrypting the passwords on your server's filesystem, and make sure both the file that contains the key and the database are secure (proper permissions, strong passwords, and no outside access to either).
In Summary
As long as you follow industry standard security best practices, the risk is relatively low that anybody could gain access to user credentials—our goal as a developer community is to ensure that we do everything possible to protect our users' data, and to educate our users on the importance of taking care of their own security by:
- Never re-using passwords (make a unique password for every service you use).
- Knowing that no online account is inherently secure (thus the above point).
- Using passwords that are harder for computers to guess.
- Assuring users that we take security seriously.