Re: Suggestionn to HTML form element to compat phishing

Hi David,
Thanks for the comments. Here is a refinement for this suggestion. What if  
we let
the browser render this password box (the <input type="challenge"...>)  
significantly
different from the password field we are seeing right now. For a phisher to
re-create an identical login page same as the legitimate one, he/she has  
to use
this <input type="challenge"...> tag in the phishing page, which implies  
that he/she
can only harvest the salted version of the password.

I agree that this method is vulnerable to man-in-the-middle attack as you  
have described
in the reply. I've been thinking of a fix to this; if we make the random  
string
be the client IP and server IP (or some value derived from these two  
parameters), it can help
the client to determine if this random string is generated by the server  
it is talking to
(although tcp connection hijacking or ip spoofing is possible but let's  
not consider this
sophisticated techniques at this moment). Do you think such refinement  
will sound more
convincing and better? Thanks.

-Richard

On Thu, May 25, 2006 at 04:56:34AM +0200, Ka Cheung Sia wrote:
> As we know, phishing activities are very active in the Internet
> nowadays. Such vulnerability of phishing is partly because we allow a
> user's password to be sent in its plain format to the server side; it
> makes the phishers able to collect username and password by setting up a
> fradulent website that looks like a legitimate one and tempt the user to
> input their secret information.

The ability of criminals to create a site that appears to be a
different site has nothing to do with sending passwords in the clear.


> I am suggesting to add a new attribute within the HTML input element
> to improve what we are currently using (<input type="passowrd"/>)
> for password input. The new attribute will be something like (<input
> type="challenge" param="some random string" value="......>). The
> broswer will render this as a password box similar to what we get
> right now, but when sending out the data, it uses the value input by
> the user to encrypt the random string and send it back to the
> server.

So the client would hash the password and send the hashed password to
the pishers.

The pishers could then construct an HTTP request using the hashed
password they recieve and send it to the site the user thought they
were communicating with.

> As you can see, the idea here is to avoid sending the password in it's
> plain format to the server; instead, it is used to encrypt a string.
> Given a corresponding changes in the server side to generate random
> string with proper timeout period when user access their login page, and
> use the same encryption/decryption mechansim to check against the
> password, phishers can no longer harvest plain password but an encrypted
> form of it.

Dealing with timeouts is simple - the pisher just grabs the form from
the real site, passes the key to the user, gets the hashed version
back, then immediately logs into the real site and empties the account
(or whatever).

Alternatively they construct the form using current HTML so the user
enters their password and they get the clear password, then they can
hash it every time the target site issues a new key.

> This new HTML input attribute can guard against phishing
> activites nowadays to certain extent. How do everyone feel about this
> addition?

Ineffective.

Received on Wednesday, 31 May 2006 15:42:17 UTC