Get a whole heap of passwords from random.org. Create a text file with the sites you use with the usernames/passwords. PGP Encrypt the whole ensamble with a good strong password. The only one you really need to remember.
Forget your password? Once you reset via email, as soon as you get access to that encrypted file, get a new random password and reset it again. Save the new password in the encrypted file.
Password managers often connect to the internet to retrieve your passwords so if you lose your access, you're SOL. I also wouldn't trust a browser plugin as that may be prone to compromise. Backup to your laptop or something if you need to take it with you, but keep it encrypted until needed.
Forget the password to the encrypted text file? Throw your life away and start a new identity.
Edit:
Pointed out below (and I agree whole-heartedly) use /dev/u(a)random
Using PGP sounds fine, but why trust a random (ha) website more than you trust a browser plugin?
Even though you generated a bunch (up to 100), what is to stop random.org from storing every one of those? Much better to just use pwgen or similar.
1Password allows you to sync the encrypted file via dropbox, so if you lose your access you'll still have the encrypted file, you just won't have any updates. And if you can't trust the browser plugin, you can't trust your browser either and no password scheme will help.
| And if you can't trust the browser plugin, you
| can't trust your browser either
Depends. Adding plugins extends the attack surface area. Also, the plugin author(s) may not be as diligent at stamping out bugs/security holes as the browser developer(s).
(my tinfoil hat mode: I don't even have any important secrets but I believe in knowing how to protect them)
Use /dev/urandom, not a website. Make sure you have configured your text editor not to automatically save any backup files, cut buffers, or the like, and never write it to disk in unencrypted form. (I use vim >= 7.3 and its blowfish encryption; see encryptedvimrc and random_alnum in my scripts https://github.com/idupree/scripts ) If you copy/paste passwords, make sure you don't have a clipboard manager that persists recent history to disk. Also, encrypt your filesystem in case you screw up on any of the above. If you have swap, make sure that's encrypted with a generated-per-boot-from-urandom key generated after loading last boot's stored entropy from the disk. (A dedicated password-managing program might do some of these things for you. I haven't looked into their security methods yet; have you?)
If you can, use an email provider for your acct-registrations that uses decent security practices; use a high-entropy password for it; use different email addresses for every site, to make it harder for social engineering attacks (someone calling, say, Amazon or Apple's call center pretending to be you). The latter is probably hard unless you use your own domain or think '+' addresses are sufficient. If you use your own domain, you're vulnerable to your registrar or your account with them or your DNS being compromised, but you should have rigorous passwords and good registrars here because losing your domain name stinks. If malware gets on your computer, it can watch you and steal your passwords, so keep your system and browser up-to-date with security updates, disable riskier parts of your system that you can live without, prefer OSes/systems that are more on top of their security, and don't make enemies.
I don't understand why password managers like OnePass store passwords online; everything else they're doing as browser plugins is fighting the good fight. (True, there are risks of giving the browser the ability to access your passwords at all; but they're probably less than the risks of password reuse and low password entropy, and greater convenience means more people will use the system for more sites. Firefox Sync is the only consumer-friendly online storage that I've seen and consider well-engineered-&-documented enough to consider trusting. Tarsnap and Tahoe-LAFS also meet everything but the "consumer-friendly" bit there, and have a somewhat different focus. It may be worth considering encrypted online mirrors legitimate (online mirrors, not sole copies) for the sake of people who don't do backups, have multiple devices, and/or have their disk fail or device stolen.).
At least the last time I used it, Google Checkout had an opt-in feature that would create a unique unguessable email address the first time you purchased something from a shop, and this email address would be proxied to your GMail account.
I suggest /dev/random or /dev/urandom, as it doesn't involve a third-party. You can xor with data from random.org, if that makes you feel better.
> Forget the password to the encrypted text file? Throw your life away and start a new identity.
Just print out the plaintext of your password text file, and store the piece of paper somewhere reasonably secure. I say `reasonably' because if someone were to gain physical access to your computer, they could install a keyboard logger anyway.
I'm not too fond of printing out passwords. If I forget, and I'm extremely forgetful, that's just a disaster waiting to happen. I know my brain and I know it can't be trusted with physical security. Also, I'd rather use /dev/urandom instead of simply /dev/random.
Considering my aversion to using a stranger's computer to login to my accounts and the fact that I never use an open WiFi connection for anything without Tor, I'm much happier using a local copy of the encrypted file or at the very least a secure offline mirror(s) to download a copy of the encrypted file if I don't have it handy.
Not really the issue, but /dev/urandom is weaker than /dev/random, it is urandom which never blocks (try "hd /dev/random" and note that it blocks, then jiggle your mouse a bit and it will come back to life)
This is true on some systems, but not others. On FreeBSD (and OSX, as I remember) /dev/random and /dev/urandom act identically. The underlying CSPRNG, Yarrow, is designed to recover from a compromised state vector. Unfortunately, Yarrow relies on entropy estimates to time its re-seeding.
I've said it before: entropy estimates are a fiction. Ideally, /dev/random and /dev/urandom would both offer non-blocking access to an underlying Fortuna implementation (using a cryptographic hash function instead of a cipher, to avoid export/import restrictions).
I've been using a 50-ish line Python script for a bit more than a decade. It generates a password from /dev/urandom on Linux/OSX and the system crypto random source on Windows. It pipes the output to gpg, so the password doesn't go through the clipboard and isn't visible in ps output.
Forget your password? Once you reset via email, as soon as you get access to that encrypted file, get a new random password and reset it again. Save the new password in the encrypted file.
Password managers often connect to the internet to retrieve your passwords so if you lose your access, you're SOL. I also wouldn't trust a browser plugin as that may be prone to compromise. Backup to your laptop or something if you need to take it with you, but keep it encrypted until needed.
Forget the password to the encrypted text file? Throw your life away and start a new identity.
Edit: Pointed out below (and I agree whole-heartedly) use /dev/u(a)random
And idupree's points are spot on.