This is an interesting idea, but my very naive question would be:
Even if the datastore contained only password hashes (which is good), wouldn't it be (potentially multiple) orders of magnitude easier to brute-force password attempts in the event of a large number of potential permutations to be eliminated right off the bat?
Even though bruteforcing the stripped passwords wouldn't provide a full set of information, it might be a good starting point and quickly reduce the search or guessing space.
Disclaimer: I have no idea if this is a practical concern, just one that comes to mind when thinking about your suggestion.
To some extent, you're right. Bruteforcing the password becomes a case of first bruteforcing the kernel by searching the much smaller password space of lowercase letters, then once that's matched using that kernel to generate candidates by altering case, adding digits, etc. Obviously a smart search will immediately try uppercasing the first letter, and adding a 1 to the end, and in a lot of cases that's going to be right. So yes, it does reduce the strength of your encryption against bruteforce password search, by several orders of magnitude.
This is where advances in hashing approaches might negate that problem for you, though - and you'd need a proper cryptographer to figure this out. If it was a plain MD5 or SHA of the normalized password, you're absolutely vulnerable to an attacker using a rainbow table of lowercase alphabet words figuring out the 'root' of the actual password; then they could use that to construct password candidates to hash and compare to the full password. But just adding a big block of salt to the normalized password though would take it out of the pure-lowercase searchspace and force you back to bruteforce searching of the (admittedly small) password space. However, multiround salted hashing strategies like bcrypt rule out rainbow tables and allow you to tune how expensive bruteforcing is, and even though the password space of the password kernel is limited, you may be able to turn bcrypt up high enough to make it unfeasible to bruteforce.... maybe?
I might suggest that the password pattern strings are encrypted using a key based on the user's password plus salt. This way, the password pattern list is only recoverable AFTER recovering the users password (via brute force). I think this solves the reduced search space problem of your scheme.
$a = passwO_rd1; $b = ($a striped down to lower case); $c = ($b's metaphone); $d = md5(md5($a.'salt1'.b).$c.'salt2'); $e = md5(md5($c.'salt3').$c.'salt4'); Store $d as encrypted password then store $e as a string to check against. have $e saved in a separate communal database so to brute force $e and then guess the missing characters and the right user it would be. ([missing characters]^[character set])^([password lengh] ^ [users])^2 or something along those lines
Even if the datastore contained only password hashes (which is good), wouldn't it be (potentially multiple) orders of magnitude easier to brute-force password attempts in the event of a large number of potential permutations to be eliminated right off the bat?
Even though bruteforcing the stripped passwords wouldn't provide a full set of information, it might be a good starting point and quickly reduce the search or guessing space.
Disclaimer: I have no idea if this is a practical concern, just one that comes to mind when thinking about your suggestion.