Windows Explorer may expose FTP passwords in plaintext

[Paul Adare - MVP]

On Fri, 1 Aug 2008 14:26:13 -0500, Shenan Stanley wrote:



If you're going to do this:


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

And do this:

> In reference to your last paragraph...

Doesn't it behoove you to follow your own advice?

If you're responding to a specific paragraph, especially the last one, do
you really need to quote the entire article?


--
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca
BPI: A 1960s term used to describe unmentionable parts of the anatomy, as
in
"you bet your bpi".

 

[S. Pidgorny]

G'day:

"Brian Knittel" <brian@quarterbyte.com> wrote in message
news:48934f4f$0$17160$742ec2ed@news.sonic.net...


> 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).

To me those are quite compelling points, and to the point. Casually
dismissing those is a good sign of the fact there's nothing to counter.

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

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

 

[~BD~]

Maybe you should put *your* house in order, too, Paul! )

This page on your web site is refering to last year:-
http://www.identit.ca/events.html

Dave

 

[Shenan Stanley]

<snipped>
Want to read more?
http://groups.google.com/group/micr...b0861171443/8d82fd27f703e5af#8d82fd27f703e5af



Paul Adare - MVP wrote:
> If you're going to do this:

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

Paul Adare - MVP wrote:
> And do this:

Shenan Stanley wrote:
> In reference to your last paragraph...

Paul Adare - MVP wrote:
> Doesn't it behoove you to follow your own advice?
>
> If you're responding to a specific paragraph, especially the last
> one, do you really need to quote the entire article?


If by article you mean the "last response in this entire conversation" -
then I can tell you why I left it whole.


Short answer:
You have to know the point-of-view of the person asking the questions being
referred to in order to understand the questions and answers I chose to
give. The background information needed to be left.


Longer answer:
The responder chose to put no reference to the entire conversation they were
responding to. This - to me - was a bad choice - but I respected it as they
made whole points, not really referencing much except to (and they stated
it) summarize the past conversation.

My response was directed at the last paragraph of questions by the poster
however, the questions (and answers) would have no real context if I had
left out the parts above it (the summarization(s) the poster had written.)
Leaving the posters points in gave the necessary context - as they posted
that as a whole and I fully intended to leave it as a whole.

Many times people do not do this - they choose to pull things out of the
body of the message they are responding to and while their response makes
sense in that microcosm of their own creation - it may not address the
actual points the original person intended to get across. I was addressing
the concerns they had presented as a whole but made sure I pointed out I was
answering the questions they had given clearly in reference to the concerns
they had presented earlier.

After all - If I had only quoted only the last paragraph:
"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?"

How do you know - out of just that - it is a discussion on (quoting the OP
earlier), "... 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 ..."? How would you know what I was referencing with the
part of my response, '... that you want to dismiss as "beside the
point"....'?

You could argue that if someone wanted to know more - they could find the
posting and read it in its entirety... However - given what I replied to and
quoted was small that would have been choosing to leave out things, perhaps
for my own purpose, thereby creating my own microcosm from which to
answer... Or - putting it bluntly - I believed it would have been lazy and
inconsiderate to the original posters intentions. Not to mention, not
everyone knows how to locate entire archives of postings - thus why I
sometimes also post the Google Groups link (such as now) to the archival of
the post in its entirety at the beginning of the response. -)

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

 

[Alun Jones]

"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:#PuEq8D9IHA.4004@TK2MSFTNGP03.phx.gbl...
> "Brian Knittel" <brian@quarterbyte.com> wrote in message
> news:48934f4f$0$17160$742ec2ed@news.sonic.net...
>> 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).
>
> To me those are quite compelling points, and to the point. Casually
> dismissing those is a good sign of the fact there's nothing to counter.

Whether you feel those are compelling points or not, it's worth noting that
the behaviour for FTP is different from any other protocol for which you can
make similar assertions.

Enter a password into Basic Authentication over HTTP - that's exactly
equivalent to an unprotected password over FTP. And yet the credentials are
not stored, they are not available through the history interface to the
user, and they are not displayed to the user.

It is only the FTP implementation - and only the implementation in Windows
Explorer - where this approach to password storage and display is made,
despite there being numerous other protocols that are at least as weak.

