yet another approach, user registration involves time-based parameter, which is based on NIST shared clock set to a particular city or time-zone, minus a mystery variable, which then runs a 'tally' as the password as it has been transmuted via calculation: thus the password is rolling, every changing and cannot be computed as a string because it is never the same (if designed that way, to include rolling variables within a longer bit string)... in this way, example: [var1] = [Pacific Time Zone] minus (skew variable) - "3.14" [var2] = [DAYDATE spelled out] plus (translation) such that ==> [var1]*[var2] (list fool's magic xor goes here) ==> [var1a][var2c][var1b.var2d]...[var1w][var2i] whereby, the entire variable of [var1] and [var2] when combined is *changing* and transforming in real-time, via hidden, unknown clock and date correspondence, though could involve GPS, weather, other variability that is essentially entangled into a living password. in the realm of impossible to crack, in my estimation. any computation that cannot stop time itself in order to run the brute force would be losing time and then it would be purely chance, never less than the odds of trillion to one, or whatever it could be, every attempt no matter how many dictionaries parsed in parallel... this is not a password: [password]