[katello-devel] katello-password potential changes

[Bryan Kearney]

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