RE: Growing Bad Practice with Login Forms

[Konstantin Ryabitsev <icon () phy duke edu>]

On Tue, 2004-07-27 at 10:34 -0400, Mark Curphey wrote:
> It is true if it is sent via HTTPS the SSL negotiation takes place before
> the HTTP happens so it wouldn't be sent. In that example as I mentioned it
> is (I checked the HTML post location and it was).
>
> But a phisher can easily create a site that looks exactly the same as the
> original and claims to be submitting the page to an SSL location using the
> icon. The form actually gets submitted to the phishers site and he captures
> the username and password (no SSL so no browser error, just the padlock icon
> in html). 

An SSL cert won't alter the situation, it will just make the phisher's
job slightly more difficult. The only way to guarantee that you're
submitting to the correct server is by verifying the URL in your browser
window, while hoping that the application you're using is not vulnerable
to any urlbar-altering exploits like the recent popular \0-bug.

In fact, teaching your users to always type in the site's address by
hand is the best practise. Unless they can't type and hit one of those
commonly-mistyped-spoof-sites.

Web security axiom is -- any way you do it, the chances of someone
getting screwed through no fault of your own is always above 0. :)

Cheers,
-- 
Konstantin Ryabitsev
Duke University Physics

Attachment: signature.asc
Description: This is a digitally signed message part