|
Message-ID: <4E2F3152.8070901@bredband.net> Date: Tue, 26 Jul 2011 23:27:46 +0200 From: magnum <rawsmooth@...dband.net> To: john-dev@...ts.openwall.com Subject: Re: Character encoding 'how-to' and patch 0009 On 2011-07-26 23:13, Frank Dittrich wrote: > Converting ß to SS for SAP codvn B is definitely wrong, since this hash > algorithm threats all non-ascii characters like the character '^'. > If you would convert it to "SS", you'd definitely get the wrong hash. > I am not sure (and have no time right now to test LM (that is: find a > windows system, use a password containing letters ä, ö, ü, and ß, > extract the resulting hash, and find out which conversion needs to be > done when processing the password). > But I am quite sure that 'ß' will not be converted. May be, 'ä', 'ö', > 'ü' are converted to 'Ä','Ö', 'Ü', respectively. This is something both Jim and I have been expecting; The problem is that JtR has about 80 formats and no one (not even Solar) have the full understanding of all of them. I and Jim do not really have the slightest clue, we are just "enabling" things blindly. What you say above is very important and we could/should adapt to this behaviour for sapB. And we would like exactly this input for most all of the other formats: What happens if you have an "£" in an Oracle password? Or a "€"? And this ß symbol, I actually expect most upper-casing formats to not uppercase them at all but just leave them alone. Still, I think Jim did the right thing. Until we know better, we uppercase like Perl does. magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.