Theoretically, this adds no security. In practice, however, it might
actually provide some security. If the attacker is just trolling for
arbitrary plaintext usernames/passwords in POST requests, encrypting
the password on the client side before sending it will defeat him. If
the attacker is specifically trying to capture the password for your
site, he will likely be able to capture the secret sent to the client
in order to encrypt the password.
As usual, there are probably better ways to invest your development
time to improve the security of the app.
-j
On 6/8/07, Scott C. Sanchez <scottsanchez@gmail.com> wrote:
I don't see how salting or hashing the password in the client prior to
submitting it will make it more secure. Anyone savvy enough to suck
your packets out of the proxy and make sense of them would just look
at the login page to find the key for the hash or salt.
One time passwords or a token-based solution like securid or mypw are
your best solution IMO.
-Scott
On 6/7/07, Vishal Garg <vishal@firstbase.co.uk> wrote:
> Hi,
>
> Thanks Rogan and everyone else for replying to my query and the
> responses were quite helpful. Ok, here I'll give one scenario to make
> it even more clear if someone could not understand my point correctly.
>
> Suppose this is an e-commerce application and a user is trying to
> access it through some shared computer such a Internet cafe or a
> hotel. Now my worry is that it is possible to capture user
> credentials by deploying a web proxy client, no matter the
> application is using GET or POST methods or is using an encrypted
> session. Yes, user would get an SSL error message but only in Firefox
> as I have not seen such message appearing in IE yet (I'm using IE6).
>
> From the responses till now, it appears to me that using salted
> hashes of passwords is the best way as it would not appear as plain
> text in web proxy. Also server generates a new hash using a new salt
> every time a user wants to authenticate to avoid replay attacks.
>
> Any other thoughts or suggestions would be much appreciated.
>
> Regards
> Vishal
>
>
> At 10:56 6/7/2007, Rogan Dawes wrote:
> >Vishal Garg wrote:
> >>Hi All,
> >>Can someone please tell what is the most secure way of sending
> >>login credentials to the server. The possible ways that I am familiar with
are:
> >>- get method
> >>- post method
> >
> >These are HTTP methods for sending parameters.
> >
> >>- hidden form fields
> >
> >This is a technique for defining parameters which will result in one
> >or other of the GET or POST methods (above) being executed.
> >
> >>By using an encrypted connection we cannot sniff the credentials,
> >>but still it is very easy to capture or manipulate these
> >>credentials using a web proxy from any of these methods. So I am
> >>looking to find a method to transport the credentials to the server
> >>so that the security of these credentials can't be compromised even
> >>by deploying a web proxy.
> >
> >The proxy can only be used by someone who accepts the certificate
> >validation error that appears in the browser. If you are worried
> >that your users might be trying to subvert your login process, the
> >odds are good that you are trying to make your login process too complex!
> >
> >In the normal event, your users will know their username and
> >password, so trying to prevent them from intercepting these same
> >values is completely pointless. If your concern is regarding
> >cleartext passwords being available on the server (e.g. you don't
> >ever want clear text passwords to leave the browser), you may want
> >to consider something like Secure Remote Password (SRP). However,
> >this requires a Java applet or ActiveX control for performing the
> >crypto and generating random numbers, and is unlikely to be popular.
> >
> >>Also once a session id is generated, what is the best way to
> >>maintain the security of a session id.
> >
> >See http://www.owasp.org/index.php/Session_Management
> >>Any help would be much appreciated.
> >>Regards
> >>Vishal
> >
> >Hope this helps.
> >
> >Rogan
>
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: Watchfire
>
> The Twelve Most Common Application-level Hack Attacks
> Hackers continue to add billions to the cost of doing business online
> despite security executives' efforts to prevent malicious attacks. This
> whitepaper identifies the most common methods of attacks that we have seen,
> and outlines a guideline for developing secure web applications.
> Download today!
>
> https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
> --------------------------------------------------------------------------
>
>
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------
