My compromise has been to come up with a password permutation scheme-- I have a long, secure, high-entropy password which I can modify/salt in a way that's predictable (to me) across sites, such that each site's credentials are unique. Obviously this works across all devices, because the scheme is in my head, and it's simple enough to remember. I don't use any password manager, because like OP, that seems like too much of an eggs-and-baskets risk for my taste.

A catastrophic compromise would require an attacker to see actual credentials (not just the hashes) across many sites, and on top of that reverse engineer my specific permutation scheme. This seems much less likely to me than a very public, high-profile centralized cloud service forgetting to cross a T somewhere and getting hacked.

Just how long have you kept this up? When I gave it a go, the sites which didn't accept the base+permutation approach stacked up quickly. Some mandated a length which was too short, some mandated a length which was too long, some required certain special characters, others forbade the same, some required multiple separate passwords (i.e. security questions or pins), some just gave me a password and didn't let me change it (i.e. a serial number), some mandated that I change the password regularly, etc, etc. Trivial modifications were an unsustainable approach. I gave up within a month when I realized that my "exceptions" file was essentially identical to a password database but with poorer compartmentalization against the most likely threats.

Besides, a simple permutation scheme does not provide good protection if the base password is leaked which is what happens half the time anyway.

I've found a length of password that covers probably 85-90 percent of my accounts, and is a good tradeoff between security and portability. Most sites accept special characters, and the ones that don't also tend to be the same ones that have retarded length restrictions. Ironically these tend to be banks, who should know better!

The small subset of sites that don't fit into the scheme get one from a pool of fixed passwords that I just remember-- so if I forget, I just try from the pool until I get in. Or reset, but that happens rarely enough that it's no big deal.

IMO there should be federal regulation about password handling which would render that problem moot: There should be no length restriction, no special character restriction, no storage in plaintext, and mandatory salting. It's arguably a national security issue.

Actually, length restrictions of a few kiB are fine. Otherwise you open yourself to some forms of DoS attacks, I believe.

I'd guess that a lot of those sites permit password reset via email verification, in which case a lot of your eggs are in one basket anyway. In fact, considering that SMTP is even less robust versus encryption downgrade attacks than HTTP, while also providing a patient target for DNS poisoning, this oft-forgotten basket is pretty fragile.

It'd be nice if those sites recognized that that security arrangement is massively improved with OpenID, which can piggyback on the authenticator's two factor scheme, server hardening, and whatnot.

If your password for foo.com is foo-hunter2-XYZ and your password for bar.com is bar-hunter2-XYZ, you've got problems.

I don't actually see the scenario where this becomes a problem.

If foo.com is compromised and their passwords decrypted, I find it unlikely that the attackers are going figure out your password scheme, go over to bar.com, and start trying out usernames that are similar to yours with the password scheme they think you have, while they are in possession of all the other foo.com passwords and usernames, some of whom probably have the exact same username and password on bar.com.

I've been using basically hunter2_foo for all unimportant passwords for some time and never had a problem.

The only thing I can think of is that if one person was on a mission to destroy my life and they managed to compromise a couple passwords to figure out the scheme, but I don't see that happening in a way that would not allow them to vacuum up a good number of passwords anyway.

He never said it was. It could be something like <Base Password><Third letter of URL><Fifth letter of slogan> etc.

Just because it's predictable to him does not mean it's predictable to all. There are ways of keeping predictability while still obscuring it from everyone else.

Assuming you're more clever than whoever is cracking the password is a bad plan.

The goal of security is to make defeating the system too difficult to be worth it.

As such I'm not advocating security by obscurity, just security by "making the job of defeating all my accounts sufficiently involved to exclude me from a en-masse attack"; by far the biggest risk for cloud accounts.

But if your password for foo.com is 10,000 rounds of PBKDF2-SHA256(foo-hunter2-XYZ) and so on, this is extremely effective.

Yeah that would be nice. I actually think browsers should have this as a feature.

But the problem is that not all websites accept long passwords. My bank wouldn't take longer than 8 characters and doesn't even have a second factor auth.

Office 365 wouldn't accept more than 16 characters. I think it was Paypal who wouldn't take more than 10.

> My bank wouldn't take longer than 8 characters

Ugh, that is seriously infuriating. Of all the websites I have accounts with, that's the top of my "Shit I care about" list.

Be happy, one of my banks has a 6-digit numeric PIN (I shit you not) as their "security".

Banks also lock the accounts after 3 failed attempts though. The short passwords are to avoid having to deal with phone calls that go something like, "Hello, I forgot my password."

Overlooking 6 characters vs 20 over a shoulder is must easier though.

Only as long as you can keep your permutation process secret.

The problem with using any standard algorithm like that is that the algorithm becomes your password.

> The problem with using any standard algorithm like that is that the algorithm becomes your password.

That's not true at all. The press released linked in this thread, for example, is very open that they use 100,000 rounds of PBKDF2-SHA256 to encrypt their passwords. That's a very standard algorithm. The security it provides is not its obscurity, but rather that the only way to check against an output hash is the naive brute force method which takes a long time - impractically long for attackers to try to brute force.

Would access to two of your passwords make the rest an easy target? that would be my fear with a system like that.

Nobody's saying the scheme is perfect, the claim is that it compares well to a centralized password service.

In the situation where someone uses the GP's scheme, to get multiple cleartext passwords attackers have to bypass security on multiple networks to obtain the databases and spend significant computation time reversing hashed passwords. And they have to do it in a time window in which the user hasn't changed their base password or hash.

For a centralized password service, the attacker has to do... pretty the same things, but for only one service! I'd also imagine the situation with regards to cleartext recovery might even be a little easier given that the passwords contained in that database have to be encrypted in a recoverable manner rather than merely hashed. And time window isn't an issue; recovery is going to be simultaneous.

Oh, and in first situation, the attacker still has some limited added security through whatever obscurity their site-specific hashing function brings to the table. If it's something one can do in their head, it's probably not anything that can deflect a clever/determined attacker that got to this point, but it's something.

The flaw in your scheme lies in the fact that "it's simple enough to remember" ... this would imply that if one were to target you they could likely correlate your credentials across multiple leaked PW databases and guess at your scheme. That of coarse has plenty of assumptions...

Yes, a motivated attacker could figure it out. But before they could do so, they would need my password in plaintext for multiple unrelated accounts of mine, which is hard, requires the attacker to target me specifically, and by that point what is lastpass really going to do for me anyway?

By far the most likely way my gmail account would be hacked is that foo.com's database is leaked/cracked, and the hackers spam the credentials for foo.com at hundreds of other sites and see what sticks. My scheme defeats that. And it's one point of failure versus several.

Depends how simple. Obviously "add the domain name to the end of the password" is too simple. But there are other ideas that are equally easy to remember or regenerate.

On the other hand, in the even of your untimely demise, your friends/family may end up in a bit of a pickle without access to some of your accounts. Granted, this is of less concern if you're single and without kids.

I use the same scheme but on top of it I hash it so even if site saves my password in plain text, it doesn't reveal my scheme. I use a portion of hash for sites which have maxlength constraint otherwise full hash.

1Password can sync your passwords through WiFi [1] without going through some cloud service like Dropbox. This is the main reason I use 1Password, and it so far has met my needs. Caveat is apparently it can only sync with a single computer.

[1] https://support.1password.com/guides/mac/sync-wi-fi.html

+1 for 1Password.

I sync across multiple computers just fine using BTSync. I only use Wifi sync to sync from 1 computer to my multiple iOS devices.

Unfortunately I can't use 1Password at work because it doesn't have a browser client, and I can't install anything I like on my computer (corporate). Sticking to Dashlane for now.

Technically, a 1Password vault contains a "1Password.html" file that essentially loads up a browser interface to your vault. This may or may not meet your needs, depending mostly on whether or not you're cool with carrying around a thumb drive with your password vault on it.

1Password has integration with Firefox, Safari, Chrome, and presumably also IE.

They don't build their own browser into which their tool is built, no.

They don't provide you a browser-only solution like LastPass, no.

But they do fully integrate with most of the common browsers.

Doesn't help in this situation-- you need to be able to install the base executable for the browser extensions to function.

So get your IT guys to install it for you? Seems like a reasonable request...

Doesn't seem to be anyway to run it on Linux.

They very carefully maintain WINE support.

> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)

