On Thu, Aug 27, 2009 at 10:25:18AM +0200, Boris Petersen wrote:
> well encryption doesn't make sense at all.
> 1. encryption on disk means, that the service we are talking to
> understands that encryption as well. Otherwise there is no way!
Or it means that the centerim understands the symmetric cipher used
and prompts the user for manual entry of a key or insertion of a
keyfile to decrypt it before use. But I also agree that this is an
extraordinary amount of convolution to attempt to "secure" some
aspects of a client program relying on insecure authentication
mechanisms to begin with. There are third party "wallet" or
"keystore" applications which could be leveraged to broker password
access if present, but I can see that integrating support for those
is also probably development time better spent elsewhere.
> 2. If you don't trust your root, you shouldn't use any program which
> uses passwords, because root still can do a memory dump.
And, for that matter, can page arbitrary memory contents out to
swap, potentially exposing unencrypted passwords in disk images and
discards.
> conclusion: if you don't trust your root you shouldn't use _any_
> program which uses passwords
I agree that reusable passwords are seriously insecure to begin
with.
The risk profile mentioned by the original bug submitter is that
someone with an offline *copy* of your filesystem, for example on an
improperly discarded backup tape or hard disk, has all the
information they need to be able to log into your instant messaging
account (why instant messaging accounts should be trusted enough to
require this level of paranoia is anyone's guess).
That risk is, of course, better mitigated by encrypting the media
itself. However, one way to mitigate it in the centerim without
actually encrypting the passwords at rest it to have an option to
prompt the user for passwords whenever they connect or reconnect
(and try to zero them in memory as soon as they are used, which is
also not guaranteed to work in some cases). This, of course, trades
away significant convenience and also now opens the user's IM
accounts up to easier compromise via keylogger or shoukder
surfing... but still, compromise by external packet sniffer is
arguably lower-hanging fruit than this in most cases.
I wasn't suggesting that this concern should be "fixed" in centerim
at all, but rather that it probably merited being marked "wontfix"
because it is already known upstream, explained there in an FAQ.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
