Re: [Full-disclosure] Google Talk cleartext credentials in process memory

pagvac wrote:
> Jaroslaw,
>
> thanks for your post. You're right, the same issue occurs in *many*
> applications. However, any vendor that is serious about security should
> at least attempt to obfuscate the credentials in the process memory (IMHO).

It's not that the vendor refuses to take security seriously, it's just
that such measures are normally useless.
So let's assume the application obfuscates the credentials using a
secret combination of AES, 3DES, Blowfish and an 512 bit random salt,
and stores this string in memory. Of course, at some point it would need
to decrypt it, using a function stored in the (public) executable image.
The only thing an attacker needs to do is pass the encrypted string to
it's own copy of the function together with all salts it can read from
the memory.
This is why most developers refuse obfuscation from the start - it's
like trying to keep a secret in a glass house.
The only notable exception from this rule is when the password is not
needed in clear, for example, only the MD5 of the password might be
needed. Then, it makes sense to apply the MD5 from the start and store
the encrypted string. Of course the attacker can steal this string and
use it to login, but at least he will not have access to the clear text
password, which is usually more valuable since it can be used to guess
other passwords.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/