[tbabb]

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.

[jjoonathan]

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.

[tbabb]

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.

[eru]

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

[cxseven]

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.

[snarfy]

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

[sean2]

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.

[mynameisvlad]

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.

[Dylan16807]

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

[tbabb]

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.

[archinal]

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

[dzhiurgis]

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.

[sosborn]

> 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.

[mynameisvlad]

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

[rickyc091]

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."

[dzhiurgis]

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

[click170]

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.

[archinal]

> 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.

[flycaliguy]

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

[wwweston]

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.

[felickz2]

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...

[tbabb]

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.

[ocdtrekkie]

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.

[pyre]

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.

[kr4]

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.