[katello-devel] katello-password potential changes

[Mike McCune]

my first reaction is that it feels like a bit of overkill to go to the 
next step and implement PBKDF2 beyond what we have now.  Perhaps a 
review from the security team would be in order?

Mike

On 06/11/2012 06:43 AM, Bryan Kearney wrote:
> Any comments on this, or do we let it go as is for now?
> -- bk
>
> On 06/07/2012 12:23 PM, Adrian Likins wrote:
>>
>> For the enc/obscured db password support for candlepin, I
>> implemented support for using passwords of the style
>> that katello-password generates (as katello is setup
>> to use that style for it's db passwords).
>>
>> In getting the java side to decrypt the passwords
>> that katello-password generates, I found some issues
>> that may need to be changed.
>>
>> I say "may" because I don't think they are wrong or
>> broken, but my research makes me think they are
>> least somewhat non standard. (And if history
>> repeats itself, crypto stuff that feels non standard
>> is usually wrong).
>>
>> So, what katello does is:
>>
>> 1) katello-generate-passphrase generates a passphrase
>> and stashes it in /etc/katello/secure/passphrase. It
>> makes the passphrase via
>> PASS=$(</dev/urandom tr -dc A-Za-z0-9 | head -c 64); echo "$PASS">
>> /etc/katello/secure/passphrase
>>
>> Things to note: that makes a 64 byte ascii string to use as the
>> "passphrase"
>>
>> (keep "passphrase" in mind, since this "passphrase" is used to enc the
>> db "password")
>>
>> 2) katello-password
>>
>> reads in that secure passphrase from above
>>
>> takes the passphrase, and get's the hex sha256 digest of it it's key
>> Note: that's a 64 byte string repr of a 32 byte digest of a 64 byte
>> ascii string
>>
>> takes the hex sha256 hex digest of passphrase+passphrase for it's
>> initialization vector
>> Note: that's a 64 byte string repr of a 32 byte digest of a 128 byte
>> ascii string
>>
>> take that 64 byte key, and that 64 byte iv, and passes to the a wrapper
>> around
>> openssl's AES, in particular 256 bit AES with the CBC block cipher mode
>>
>> First thing that get's weird: AES 256 bit only accepts 32 byte keys. The
>> wrapper is
>> silently truncating the key to 32 bytes. I had to do this in the java
>> code to get
>> decryption working.
>>
>> Second thing that get's weird: AES CBC's initialization vector only
>> supports a 16byte iv.
>> The wrapper is also silently truncating this to 16bytes. I also had to
>> do this explicitly in
>> the java code to get it to decrypt properly.
>>
>> Third thing of weird: Research seems to indicate that the iv should be
>> random, and not
>> something predictable. To quote from RFC 3602: "The IV MUST be chosen at
>> random, and MUST be
>> unpredictable." Now that said, we also have to have the IV to decrypt.
>> Which means including
>> it in the format of the stored password.
>>
>> The caveat being: we aren't using this crypto particular "correctly",
>> but then, we are just trying
>> to obscure the passwords a bit, and I'm not even sure with a plaintext
>> as small as a password
>> if the iv really matters much.
>>
>> Thing of weird IV: I think we should be using a different iv for each
>> password stored. Somewhat
>> moot considering we are only storing one db password, but I thought I'd
>> throw that out there.
>>
>> Suggestion: We should probably be using
>> http://en.wikipedia.org/wiki/PBKDF2 for
>> generating the key for AES from a passphrase. That means we need to
>> store the 8byte salt as well, but
>> that shouldn't be an issue. We would store the 8byte salt append/prepend
>> to the enc password, as well
>> as the 16byte random IV and the rest as the passphase. For java, this
>> means the PBKDF2HmacSHA1,
>> and I think the openssl Cipher.pkcs5_keyivgen will do the right thing
>> for this case, but I haven't tested
>> it yet.
>>
>> All of those may well be overkill for this use case. (and my thoughts
>> above could all be wrong, it's
>> crypto, which I'm usually wrong about...)
>>
>> Thoughts?
>>
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
Mike McCune
mmccune AT redhat.com
Red Hat Engineering       | Portland, OR
Systems Management        | 650.254.4248