lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <438C3335.8060503@gecadtech.com>
Date: Tue Nov 29 10:53:45 2005
From: stelian.ene at gecadtech.com (Stelian Ene)
Subject: 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