KPasswordDialog

[Ingo Klöcker]

On Friday 05 November 2004 13:42, George Staikos wrote:
> On Thursday 04 November 2004 19:06, Ingo Klöcker wrote:
> > The other threat is that passwords are written to the swap
> > partition. This can only be countered by using mlock'ed char*
> > memory. mlocking QString is impossible (unless you or Qt writes
> > QSecureString).
>
>   That's cool, we can provide a mechanism to prevent people from
> stealing passwords of out KPasswordDialog and instead force them to
> steal it from whatever uses KPasswordDialog. :)   Really.....  I know
> the argument you're making and I think it's rather pointless for
> this.  If someone needs a
> KSecuredButNotVeryUserFriendlyOri18nCompatiblePasswordDialog, they
> can use a separate one or a fork of the existing one made more
> secure.

My argument is rather pointless? Well, your last sentence is completely 
pointless. Why would a secure password dialog not be user friendly or 
i18n compatible? Is this a law of nature or are you just making this 
up? For one the user wouldn't even notice that the password dialog is 
more secure (why should he notice that internally mlocked memory is 
used?). Moreover there is apparently already a secure QString 
replacement that could potentially be used and last time I checked 
QString was i18n compatible.

Also your argument about forcing them to steal it from whatever uses 
KPasswordDialog is wrong. If passwords can be stolen from 
KPasswordDialog then that a single point to steal passwords from all 
applications. Moreover not all applications are as careless about 
passwords as KDE applications. Just take a look at the 
gpg/gpg-agent/pinentry-* combo of GnuPG 2. But if you think it's okay 
to make password handling in KDE even more insecure than it already is 
then that's fine with me because unfortunately I don't have the time to 
do anything against it. Still I'd prefer that somebody writes a 
KSecureString that can/should then be used by all KDE applications if 
they deal with passwords. Then all KDE apps would have secure password 
handling by default. Isn't that what KDE core is about? Making life 
easier for KDE developers? And you propose to leave such an important 
issue to each individual developer?

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041106/ff3b3c48/attachment.sig>