Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