3 ms·
> In the system you describe if I have "FooBar1" and "BazQuz7" as both being acceptable, I can hop between them endlessly. Just about all backends test the pre
by jjnoakes 10y ago
> In the system you describe if I have "FooBar1" and "BazQuz7" as both being acceptable, I can hop between them endlessly.
Just about all backends test the previous N passwords, so no, you couldn't.
What the system I describe does not prevent is switching between "FooBarX" and "BazQuxY" where X and Y are changing numbers or characters every time you switch back to them. To prevent that you would need a custom backend, sure.
- koolba 10y ago> What the system I describe does not prevent is switching between "FooBarX" and "BazQuxY" where X and Y are changing numbers or characters every time you switch back to them. To prevent that you would need a custom backend, sure. Yes that's what I figured. Thanks! Thinking about the problem a bit, I came up with two possible solutions[1]. The first is to save N prior hashes and brute force the permutations. The main issue with this is that if the CPU cost of the hashing is non-trivial (which you hope it would be) then this will be prohibitively slow (though still feasible for a small number of permutations). The second is to store the plaintext of the old passwords encrypted using the current password. That way after verifying the current password you can decrypt the old ones and run the permutation checks against those as well. Updating the password would decrypt/encrypt the old passwords with the new password as the key[2]. [1]: If anybody else is following this thread and wants to build this, it's all yours! [2]: Or more likely the new password would be the seed used to derive a key.