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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55EDC241.7040300@devever.net>
Date: Mon, 7 Sep 2015 17:58:41 +0100
From: Hugo Landau <hlandau@...ever.net>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Interest in specification of modular crypt format

On 07/09/15 15:49, Solar Designer wrote:
> Should there be a shortcut syntax where some parameter can be omitted
> and a default used? e.g. have p and t default to the smallest
> supported (which is generally what I would recommend for password
> hashing use anyway). If so, it'd be preferable to use another
> delimiter between the parameters. 
I suspect not. It just doesn't seem worth it. The savings are tiny. In
this day and age of multi-terabyte hard disks, nobody, but nobody, is
complaining that they can't upgrade from their "md5(password)" disaster
because they can't afford the disk space. (The only real issue that
comes to mind is that some systems may have a hardcoded limit, perhaps
255 bytes; but that's miles away, and any such limit needs to be
reasoned about in terms of worst cases, not best cases.)

> I'd expect many (possibly most) implementations not to insist on the
> decimal numbers having proper syntax (digits only) and being in range
> (except after decoding, where an overflow may have already occurred).
> It's just too tempting to simply use atoi() or a scripting language's
> equivalent, instead of proper use of strtoul() (with its somewhat weird
> semantics) or checking the string against a regexp first (including a
> length limit).
>
This is true. However, I would question the likelihood of an
implementation being presented with such crypt strings. If someone is in
a position to present arbitrary malicious crypt strings to an
implementation, you have bigger problems.

This seems like it is best rectified with a robust test suite which
offers both must-pass and must-fail test cases, with plenty of cases for
edge conditions on integer parsing.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