> How more secure would something like that generally be compared to static passwords?

It's not secure at all. If someone knows the rules of the system, the entropy on that is tiny, because it's basically a 2 letter password with only 6/3 options.

The only security would be from the obscurity of the attacker not knowing the password rules.

> because it's basically a 2 letter password with only 6/3 options.

That was obviously an oversimplified example to explain the rules.

In practice you could make it as obscure as you want, while keeping it easy for you to remember.

Like the sentences I just typed here. No limit on the number of characters. I could enter different long sentences each time, as long as the characters at specific positions match certain sets.

There is no way that "use a (proper) subset of the characters for bits of entropy" is going to beat "use all the characters for bits of entropy". Almost by definition, the second is going to have more entropy.

You're not getting anywhere, because people trying to guess your password don't have to guess your scheme. All you're doing is making it easier for them. There is no sense in which you are making it harder.

In the optimum case, you'd require them to get the right characters in the slots you're counting, but to not use the wrong characters in the slots you're not counting, thus demonstrating that they actually know the scheme in question and aren't just getting lucky. There would be exactly one character you'd accept in the slot you're counting, and there would be exactly one character they could use to indicate they understand your pattern in the slots you're not counting. This maximizes the chance they have proved to be in possession of your password, rather than just getting lucky because you didn't count their misses. This is, of course, simply using a password normally.

That's just the same thing as a password, though. Even a short password is still just ensuring that specific characters are in specific positions. The only situation where this would be useful is against people with physical or viewable access to the password being typed.

> In practice you could make it as obscure as you want,

If only that made it as secure as you want.

https://en.wikipedia.org/wiki/Security_through_obscurity

And they would almost certainly know the password rules, because anyone making an account would have to be told the rules in order to understand what was happening.

Unless the rules were unique and hidden for each user!

    User1: 1,3,7,10,12,15
    User2: 2,3,5,8,10,13

I think we’re on to something big.

It's complicated enough for people to remember 8 character long passwords, good luck with an additional level of complexity.

Each user could provide their own rules.

If I had a key logger on your system, I'd just try;

    9A4jc@23

Bam. Access granted.

If you had a keylogger, it wouldn't really matter how good your authentication scheme is…

Keyloggers aren’t very useful when authentication uses TOTPs from a hardware token.

TOTPs from a hardware tokens aren't very useful if system doesn't support TOTP as an auth backend.

But if each of those is a valid password, how does it defeat keyloggers or shoulder snoopers in any way? They just have to type in the same password.

Now, if the rules were totally secret, you could make it such that each time you used a password, it was no longer valid. That would defeat the keylogger, while still allowing you to remember your 3 special characters. But of course you can't ever assume your rules are secret (security by obscurity and all that).

> You could expand upon that system by having it only check the 2nd, 5th, 10th, Nth etc. characters

A bank I use does something like this. On account creation you give it a long key string and on subsequent log-in it asks for three different characters (e.g. the 4th, 3rd and 9th characters) from the string.