oss-sec mailing list archives
Re: CVE request: crypt_blowfish 8-bit character mishandling
From: Ludwig Nussel <ludwig.nussel () suse de>
Date: Tue, 12 Jul 2011 16:58:10 +0200
Solar Designer wrote:
On Mon, Jul 11, 2011 at 04:39:08PM +0200, Ludwig Nussel wrote:Solar Designer wrote:[...] Also, it brings up the question: why merely use $2a$ running the new code rather than fully emulate the bug even for newly set passwords, which would make all passwords work, even on other networked machines? Sure, that would be even nastier for security, so maybe you managed to strike a balance well. But nevertheless the question is there. One of your options results in full backwards compatibility at a security cost (for the local system), but the other somehow chooses to strike a balance between compatibility and security without achieving either of these fully (for a network of systems). Maybe you can afford to drop BLOWFISH_2y to avoid those inconsistencies? I imagine that people won't know to enable this option unless/until they have already run into an issue anyway (that is, someone is already unable to log in). At this point, they could likely upgrade the rest of their networked systems as well... or downgrade this one. ;-(I'm not sure I understand what you are suggesting.I am not exactly suggesting anything specific as I don't know your priorities, but I point out the inconsistency. My preference would be that you don't implement that BLOWFISH_2y option - always have new hashes generated as 2y, even though this means that networked systems need to be upgraded to new package versions in sync.
The default would be to use 2y by default. The option would be there as last resort only.
Keep using the buggy algorithm for new passwords and keep storing them as 2aI'd be unhappy about that, but it's a valid option to provide if you want to minimize user annoyance, including for networked systems that are not upgraded in sync (but are manually configured for this...)
The fourth possibility would be to use the 2y algorithm and store as 2a. That would be the better option if non-ASCII passwords are unlikely. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Current thread:
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 06)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jul 07)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 07)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 08)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 07)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 07)
- <Possible follow-ups>
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jul 07)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 07)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jul 11)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 11)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jul 12)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jul 13)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 14)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jul 14)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 14)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 17)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 17)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Aug 03)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Solar Designer (Jul 07)
- Re: CVE request: crypt_blowfish 8-bit character mishandling Ludwig Nussel (Jul 07)