[Melbourne-pm] Obfuscating passwords in configurations

[Daniel Pittman]

Toby Corkindale <toby.corkindale at strategicdata.com.au> writes:

[...]

> I recommend that people use established crypto libraries when they need
> crypto. It's harder to get this stuff right than you might think.. and these
> other libraries have *already been written*, so you can be lazy AND secure
> at the same time! :D
>
> For eg:
> Crypt::OpenSSL::RSA
> Crypt::CBC

FWIW, if you are using those you are probably *still* working at way too low
a level in your design: those are solid cryptographic primitives, but there
are millions of ways to screw those up.

For example, RSA falls terribly if you don't have random padding or ignore
problems with it; DSA fails if you reuse a nonce; many encrypted cookie
schemes are vulnerable to oracle attacks that allow recovery of the key; a
bunch of chaining modes are vulnerable if you reuse output, others if you
reuse the IV.

Note: CBC is specifically vulnerable to an oracle attack if you HMAC then
encrypt, and have detectably different failure modes.  Which are vulnerable to
real remote timing analysis over the Internet.


You really want to be picking up an existing, well designed and well tested
cryptographic protocol, and using a standard implementation of it.  Use HMAC
rather than inventing your own or using a keyed hash; encrypt-then-MAC rather
than the reverse.

The best practice would be to use SSL/TLS, and GPG for encryption; if you
need a library then pick up Gutmann's cryptlib[1], GPGME, or Keyczar:

    http://search.cpan.org/~flora/Crypt-GpgME-0.09/
    http://search.cpan.org/~alvarol/PerlCryptLib-1.11/
    http://search.cpan.org/~oyama/Crypt-Keyczar-0.06/


That also saves you one other huge risk of cryptography: thinking that, by and
large, it actually matters worth a tinkers damn for your application.  For
most applications there are way more interesting risks that it provides
practically no protection against.

Just grab an existing, very high level solution, use that, and address your
time to solving real problems like security against other vectors.

        Daniel

Footnotes: 
[1]  ...which is commercial.

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons