Version: 3.2.2 (using KDE KDE 3.2.2) Installed from: Debian testing/unstable Packages It seems that if you attempt to access a site through a connection (ssh/ftp/http) that requires authentication and you use a "Location" like: http://myusername@mysite.com/ It will prompt you for a password and if you check the 'Save Password' box. The next time you attempt to connect to mysite.com with the above Location string, the thumper (spinning K) will go into motion and then no additional action will occur. You will remain in the existing directory that you were browsing. If you type in: ftp://myusername:mypassword@mysite.com/ The same password you had told it to save earlier, it will log you in. This is slightly annoying, but the real problem comes when the system stores those Locations in the location history, so basically other people using the computer while the active account is still logged into KDE can see passwords. I'd expect that with or without KDEWallet, access to password-protected resources would trigger the system to use the saved password or if it is using the saved password to refresh and load the resource.
Hi Ryan Are you sure that the location is stored *with* the password in the history? Normally the password is immediately striped from the URL. Could you provide a screenshot? Thanks, Christian
Created attachment 6161 [details] Screenshot Showing Password Displayed
When you start typing in 'fish://' in the 'Location' area of Konq, it tries to autofill what you want and it gives you two listing for every site you've been to that you entered authentication through the Location field. I wouldn't enter authentication through the location field, but if I've chosen to save the password, most of the time it will time out on the connection with just http://username@site.com/ unless I put the password in the URL. I hope this helps.
Created attachment 6162 [details] FTP & FISH passwords are saved in location string I thought I'd try to see if it'd show both ftp and fish passwords... it does.
Hi Ryan, thanks a lot for the additional feedback. Yes, I can confirm this now. The location is saved in the history incl. the password. This part of the report sounds like a grave bug to me. Christian
CVS commit by waba: Don't save passwords in the history (BR82281) CCMAIL: 82281-done@bugs.kde.org M +2 -1 konq_historymgr.cc 1.51 --- kdebase/libkonq/konq_historymgr.cc #1.50:1.51 @@ -282,4 +282,5 @@ void KonqHistoryManager::addToHistory( b KURL url( _url ); + bool hasPass = url.hasPass(); url.setPass( QString::null ); // No password in the history, especially not in the completion! url.setHost( url.host().lower() ); // All host parts lower case @@ -287,5 +288,5 @@ void KonqHistoryManager::addToHistory( b QString u = url.prettyURL(); entry.url = url; - if ( u != typedURL ) + if ( (u != typedURL) && !hasPass ) entry.typedURL = typedURL;
Created attachment 8269 [details] ftp:// history url with password embedded in plain-text ftp:// passwords being stored in KATE and apps using KIO in general.
This problem is happening again in KDE 3.3.1 I just upgraded and it occurred, so I deleted my .kde directory and tried again and it still occurs. The last attachment is a screenshot of the "Selector" path history in KATE with a stored username/password.
This has been reported as debian bug #253700 at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253700
If there's a kate bug, you'll have to report it to kate. This report was only about konqueror.
no. this isn't just about konqueror. It specifically says "kio" and "kfmclient" client in the bug report information.
kfmclient *is* part of konqueror - "kfmclient openURL" opens konqueror. KIO is too generic - the bug isn't in kio. This report *was* about konqueror, and was correctly closed when the bug was fixed. If there's a kate bug, please file a bug for kate.
thanks for the clarification David. I've opened a bug for KATE. http://bugs.kde.org/show_bug.cgi?id=93783