Re: Windows Explorer may expose FTP passwords in plaintext

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




.

Relevant Pages