[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <218AE73F98E99C4C98AF7D5166AA798E0906BEA8@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Thu, 21 Mar 2013 21:11:45 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Password Hashing done wrong on CISCO IOS
> -----Original Message-----
> From: Per Thorsheim [mailto:per@...rsheim.net]
> Sent: Thursday, March 21, 2013 11:14 AM
> To: discussions@...sword-hashing.net
> Subject: Re: [PHC] Password Hashing done wrong on CISCO IOS
>
> Well, at least I guess Jens should be able to share his side of this, but
> honestly I don't think that's the interesting part. This has to be a serious
> implementation error by somebody who doesn't know crypto well enough,
Implementation errors happen to *everyone*, even folks who know tons about crypto. In practice, it seems that some functions are more prone to subtle implementation errors than others.
Say the developer accidentally left in some test code that ignored the round count and salt parameter and substituted the constant values of [nil] and 1, I agree we probably wouldn't learn much new from that. On the other hand, if the error came from C code making assumptions about the signedness of 'char' or sign extension of a shift right operator (e.g., Java) this might be interesting to hear about.
> and (crypto) QA / testing before the affected versions of IOS got released
> must have been weak, if at all present over the usual "if it reboots fine all is
> good" testing.
The challenge with subtle password hash bugs is that QA can do a thorough job of black-box testing and still not catch 1 round instead of 1000. Customers in the field are even unlikely to notice or complain about it.
Bugs like this get caught only by either comprehensive test vectors and/or 3rd party white-box testing.
- Marsh
Powered by blists - more mailing lists