I don't know if it meets but your needs, but I love PasswordMaker (http://passwordmaker.org). There is no need for sync'ing, because the password is generated from a master password and configureable per-site data (by default, the web-site address; but you can add more data sources if you don't like that). It has an extension for Firefox that auto-completes passwords (configureably, remembering the master password per session so that you don't ever have to type it); there are widgets for Windows and Mac OS; there are Android and iOS apps; and, always, there is the fallback web page, which you can use anywhere that you have a web browser.

EDIT: Since I am trying to indulge in quite a bit of advocacy here, I want to make it clear that I am in no way affiliated with the project. I just stumbled on it a long time ago, and have been delighted with the way that it fills my needs.

I tried to use something similar a long time ago (SuperGenPass). The problem I had with it was that often times the password would not meet the password requirements of the site. Sometimes it's too long, sometimes there weren't enough numbers or symbols. I couldn't use it if I'd have to remember that it didn't work for particular sites (after all, the whole point is not having to remember information for each site). How does passwordmaker fair with that issue?

PasswordMaker allows you to tune the length and character set. You have to remember your site's password requirements, which is not so easy to do (usually they are only made available when you try, and fail, to change your password; in particular, only when you are logged in); but, in practice, I've found that using the default settings, and then using restricted settings (shorter length and A-Za-z0-9 character set) if that fails, works on every site I've ever used. This means that, if you are willing to endure the occasional inconvenience of having to re-enter a password, you don't have to remember anything per-site.

I hate such site with a passion. Especially ones that say a 10 character password is too long.

I hate any website that imposes a specific password format on me. I have a fondness for vaguely pronounceable passwords and I tend to use all-lower case for anything I have to enter on a mobile device.

So - reject my 16-character all-lower case password because there's no numbers or punctuation in it and you know better than me? Grrrrrrrrr.

That means one compromised password - your master password - compromises all your sites. That's the kind of risk I can't stomach.

LastPass is a huge target, yes - but (if we trust them) the data is only decrypted client side, so they have no access to it. Which means the only viable exploit is in the lastpass browser extension.

But isn't it encrypted with a secret that is also used to log into their web site, or to log into their API to recover the vault?

This is one of the things that scares me. If an attacker had access to dump their credential digests, could they also have modified the site to silently log credentials upon entry?

From their statements so far, it doesn't seem that happened, but it seems likely that it could.

It's a whole different cup of tea though, this compromise required the attacker(s) to go in, download data and get out. Your scenario would also require the attacker to have changed their site and go unnoticed for any significant amount of time.

If that was the case I'm sure Lastpass would've found out and reported as such.

The password is hashed on the client side before sending to the server.

> That means one compromised password - your master password - compromises all your sites.

I agree, but it's hard to see how it could be compromised, since it is never entered anywhere public-facing. You can, but need not, have the Firefox extension store it, but only in memory. It is also possible to use the PasswordMaker website (once loaded) without an Internet connection, in case you are worried about it leaking data.

Not that it's a cure-all, but one probably shouldn't be using a centralized password store without some sort of multifactor authentication enabled.

