lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <be950f350701150117s479b45f6n84f902e7b686d718@mail.gmail.com>
Date: Mon, 15 Jan 2007 04:17:25 -0500
From: wac <waldoalvarez00@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Flog 1.1.2 Remote Admin Password Disclosure

On 1/8/07, Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
>
> On Sun, 07 Jan 2007 16:08:23 +0100, endrazine said:
>
> > > yes that's correct but don't forget that hashes can collide
> > >
> > > it could be the case that:
> > >
> > can ? could ? might ? Do you have any mathematical prouve or are you
> > just guessing ?
>
> It's a pretty easy proof actually.  If your password input routine allows
> more different passwords than there are possible hashes, you *will* have
> collisions.  For instance, if you use a 64-bit hash, and reasonable-length
> passwords, you can create more than 2**64 of them, and 2 *have* to
> collide.


right

> > xhash("$Up3$tr0n9 # P@...oRD!!") == xhash("1234") and you don't even
> > > need the original strong one ;)
> > what hashing algorithm is being use ? Is a collision realistic ? How
> > much time would it take to actually break a given hash ?
>
> If you're using anything resembling a sane hash (such as MD5 or similar),
> what happens is that you basically ignore the hash collisions - because
> rather than "1234", your colliding password/phrase is probably a 32-byte
> or so
> string, which is likely not even enterable at the keyboard (it ends up
> being
> A # ctl-b 9 e alt-control-meta-$ etcetc - of the 32, likely only 10 or so
> of the characters are from the 96-char printable ASCII set, and there's a
> good
> chance that at least several of the bytes are ones you can't enter from
> the
> keyboard at all....)


Well I think you should not ignore those collisions, in some cases binary
data could be entered as a password for example when sent over the network
so... do not count on having to type it on a keyboard machines can do that
for you ;).

BTW for that still do not beleive this bug is a BIG hole well... as an
example a friend of mine broke into a website about 2 days ago "reversing"
an MD5 hash. Using a similar bug in one of those php instant website
creation tools that disclosed the administrator password hash using some
sort of SQL injection. He was using a program similar to John the Ripper and
asked me for help since that was taking very long and he had no idea about
rainbow tables. I simply told him to use one of those online Rainbow tables
an the thing ended taking only a couple of minutes. And he was only learning
about SQL injection and was only one hash that popped when you typed in your
browser some sort of URL containing that SQL stuff. No imagine when you have
the whole database. No... is not BIG, is HUGE.

_______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