Warning: iconv_mime_decode() [function.iconv-mime-decode]: Malformed string in /home/secureg/public_html/lib/standard.lib.php on line 2251
Windows Explorer may expose FTP passwords in plaintext
Windows Explorer may expose FTP passwords in plaintext

Windows Explorer may expose FTP passwords in plaintext
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 Microsoft Applications Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Windows Explorer may expose FTP passwords in plaintext Brian Knittel 07-18-2008
Posted by Brian Knittel on July 21, 2008, 8:07 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Thanks, Shenan for the links. I'd done some googling on this before I posted
the original question and didn't find these.

So, it's a known, long-standing issue. And it's mind boggling that the
response is "besides, no body can see it." (Except maybe someone who walks
up and looks over your shoulder at your monitor, but hey).

Its interesting to note that Internet Explorer does not display the
password. Only Windows Explorer.

Anway, thanks. I'll see if I can find someone up at Redmond who cares about
this sort of stuff.

> It is not like this discussion is new. ;-)
>
> Maybe where the password is displayed is (maybe) - but I am sure it has to
> do with 'how the browser has to pass the credentials...' - so it may be a
> direct result of the protocol rules of passing things in clear/plain text.
>
> Internet Explorer 5, Netscape 4.61 Reveal FTP User Names and Passwords
> http://www.astonisher.com/archives/bugnet/alerts/bugalert_81199.html
> (1999)
>
> Internet Explorer discloses FTP access credentials
>
http://www.heise-online.co.uk/security/Internet-Explorer-discloses-FTP-access-credentials--/news/94349
> (2007)
>
> Internet Explorer and Your Web Site's Privacy
>
http://blog.washingtonpost.com/securityfix/2007/08/ftp_files_expose_web_site_cred.html
> (2007)
>
>
> How to Enter FTP Site Password in Internet Explorer
> http://support.microsoft.com/kb/135975
> (OLD - since it mentioned Windows 95/98 - but last updated in 2007)
>
> "NOTE: The user name and password you enter in the Login As dialog box are
> passed through as plain text and may be displayed in the Internet Explorer
> title bar or status bar while you are connected to the site.
>
> Note that this is not a secure method of logging on, as the password is
> viewable in plain text. If you require additional security, use the FTP
> client (Ftp.exe) that is included in your version of Windows 95 or Windows
> 98."
>
> Does FireFox do it?
> Opera?
> Any other browsers?
>
> Or do some browsers not even do FTP because of the weak security and how
> they would have to pass the username/password?
>
> --
> Shenan Stanley
> MS-MVP



Posted by =?Utf-8?B?QW50ZWF1cw==?= on July 23, 2008, 4:56 am
If you were  Registered and logged in, you could reply and use other advanced thread options
True, and it's a point that I've often emphasised is that Windows tends to be
faddist about theoretical considerations like repeatedly changing passwords,
and passwords of huge and totally unmemorable complexity, yet leaves a
blooper or two like this which makes the rest truly pointless!

The other point is that to say 'the user' is the only one who sees the
password assumes 'userization' of the computer. This is not always feasible.
In fact, this kind of arrangement is generally only practical with an AD
domain and roaming profiles. In smaller offices the tendency is to work with
a single fixed account regardless of actual user, since any other arrangement
causes too many problems with loss of program-settings.

Though, Windows is not the only OS to suffer this. In Linux' bash shell, try
typing 'su' and having this fail to be recognised, perhaps because of
existing garbage on the commandline. Then type the root password. It gets
stored in the bash history instead of being treated as a password. Once in
there it's suprisingly difficult to remove, too, unless you know some obscure
function-key strokes. Unlike in Windows, closing the commandprompt does no
good either, as the history persists between sessions. This one must be
decades old, yet it's never been addressed. It's an oh-so-easy way for an
engineer to unintentionally give a user the root logon.

"Brian Knittel" wrote:

> Stefan got the point: a computer should never display a previously entered
> password in clear text, no matter what, and I have observed Windows doing
> just that.


Posted by S. Pidgorny on July 28, 2008, 6:18 am
If you were  Registered and logged in, you could reply and use other advanced thread options
And here's the difference: in Windows, I can have maximum-length, totally
random password that I don't know. That is, use smart card for
administrative functions. AD recovery password that is stored in the vault
is note really required all that often.

And I can set local administrator password to something random and don't
store it anywhere.

I have yet to see a UNIX system that allows smart card logon for equivalent
of root. Note that I'm not claiming that capability doesn't exist - only
outline the limit of my knowledge. I'd love to be educated if the
alternative exists.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *

> True, and it's a point that I've often emphasised is that Windows tends to
> be
> faddist about theoretical considerations like repeatedly changing
> passwords,
> and passwords of huge and totally unmemorable complexity, yet leaves a
> blooper or two like this which makes the rest truly pointless!
>
> The other point is that to say 'the user' is the only one who sees the
> password assumes 'userization' of the computer. This is not always
> feasible.
> In fact, this kind of arrangement is generally only practical with an AD
> domain and roaming profiles. In smaller offices the tendency is to work
> with
> a single fixed account regardless of actual user, since any other
> arrangement
> causes too many problems with loss of program-settings.
>
> Though, Windows is not the only OS to suffer this. In Linux' bash shell,
> try
> typing 'su' and having this fail to be recognised, perhaps because of
> existing garbage on the commandline. Then type the root password. It gets
> stored in the bash history instead of being treated as a password. Once in
> there it's suprisingly difficult to remove, too, unless you know some
> obscure
> function-key strokes. Unlike in Windows, closing the commandprompt does no
> good either, as the history persists between sessions. This one must be
> decades old, yet it's never been addressed. It's an oh-so-easy way for an
> engineer to unintentionally give a user the root logon.
>
> "Brian Knittel" wrote:
>
>> Stefan got the point: a computer should never display a previously
>> entered
>> password in clear text, no matter what, and I have observed Windows doing
>> just that.
>



Posted by Brian Knittel on August 1, 2008, 2:00 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
OK, to summarize this: the issue at hand is what happens when Windows
Explorer is given an FTP URL, prompts for a password, and unexpectedly
retains and displays it in plain text in the Address history dropdown. There
are four points to make:

1. The password prompt dialog does not display the password. It displays
bullets. This implies a contract with the user not to expose the password.

2. The password is stored and is recallable from the history even when the
user does NOT check the box "Save this password."

3. Internet Explorer does not display FTP passwords for which it has
prompted. Only Windows Explorer does this.

4. There is no other instance anywhere in Windows (or any other operating
system produced in the last 30 years), either in OS components or
application tools, where a password is stored in and is displayable in plain
text, even if the user wanted it to be. There are reasons for that, and
Windows Explorer alone disregards these reasons.

Any one of these points should be sufficient to make the case that this is
improper behavior and has to be fixed. The four taken together are beyond
compelling. Arguments that "FTP isn't secure anyway, so it's OK for Windows
to reveal the password," or "Only the logged in user can see the password
anyway" are completely beside the point. (And wouldn't have been so
disturbing but for the credentials of their sources).

So -- the people responsible for this at Microsoft have been asleep at the
switch, and nobody has called them to task? Surely this can't be beyond
Microsoft's ability to fix? And surely there's someone up there with enough
of a grasp of the importance of protecting passwords (and protecting user
confidence) to take it on?



Posted by Shenan Stanley on August 1, 2008, 3:26 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Brian Knittel wrote:
> OK, to summarize this: the issue at hand is what happens when
> Windows Explorer is given an FTP URL, prompts for a password, and
> unexpectedly retains and displays it in plain text in the Address
> history dropdown. There are four points to make:
>
> 1. The password prompt dialog does not display the password. It
> displays bullets. This implies a contract with the user not to
> expose the password.
> 2. The password is stored and is recallable from the history even
> when the user does NOT check the box "Save this password."
>
> 3. Internet Explorer does not display FTP passwords for which it has
> prompted. Only Windows Explorer does this.
>
> 4. There is no other instance anywhere in Windows (or any other
> operating system produced in the last 30 years), either in OS
> components or application tools, where a password is stored in and
> is displayable in plain text, even if the user wanted it to be.
> There are reasons for that, and Windows Explorer alone disregards
> these reasons.
> Any one of these points should be sufficient to make the case that
> this is improper behavior and has to be fixed. The four taken
> together are beyond compelling. Arguments that "FTP isn't secure
> anyway, so it's OK for Windows to reveal the password," or "Only
> the logged in user can see the password anyway" are completely
> beside the point. (And wouldn't have been so disturbing but for the
> credentials of their sources).
> So -- the people responsible for this at Microsoft have been asleep
> at the switch, and nobody has called them to task? Surely this
> can't be beyond Microsoft's ability to fix? And surely there's
> someone up there with enough of a grasp of the importance of
> protecting passwords (and protecting user confidence) to take it on?

In reference to your last paragraph...

Actually - I think it is more likely the, "many better file transfer methods
exist and better ways to use even this particular file transfer method exist
other than using a browser/windows explorer" that you want to dismiss as
"beside the point".

Anyway - this is a public newsgroup - for discussion purposes only. It will
be unlikely to prompt anyone to do anything. ;-)

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html



Similar ThreadsPosted
Should "windows explorer" be in firewall as a security alert May 27, 2005, 10:03 am
Using windows explorer 7 e-mails won't display graphics or web lin September 6, 2006, 4:29 pm
domain tree view in windows explorer December 4, 2006, 10:27 am
explorer opens on startup, C:\WINDOWS\SYSTEM32 June 5, 2007, 2:36 pm
Windows Internet Explorer 7 beta - Security Warnings June 2, 2006, 11:50 am
Can we "stored user names and passwords" in Windows XP Home Edition? December 16, 2005, 5:57 am
The Microsoft Internet Explorer Weblog The Microsoft Internet Explorer Weblog IEBlog June 4, 2007, 5:52 pm
explorer.exe..??? June 27, 2005, 6:58 pm
IE Explorer November 7, 2005, 6:06 am
Internet Explorer 6 September 28, 2006, 6:09 pm

The site map in XML format XML site map

Contact Us | Privacy Policy