There are two debates here:
1. I disagree with your suggestion that it's fine to display passwords "to
the user", as if there is no concern about shoulder-surfing.
2. The operating system is being inconsistent, when you compare FTP against
similarly unsecure protocol implementations.

Brian's interested in addressing debate 2. Debate 1 is a different issue
altogether.

Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.

 

[Brian Knittel]

Alun got the point. Windows Explorer is breaking the contract Windows makes
with the user not to display OR store the password. The first contract is
implicit: the password is obscured when it's entered in the
username/password prompt, so it should remain obscured. The second contract
is explicit, because the "Save this password" box can be left unchecked, yet
the password is still retained.

That's what I meant when I said that arguments about FTP's security are
beside the point. Those arguments don't NEED to be countered in
this discussion of the user interface bugs, because, as Alun understood,
it's a different debate. I might be using an-encrypted-over-the-wire network
for all anyone knows. The user interface is still broken (that's fact, not
opinion), and it's broken in a really bad way (that's my opinion).

It seemed pretty simple to me when I started this thread:

* The "save password" box should be respected.

* Since I never put my password into the URL I typed, Windows Explorer
shouldn't be putting it into the URL it stores in the history. The
associated password, IF I request it to be stored, should be enrypted and
stored elsewhere. There is a credential management system in Windows for
this sort of thing. Windows Explorer should use it.

That's all I'm saying. Are these bugs really worth defending?

> Whether you feel those are compelling points or not, it's worth noting
> that the behaviour for FTP is different from any other protocol for which
> you can make similar assertions.
...
> It is only the FTP implementation - and only the implementation in Windows
> Explorer - where this approach to password storage and display is made,
> despite there being numerous other protocols that are at least as weak.
>
> There are two debates here:
> 1. I disagree with your suggestion that it's fine to display passwords "to
> the user", as if there is no concern about shoulder-surfing.
> 2. The operating system is being inconsistent, when you compare FTP
> against similarly unsecure protocol implementations.
>
> Brian's interested in addressing debate 2. Debate 1 is a different issue
> altogether.
>
> Alun.

 

[S. Pidgorny]

G'day:

"Brian Knittel" <brian@quarterbyte.com> wrote in message
news:4897589a$0$17210$742ec2ed@news.sonic.net...
> Alun got the point. Windows Explorer is breaking the contract Windows
> makes with the user not to display OR store the password.

There's no such contract. You cannot store ftp password using irreversible
encryption.

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

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

 

[Alun Jones]

"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:OlXtE059IHA.5928@TK2MSFTNGP05.phx.gbl...
> G'day:
>
> "Brian Knittel" <brian@quarterbyte.com> wrote in message
> news:4897589a$0$17210$742ec2ed@news.sonic.net...
>> Alun got the point. Windows Explorer is breaking the contract Windows
>> makes with the user not to display OR store the password.
>
> There's no such contract. You cannot store ftp password using irreversible
> encryption.

Brian's already stated that there is a box that he chooses not to check,
that says "Save this password".

Brian does not want the password to be stored - reversibly or otherwise.

Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.

 

[Brian Knittel]

>> Alun got the point. Windows Explorer is breaking the contract Windows
>> makes with the user not to display OR store the password.
>
> There's no such contract. You cannot store ftp password using irreversible
> encryption.

You're quite correct, irreversible encryption cannot be used, since the FTP
protocol requires transmission of the unencrypted password to the server.

But I don't believe that that has anything to do with the issue at hand.
Password storage and UI behavior are two completely independent things.

First, the UI behavior: the display contract is implied when the UI obscures
the password during entry, displaying bullets instead of letters. This sets
up an expectation that the UI won't later visibly display the password in
the clear. I'm arguing that this expectation is reasonable and significant
it has to be taken seriously and met. What do those dots in the password
dialog box mean, if not, "this password is going to be kept hidden?" The
dots in the password prompt lose their meaning if it turns out that
depending on the protocol and the program you use, Windows might show the
password again, or it might not. You get to guess when and how. If the UI
can't be trusted to behave consistently, should I also be worried that
Windows is going to display my online banking password when I'm least
expecting it? The passwords to the domain servers I manage? Displaying the
password after the UI has signalled that the password is going to be kept
secret is a betrayal of trust. I was completely taken aback when I saw it --
and I've seen more than my share of gory UI train wrecks.

