Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: Must we authenticate login forms (using SSL?)?

Subject: Re: Must we authenticate login forms (using SSL?)?
Date: Fri, 30 Sep 2005 16:25:24 +0100
On Fri, 2005-09-30 at 15:15 +0000, Eoin Keary wrote:
Hi is this over SSL, if not are you not subject to replay attacks?
Not necessarily over ssl, but if you are going down that route you could
re-use the same code over ssl too (a bit unnecessary but why not).
It should not be subject to replay attacks as long as you add a
per-session salt.

Antoine


On 30/09/05, Antoine Martin <antoine@nagafix.co.uk> wrote:
e.g. My bank logon script performs an MD5 hash of the username and
password before sending it to the bank. The MITM tricks me to visiting
their own site, and just "proxies" the comms to the real site. However,
they strip out the MD5 hashing script,and replace it with an "identity"
function (i.e. the output is the same as the input). When the MITM
receives the form submission, it is trivial for them to extract the
username and password from the form, replace it with the MD5 hash
expected, and pass it on to the real bank.
Absolutely, that's why in my post I had said:
"The session can still be hijacked but at least the original
password is safer (as stealing it requires more work than
just listening in)."

There is still some value in the approach suggested above, in the
context where the attacker can listen on the line but not proxy the real
server (and therefore not modify the page - not easily anyway).

Regards
Antoine



<Prev in Thread] Current Thread [Next in Thread>