Just recently and by pure coincidence I came across a company's full production access credentials for all of the APIs they use — point of sale API, Oauth server, product API, the whole shebang — in plain text and hosted on GitHub.

I like to "Do The Right Thing" so I notified the company straight away and they have now since removed the information from GitHub. But it made me think again about basic best practices to do with code, version control systems and credential management, and how wide-spread the fundamental knowledge of protecting your systems are.

I think everyone should already be well aware of these concepts (the developer's version of "common sense"). However, if you do an advanced search on GitHub for some certain queries that match env or Java properties files, you can see that some developers have leaked usernames, passwords and other tasty info to the world wide web.

Considering my recent discovery, I thought I'd share what I regard as a developer's security "common sense" — or Basic Security Hygiene — as my first post on dev.to.

Don't commit files with access credentials or important API keys

If you have any files that store various access credentials or important API keys that your code base refers to, please, for the love of the Flying Spaghetti Monster and all that is holey, ensure that either they live outside the code repository, OR that they are ignored.

If you use git, something as simple as this might save you in your .gitignore file:

  .env*
  staging.properties
  production.properties

If you want to store your credentials in a file located outside of the code repo, on a Mac/Linux machine you might use something like ~/.<project name>.credentials.json or ~/.<project name>.properties.

Make your code repo private

If your code does not need to be open and available to read online, then please do not make it open and available to read online.

In the past I used BitBucket for free private repositories, however just recently GitHub have announced free private repositories for everyone. Go ahead and ensure that your repo is now private: but if you're changing it from public to private, make sure you reset all your username/passwords...

Deleting credential files in your code repo is not enough

If you have mistakenly committed your credentials in your repo, deleting the files or the lines that contained them and committing your changes is not enough — your editing history is still there! That's the whole point of git.

Use a tool like bfg-repo-cleaner to eradicate parts of your git history; however use with caution and care. The best way is to never include your credentials, API keys or any other sensitive information within your code in the first place.

Ensure database back-ups and sensitive files aren't accessible via the public web...

If you use things like WordPress, the core software and many plugins store credentials within the SQL database. If you create SQL backups using tools like iThemes Security, make sure that the generated SQL dumps are NOT within a publicly available folder (or within a descendant of one like www, htdocs or public_html) and/or that SQL files cannot be viewed on your server.

Using an .htaccess file (for Apache) or configuring locations for nginx to restrict public access viewing sensitive files and folders (especially .git folders if you happen to use git as a way to deploy your code) is extraordinarily important. Better yet, don't commit these files and folders to your code repo and avoid deploying them to a production server! Store them somewhere else.

... Better yet, use your pipeline/server infrastructure to store the credentials

DevOps are the go-to champs about this kind of stuff. It's also a great way to ensure separation of concerns by keeping your credentials out of your project code by feeding it via the pipeline or via environment variables to the virtual machine hosting the project.

If you are compiling code there might be a need to include API keys. To be honest, I'm not sure what the best practice is here. If using Google services, you can often limit an API key to specific domains which adds an extra level of authorisation so it can be OK to include those API keys in your code (and for front-end projects, required).

If you're using a service with an API key that doesn't have that feature, then it might be a security risk to include it in the code. Perhaps someone has a good suggestion and can comment.

Exercise caution when passing credentials around

Plain text emails and SMSs are not the future of day-to-day communications. I'm surprised they've even lasted this long.

If you are passing any of your credential data or files around, please ensure you're doing it via an encrypted method and/or private channel. Better yet, split the information up so that if someone is snooping in they only get some or half the data.

Please don't write down credentials on paper. The other day I just found my previous employer's PayPal username and password in my computer carry case and I only happened to see this as I was pulling some documents out put on someone else's desk. If you want to be a White Hat developer, best to destroy those security credentials if you have written them down on paper or in a digital doc, or remove your permissions to access them.

There are also credential services and tools that can help with secure and protected means of credential sharing:

• 1Password
• Dashlane

If you can, create per-user or per-project credentials

Doing so will allow better security control when people have left an organisation or a project has been removed.

Additionally, make the process of resetting the credentials very easy. If your user/project credentials are compromised, you'll want to be able to reset and generate a new username and password and update the project as quickly as possible.

Please create smarter and more secure credentials

The amount of times I've been given the user name <brand/agency name> with the password <brand/agency name><year>! is mind-numbing. Adding a year and an exclamation mark in theory does make the password more secure when evaluating it from a character range perspective, however it is a common format that can easily be guessed and brute-forced. Use a secure password generation tool.

Requisite XKCD reference: https://xkcd.com/936/

Security by obscurity helps, but only when there are additional levels of security to back it up (and that you're not using public services with search capabilities)

Any additional layers you can add to your security implementation further help to secure your code.

If your first and only level of security is obscurity (i.e. assuming your code or project won't be found by other people online) then it will only be a matter of time someone randomly stumbles across your code. Need I remind you what happened with the US Republican National Committee?

You might think you have no followers on GitHub and that you might not be important enough for anyone to see or find your code, however just remember that the code on GitHub is searchable and people can (and probably do) randomly search for things to see what saucerful of secrets they can find.

Google's web crawler is also another powerful tool at everyone's disposal, and you'll be surprised at what things you thought you had obfuscated surfaces in its results.

Ensure your external suppliers practice Basic Security Hygiene

Again, we all assume it is basic developer "common sense", however it's important that if you use any external suppliers — be they individual developers or agencies — that you have an expectation of high quality practices around security.

The original issue I found was related to an employee of an external supplier who had exposed all the access credentials for one of their clients. Oops.

Summary

1. Don't commit files with access credentials or important API keys
2. Don't make private code public: ensure your repo visibility settings are correct
3. When removing committed credentials from your repo, ensure to clean your history
4. Ensure database back-ups and sensitive files aren't accessible via the public web...
5. ... better yet, use your pipeline/server infrastructure to store the credentials
6. Exercise caution when passing credentials around
7. If you can, create per-user or per-project credentials
8. Please create smarter and more secure credentials
9. Don't rely solely on security by obscurity
10. Ensure your external suppliers practice Basic Security Hygiene

Not having an awareness, significant concern or care to implement any or all of the above points is what I'd deem a Developer Smell.

You might be compromising yours or your clients' systems, and in a world where privacy and security really matters and legal guidelines like the GDPR are present and conscious to punish those who don't play well or fair, to flagrantly avoid better security practices would make you a risky and stinky developer.

Always keep in mind that being hacked is a matter of WHEN not IF. Increasing your Basic Security Hygiene will help mitigate access to your credentials and systems, but there are always many more techniques and concerns well above and beyond the scope of this document that should require your attention. Start with the OWASP Top 10 to learn more.

It also always pays to be extraordinarily vigilant to remind everyone of Basic Security Hygiene, developers and non-developers alike. Anyone with access to security credentials must display the minimum knowledge and awareness on protecting those credentials and doing the utmost to keeping them away from the wrong audience.

I'm sure there's more I haven't fully covered in the basics, or maybe I've missed some other important details with the ones above. Please feel free to contribute your additional Basic Security Hygiene tips and concerns in the comments.