How do webmasters store and keep track of their passwords [closed]

Question

I'm developing a site for the first time, and I'm trying to work out the best way to store and track all the accounts/passwords e.g. Server passwords, ftp passwords, API passwords (FB, Google, Twitter), Email account passwords. There's a lot! If any one of these is compromised it could do a lot of damage.

Also, I use public key authentication over SSH for connecting to my server using putty, but sadly, i actually fail to understand how this is safer than using default root login with a good password. For the private key is stored on my local machine and a password is not (hopefully not written down in plain text elsewhere).

So what if my key was stolen? Would the thief be able to use that key to log in to the server and wreak havoc?

Answer 1

There are programs called password managers that allow you to maintain lists of account credentials. One such program is KeePass Password Safe. I use it on Windows, but I think it can run on platforms where Mono is available.

There are risks, of course, with using any password manager. They do, however, make it easy for you to keep all of the credentials together and organized.

Answer 2

I personally use Password Safe and Password Gorilla for password management. They use the same encryption format (one client is for Windows, the other is cross-platform) and allow you to manage passwords in hierarchical groups, including associated email and web addresses (for auto-login) and customizable password generation.

This way, I only need to memorize a few long but easy to remember passwords, and I can still use strong and unique passwords for every single account. Additionally, by storing the encrypted password archives on Dropbox, I can have secure access to it from multiple computers.

Public key authentication has several advantages. If you don't require an additional password, it's very convenient while being pretty much impossible to crack. If you're security-focused, then you can still encrypt the key file with a passphrase, so even if your computer is hacked, the key file will not be immediately accessible. Though it's generally much easier to guess a password than to gain access to a physically secure computer, so even without a passphrase on the private key, you're still better off in most cases.

Answer 3

First of all never login into any system with root. Always login with a lower credential. In fact I have no root password set on my server so you cannot login as root. High level work is done via sudo. If you have to log in as root, login with a lower credential and then when logged in, su to root or sudo bash.

As to passwords and storage the biggest issue isn't where you put them the biggest issue is your access. Mine are stored in an encrypted format on my iPhone and backed up encrypted and duplicated onto my ipad encrypted. I have access to this all the time because my iphone is with me all the time. So if I'm off at a friends place and get that magic call from a client, I'm prepared. The file is also protected via a 3 login failure wipe system, so if I loose my iPhone the "attacker" gets three attempts at a 20 digit password and then its wiped.

Oh, and my ssh keys are stored on my iPhone as well, in an encrypted form. And before you say it, the file is encrypted and not stored in one of those Apple you can't see it so it must be encrypted philosophy.

Answer 4

The security field has a saying, "any system can be compromised". In other words, any system you use could have flaws. I suppose the best solution would be to write it on paper, and lock it in a safe, within a safe, within a safe.

I personally use one of two approaches (depending on the project).

1. Store it in an email. May hosting providers will send you an email with information about servers. Due to the fact that if someone gets access to your email, they can reset the hosting account password, change the email associated with it (to prevent you from resetting it in the future), and reset the root password for the server. Because of that, if someone gains access to the server, your API keys are far from your largest concern. On the same level, Google Docs might be your best choice because emails can't be edited, and it offers revision history allowing you to see old passwords or API keys that were deleted from the document (possibly also a security concern).

2. Store it on your revision control's site. Source code control sited with private repositories are very secure (recommendation: BitBucket for free private GIT repos). They allow you to create WIKIs and manage permissions for viewing them. That way your code and passwords are all in one place. The downside is when you're working on a repository with users that shouldn't see these passwords; in which case, email is probably your best bet.

Edit: To clarify, the difference between email/google-docs and KeePass or similar is that one is confined to one computer, and the other may be accessed from any internet-connected location. Neither is better, but one is better for each situation. You could also search around for a service with 2-step authorization for added security for online files. It's becoming increasingly popular.

Answer 5

I create txt files and store passwords in them. Then I encrypt them with one master password using WinRar or 7z and delete the txt files. Also passwords keep changing. So for a new Godaddy account I'd write the password using a code within a new file name Godaddy...txt and then I'd encrypt it.

Using any third party utilites to archive the passwords could be risky as those could be hacked - who knows. I'd trust on Winrar/7z which is used by millions and their primary objective isn't to encrypt the content.

We can also safely use Windows encryption feature but it isn't simple enough also adds some complexities in backups. Also it could be lethal to leave your login unlocked ..

I also upload all those regularly in my email accounts if I ever need them .. while on travel etc.

I use ssh to login into putty with public/private key just to save time otherwise typing the password is safer than that.