|
Posted by =?Utf-8?B?RGFu?= on August 9, 2008, 9:06 am
If you were Registered and logged in, you could reply and use other advanced thread options
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
>
>
>
>
| 
XML site map