Re: Encryption Question

Richard Cornford wrote:

Isn't the problem with sending the password in plain text
over HTTP that someone may intercept the traffic and so
acquire the password for later use in gaining access that
they are not entitled to?

Precisely.

However, if a 'hash' of the password is sent in plain text
over HTTP, and all the server knows is the 'hash' of the
password, has the situation really changed?

No. It's the programmer's choice to let the client perform the
encryption in this scenario. Sure, one could send the password in
plaintext too, and let server encrypt it. This would be a more
traditional approach, and, as long as it uses HTTPS, an equally secure
scheme.

What is to stop someone who knows the 'hash' of the
password inserting it into the appropriate location in an
HTTP request (by any of numerous means, including the
executing of alien javascript on the logon page)? Wouldn't
the server recognise the intercepted 'hash' as easily as
it may have recognised the original password?

Yes.

The advantage of HTTPS is that someone intercepting the
HTTP traffic is not going to find it easy to make any
sense of what they observe.

Understatement - HTTPS is secure. But its importance should not be
exaggerated and well scoped. HTTPS does not take care of your safety;
it only secures the transmission itself (cfr. its "tunnel"-
terminology) which is only a small part of the total security picture
of an application.

Shimmyshack is very right to state that most of the troubles aren't
caused by not applying HTTPS, but by what happens after the sensitive
data has arrived at the server. After all, traffic can only be
intercepted at each hop from client to server, and, apart from the W/
LAN, these hops are ISP's routers that are mostly strictly secured.

Tons of sensitive data travel unencrypted this way: POP3 for email,
default UNIX (htaccess) authentication, passwords of internet
subscriptions, FTP, Telnet passwords, (XML) message sets, etc.

--
Bart

.