I wrote WebPass ( http://webpass.rkeene.org/ ) for a similar reason. It's extensible with domains having password requirements and does syncing (of parameters for passwords, never actual passwords -- since they are generated). The UI is bare, but it's open source (and aside from the syncing, done entirely client side).

The sync'ing is done with a FIFO, two clients connect with the same key and they each get what the other one POST'd, no data is logged on my side.

Not only do I see this issue groby_b rasies as a huge one but I'm not sure how this is supposed to work for sites that have various password requirements. Most of them don't display the requirements on the login page (or even on the signup page sometimes) so now I need to remember that on a per-site basis which is just as bad as having to remember different passwords IMHO.

> Not only do I see this issue groby_b rasies as a huge one

I think that it is not actually an issue, since the master password never goes out into the wild (see https://news.ycombinator.com/item?id=9722272).

> Most of them don't display the requirements on the login page (or even on the signup page sometimes) so now I need to remember that on a per-site basis which is just as bad as having to remember different passwords IMHO.

For me, at least, this issue is solveable in practice. See https://news.ycombinator.com/item?id=9722276 .

> Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.

Sure, it's a balance everyone has to find for themselves. As you note earlier, a cloud password manager is better than shared passwords.

I'm certainly happy to accept a bit more inconvenience than most. I only do banking on one device, and one device only. I set up per-device passwords for things like Gmail (and MFA for my primary password), I authorize mobile apps via API keys, and try to avoid services that require I use my password on multiple devices in the first place.

For the most part, devices I use frequently can access things I use frequently without passwords. For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.

> So the choice once more, for me, becomes cloud-based password manager or no password manager at all.

If those are you're options, you're probably right to go with the cloud option. For many people, even a physical notebook of single-service passwords would be an improvement.

> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)

Not really. It's largely the magic of cloud synching that I don't like. A lot of people run standalone password managers like Keepass or 1Password and store the database in some sort of file synchronization service like Dropbox. I guess that's workable, but it's still not something I'm going to be doing.

I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.

> For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.

You also don't need to use one solution for every use-case. I use an online password manager (LastPass + 2FA) for relatively high-use, low-value credentials (things like web forums and online shopping sites). For higher-value credentials (investment accounts, banking, email), I use an offline password manager on trusted machines and site-specific 2FA when available.

That's been a good trade off between convenience and security for me.

Seconding multiple solutions. I use LastPass to deal with the volume of credentials required, storing most but not all sites. I memorize the most important sites (bank, primary e-mail), never putting them in a password manager.

I think 2FA is really the key here. If I have a really physically isolated 2FA device I feel pretty safe actually.

A solution I have found that (I think) is relatively secure. Setup a keepass database that requires the use of an unlock password and key file. Sync the database to Google Drive but never sync the key file! Only store the keyfile on a locally ecrypted thumb drive or only stored locally on the devices (preferably encrypted) that you need to access keepass from.

In random time/day intervals reset your key file and keepass password.

The key to this method "working" which should be "secure" barring total ownage by a state actor or well funded individual is to never sync the key file and database to the same service. Additionally, sync up a "false flag" key file if you want some additional level of obscurity.

tl;dr:

1) Setup Keepass database to require password and key file to unlock.

2) Sync database to cloud service but never the key file.

3) In random time intervals (t=60+days) Randomly change both the password and generate a new key file for your database.

4) Keep your key file on an encrypted drive or on the device (preferably encrypted) that needs access to Keepass.

I'm concerned (but not qualified to judge) that changing your password and keyfile may not be as beneficial as it appears.

