https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28786
--- Comment #62 from Jonathan Druart <[email protected]> --- (In reply to Marcel de Rooy from comment #60) > (In reply to Jonathan Druart from comment #58) > > > > [2] The randomizer (which we should not use) depends on Math::Random::MT. > > > This module says: This algorithm has a very uniform distribution and is > > > good > > > for modelling purposes but do not use it for cryptography. > > > As long as we pass our own stronger secrets, no worries. See [1]. > > > > Sorry, you lost me here. Which randomizer module? > > See Auth::GoogleAuth: > use Math::Random::MT 'rand'; > sub generate_secret32 > [...] > return $self->secret32( join( '', @chars[ map { rand( scalar(@chars) ) } 1 > .. 16 ] ) ); > Please reread earlier comment. Not sure this is valid, but I will provide a patch anyway. > > > [3] Martin refers earlier to Authen::OATH. I follow him there, but no > > > blocker. > > > > Why? Did you see my answer on comment 23? > > On the other hand if we do not longer use the QR code generator from > > Auth::GoogleAuth there is no bad reason to not switch. But what are your > > good reasons to switch then? :) > > Martin mentions them already. I could only add: the fact that it potentially > exposes the secret in a GET parameter, could be reason enough? I've answered Martin's concerns, they were not valid IMO. I am not willing to rewrite the base of the feature here. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