(Again: I'm talking about how the UI interacts with me, not with how Windows
interacts with the remote server--keeping an FTP password secure in that
interaction is different realm of responsibility. And for this converssation
I'm assume that the user checked "Save this password." That Explorer retains
the password when the box isn't checked is also a separate issue).

Now, second, implementation. Yes, reversible encryption has to be used, just
as IE has to reversibly encrypt the passwords it memorizes for websites via
the autocomplete feature. I notice that there is no way to display any of
_those_ stored passwords in the clear, yet they're not encrypted when sent
over the wire either. Why should FTP be treated any differently, and only by
Windows Explorer? The FTP URL should be put into Explorer's history list,
yes, but the username and password that it prompts for should be reversibly
encrypted and stored as metadata associated with -- but not displayed
with -- the URL.

Given that (a) every other program maintains the veil around passwords and
(b) mechanisms for storing and recovering passwords separately from the URL
history exist and (c) Internet Explorer uses them and demonstrates that it's
not necessary for Windows Explorer to do this, and (d) Explorer's
functionality can be maintained without deviating from consistent UI
behavior, why should Windows Explorer be let off the hook?

Why defend the behavior? Does it serve a purpose, is there a reason that it
should be retained?

And if there is any ambivalence about whether the behavior is acceptable,
shouldn't the error be on the side of better security and more conservative
handling of credentials, rather than less?

Brian

 

[Dan]

Exactly, Brian we can always use more external security and internal safety
for computers and networks.

"Brian Knittel" wrote:

> >> Alun got the point. Windows Explorer is breaking the contract Windows
> >> makes with the user not to display OR store the password.
> >
> > There's no such contract. You cannot store ftp password using irreversible
> > encryption.
>
> You're quite correct, irreversible encryption cannot be used, since the FTP
> protocol requires transmission of the unencrypted password to the server.
>
> But I don't believe that that has anything to do with the issue at hand.
> Password storage and UI behavior are two completely independent things.
>
> First, the UI behavior: the display contract is implied when the UI obscures
> the password during entry, displaying bullets instead of letters. This sets
> up an expectation that the UI won't later visibly display the password in
> the clear. I'm arguing that this expectation is reasonable and significant
> it has to be taken seriously and met. What do those dots in the password
> dialog box mean, if not, "this password is going to be kept hidden?" The
> dots in the password prompt lose their meaning if it turns out that
> depending on the protocol and the program you use, Windows might show the
> password again, or it might not. You get to guess when and how. If the UI
> can't be trusted to behave consistently, should I also be worried that
> Windows is going to display my online banking password when I'm least
> expecting it? The passwords to the domain servers I manage? Displaying the
> password after the UI has signalled that the password is going to be kept
> secret is a betrayal of trust. I was completely taken aback when I saw it --
> and I've seen more than my share of gory UI train wrecks.
>
> (Again: I'm talking about how the UI interacts with me, not with how Windows
> interacts with the remote server--keeping an FTP password secure in that
> interaction is different realm of responsibility. And for this converssation
> I'm assume that the user checked "Save this password." That Explorer retains
> the password when the box isn't checked is also a separate issue).
>
> Now, second, implementation. Yes, reversible encryption has to be used, just
> as IE has to reversibly encrypt the passwords it memorizes for websites via
> the autocomplete feature. I notice that there is no way to display any of
> _those_ stored passwords in the clear, yet they're not encrypted when sent
> over the wire either. Why should FTP be treated any differently, and only by
> Windows Explorer? The FTP URL should be put into Explorer's history list,
> yes, but the username and password that it prompts for should be reversibly
> encrypted and stored as metadata associated with -- but not displayed
> with -- the URL.
>
> Given that (a) every other program maintains the veil around passwords and
> (b) mechanisms for storing and recovering passwords separately from the URL
> history exist and (c) Internet Explorer uses them and demonstrates that it's
> not necessary for Windows Explorer to do this, and (d) Explorer's
> functionality can be maintained without deviating from consistent UI
> behavior, why should Windows Explorer be let off the hook?
>
> Why defend the behavior? Does it serve a purpose, is there a reason that it
> should be retained?
>
> And if there is any ambivalence about whether the behavior is acceptable,
> shouldn't the error be on the side of better security and more conservative
> handling of credentials, rather than less?
>
> Brian
>
>
>
>