A password for an encryption key is very different to a password for a server. Once you change your password on a server, there's little harm in publishing it -- it can't be used any more. But the key is a file that may still exist (see also Wikileaks' key being published by David Leigh).

Consider: your database exists as a file. If someone is able to gain access to a copy, that copy remains valid as long as at least one password within it remains unchanged. So you need a strong key, because it's subject to offline bruteforcing. Now they get a second copy of your database, with a different password. If any of your passwords are ever published or cracked, your database is exposed. If you have to change your password regularly, it's going to be tempting to make it weaker, or to store it somewhere less securely. If you're using key files, they only need to get one of your files. It seems to me that the more key material you need to secure, the more difficult it's going to be?

Anyone who knows better want to chime in?

The key it seems to me is by using both a master password and a key file. If a site gets cracked and they find your site specific password that won't help them determine your keepass database master password &/or generated key file that you only store offline and never sync to the cloud.

In order to open the database you need both the correct master password and the correct keyfile. If the attacker doesn't have both, they should not be able to get into the database.

I'm also no qualified to judge, but I would say it's important that in addition to rotating the password and key file used to encrypt the password database, one also rotates the all the passwords in the database regularly. This way, if someone obtains a copy of your database, they have a limited time before all the passwords in the database become useless.

This is true, as well as enable 2-factor authentication for sites that support it.

I do something very similar to this, but I sync the key file to a second service (both services have 2FA logins). Keeping it off "the cloud" entirely is indeed safer from a security perspective, but think about how many copies of your key file you have, and what would have to happen to destroy all of them. If you've just got the key file locally on e.g. your laptop and maybe a smartphone, it doesn't take much more than a petty theft to cause you to lose access to every service in the database (in which situation of course you'd paradoxically want access to those services right away!).

> I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.

That makes sense. What would be really nice -- and what I had in mind -- would be some sort of device where the passwords were stored to which my other devices could easily connect to to access the passwords, sort of like a wireless dongle. (Though, really, even the wireless part is negotiable. I'd be happy to plug something in as well so long as it was easy to carry with me and supported the right connectors.)

Seems like a Kickstarter campaign waiting to happen.

And when the device dies?

If you're using a reasonably trustworthy password manager with a strong master password, your biggest risk is data loss, not mass password compromise. Syncing to multiple devices and cloud backups dramatically reduce that risk while only marginally increasing that of compromise.

I'd make it so that under some very specific and hard to attack circumstances, it would be possible to make a backup of the keyring stored on a device.

Possibly only directly to another device, or maybe dump an encrypted blob to file or straight to paper (bitcoin printable wallet style).

That creates the risk of someone duplicating your thing, but you could have a 'number of times/date of most recent backup' entry obvious in your token UI, and hope people notice abnormal ones.

Protecting from a Chris Tarnovsky[1] level attacker who is probing your silicon is probably beyond the scope of a cheap consumer unit.

The best way I (IANACryptographer) can immediately think of is that your hardware dongle generates an very large internal (never leaves the device) pgp keypair. It can be allowed to back up your internal password database only when encrypted by that key, so it is literally useless except on that single physical device. You could then enroll the pubkeys of your other devices as backups onto it, and the backups would then be multisigned where any one of the associated keys has the ability to decrypt.

The password blob can then be stored jsut about anywhere, but is only decryptable and useable when embedded into the hardware device.

[1] https://en.wikipedia.org/wiki/Christopher_Tarnovsky

http://finalkey.net/ looks like a step in teh right direction, although I'd prefer to see something a bit more compact, and ideally with an independent user interface.

Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.

There was a hardware bitcoin wallet not that long ago that was further down this road, I think maybe https://www.bitcointrezor.com/ ?

The biggest problems I can see for usability are:

* what can you do when you don't have it with you? - One answer would be some printable one-time tokens such as the fallback that google auth uses, that you can carry separately.

* Can it be backed up? In theory, the keys are in there permanently, and cannot be accessed by design. Having some Super Mega Master Password that allows a full copy to be made onto a second device that can be kept elsewhere might be sufficient.

* How to handle situations where you can't use USB/NFC for it to communicate. It would need a display to give you a code/your password to enter or something.

A smaller issue would be if you're planning on fully interoperating by generating and storing individual site/system credentials on there, it would have to handle the idiocies of various systems that impose password restrictions like special chars, numbers, maximum length, etc. If it's autotyping as a fake keyboard, would also need to deal with the 'retype your password' field somehow.

All in all, I think it's totally doable, but I'm not sure I'd trust a kickstarter-like project to get the details right, given the general (maybe just perceived) level competence of kickstarted projects. Crypto Is Hard. You can't really start having a 'stretch goal $10M - hire a real cryptographer to check we didn't twiddle our nonces' or something.

A decent and well-reviewed thing like this is probably somethign I'd buy though. I've just got a Yubikey to play around with, and need to start setting that up for SSH and other keys to my more important accounts.

> Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.

You might be interested in this:

https://hackaday.io/project/86-mooltipass

Interesting. I had seen that a while back I think, but totally forgot when writing my comment just now. It's not quite 100% what I was thinking, but it's closer than anything else.

U2f (Universal 2nd Factor) is a standard to have a 2nd factor authentication usb device that uses a different secret for each website/resource. The only problem is that a version 2.0 is being discussed and you can't be sure that today's hardware will work with it.

Somebody want to make an IronKey for cell phones?

Here's my solution:

1. Think of a 'stock phrase' that is simple for me to remember but likely to be unique, such as "angry dogs never jump for joy".

2. Write a simple program to generate 4 words at random, so it might generate "led show joke via" or "dean rock ranch ocean".

3. Generate a password by concatenating first letters of the stock phrase, the first two letters of the site name and the 4 random words. So the password for foo.com would be "adnjfjfo led show joke via" and the password for bar.com would be "adnjfjba dean rock ranch ocean".

4. As I generate the password I write down the site name and the 4 random words on a piece of paper which I keep in my wallet. So in our example I would write the following on the piece of paper: "foo.com=led show joke via; bar.com=dean rock ranch ocean"

The approach is very secure because the owner of foo.com would have no way to discover my password for bar.com. And a thief who steals my wallet will not be able to access either site.

Here's what I have found after several years of using this system:

A) After a few months of use I often find myself memorising the 4 random words for the more commonly used sites, so I often don't need to refer to the piece of paper in my wallet when logging in.

B) Many sites limit the length of the password - in these cases I generate 6 random characters in Step 3 instead of 4 random words.

C) For sites where security is not so important I skip the four random words. So my password for foo.com would be "adnjfjfo"; for bar.com it would be "adnjfjba". This avoids me having to use the paper in my wallet, but still ensures that the password for each site is distinct.

