[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
