Closed clsn closed 8 years ago
Firstly, thanks @clsn for implementing this very cool idea.
At first glance the code looks good, and the style is in keeping with the rest of the code in the module, so thanks very much for that.
Before I merge this pull request in, I do have one request to make - could you add a description of the configuration variable and what it does into the documentation in the POD section at the bottom of lib/crypt/HSXKPasswd.pm?
Thanks,
Bart.
OK, I changed the option like I said I was thinking might be better: now it's "substitution_mode" and can be "ALWAYS", "NEVER" (another way of overriding substitutions, in addition to setting the table empty) or "RANDOM". Who really needs to control the probability? Any more than we do for random case, etc.
Added words explaining such to the POD section. Hope it reads okay to you.
Glad you like the idea!
Thanks for the updated code - it looks good, and I'm happy to merge it into the 3.7 release.
BTW - If you can, could you change the target for this marge to "150813-v3.7-prep" too?
Finally - I've been thinking about the idea of having randomised substitutions, and it occurs to me that if you're going to randomly substitute or not, you should be able to specify multiple possible substitutions too, and have it randomly pick one of the possible n, or none. Imagine specifying that l
could be replaced with 1
, or |
(pipe). In that case you would randomly generate a number between 0 and the number of substitutions - between 0 and 2 in this case - if the number is < the number of substitutions, use the substiutiont at that index, otherwise don't substitute at all. So, in my example a random value of 0 would mean the l
s get replaced with a 1
, a random value of 1 would mean the l
s get replaced with a pipe, and a random value of 3 would mean no substitution.
To do that, the value inside a substitution would need to be allowed to be either a string, or an array of strings. Allowing strings makes the config easier if you have single substitutions, and, makes it backwards compatible.
BTW - I'm not asking you to write all that code - just wondering if you think it's a good idea?
Thanks,
Bart.
Interesting. Yes, it makes sense to have multiple possible substitutions. I'll have to think about the syntax, can we just do it with strings or arrays... It also affects the entropy calculations. Have to run just now, but will get back and either move this or re-open it to the new branch. I'm still fuzzy on how git/github does all this stuff.
Replaced with pull request 23 to desired branch - closing.
Added a new configuration option, "substitution_probability". Gives percent chance that each word will have any given substitution (from the character_substitutions) applied to it.
Also computes (maybe inaccurately?) the additional bits of entropy provided: for each word, for each substitution, it might be applied or not. This does not account for the possibility that a given word might not have the letter to be substituted, though.
Does it really make sense to have this as a "probability" instead of just 50-50 random? i.e. maybe something like substitution_application=>"RANDOM" (as opposed to "ALWAYS" let's say), instead of this?