I do something similar in concept. I start off with a base password with numbers, letters, and symbols (to fit most website requirements). Then, I generate 2 random words based on the website name (based on the syllables). For instance, Gmail -> GM -> Green Mollusk or Amazon -> AM -> Aromatic Mitten. I find that it helps with remembering them naturally since the random words form a mnemonic on their own. The solution space is still large enough that knowing the rule should still be secure in real-world applications.

Creating passwords and such is never a problem for me. The problem is when I have to constantly reset passwords due to this, or that reason.

Interesting - but you know this isn't going to work for 99.9% of the population.

The difference is that a password manager must be able to decrypt a password in order for it to be used, while ideally websites only store one-way hashed passwords which if stolen aren't always useful at gaining access to other sites.

Ideally websites only store the hash, but you have no way of verifying which websites are actually doing that (and if they are doing it right).

1Password.

Sure, it's not free but well worth it to me in this case. I also chose not to sync using Dropbox but wifi sync and BTsync instead. So, no copy ends up in the cloud but cross-platform passwords with mostly minimal pain.

This reinforces the general problem that strings of characters are bad candidates for authentication. Users generally fit into two categories: those who will use the same password for everything, and those who won't. The latter half is the more technically savvy - which means they were likely to take the appropriate steps, read the appropriate news, and protect themselves against most classes of attacks. In short: the people who are likely the most vulnerable are also the ones that are least equipped to do anything about it.

It's a general problem with username/passwords as authentication and I think this is an interesting space for new start ups and service providers. Even with standards like FIDO, companies will want to be able to integrate it easily into their systems. The faster we can just kill passwords, the better.

>> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)

I'd like to chime in with another suggestion for a storage solution that I haven't seen mentioned yet: syncthing ( https://syncthing.net/ ) makes for a very good alternative to Dropbox, letting you synchronize your data across your devices but without relying on a third party service to do so. I use it to sync my KeepassX database across Linux, Windows and Android devices.

Disclaimer: I'm not affiliated in any way with syncthing, I'm just a happy user.

I use a password manager along with Syncthing[0] which seems to be the compromise you are looking for. This setup works well as long as your devices are decently often on a wifi that allows local device discovery (since syncthing needs either that or static IPs) and it also keeps your password vault offline (i.e no cloud involved).

0: https://syncthing.net/

no one that uses password manager would use the same password everywhere in the first place, were they not using password managers.

you simply can't even conjure that as an alternative because that's completely out of character for you hypothetical situation.

I dunno, I did. I used the same password everywhere, and then I got a password manager and started generating passwords. Granted, it may have been the case that it was my desire for stronger passwords that drove me to use a password manager, and not vice versa. I honestly don't remember.

> But this depends on the alternative. If, instead of using a password manager, uses only one (or even two or three) passwords across all the websites they frequent, then you are still, in effect, trusting numerous third parties to keep your password safe in the cloud--if any one of these sites is compromised, then your password for all (or half, or 1/3rd, etc.) is compromised along with it.

Correct me if I'm wrong, I read this as if you're equating hacking a frequented website (and password) as hijacking a % of someone's accounts, if they use the pw there.

Random websites don't know about the other accounts you own, let alone the user ID and password them (if that same pw cracked is workable on the other service).

LastPass, or any cloud password service, has to store the relation between the service, your username for it, along with the password. That is global ownage.

Find my password on some irrelevant site, you may not even be able to link it back to me. If so, that doesn't mean you know which services I'm signed up to, let alone my user ID or password.