https-Question

[Wilhelm Kutting]

Hello, i got a little understanding Problem.
on some http-Sites i can log into my Account with Name/Passwort.
The Form-Login-Page ist only http with form action directing to a
"secure" https page.
So - in my understanding the username and password is send uncrypted
over the Net.
Only the later Communication is done secure.

Am i right that only a https login-Form-page would be safe?

[Nikita the Spider]

In article <e9**********@newsreader2.netcologne.de>,
Wilhelm Kutting <wk******@arcor.dewrote:

Hello, i got a little understanding Problem.
on some http-Sites i can log into my Account with Name/Passwort.
The Form-Login-Page ist only http with form action directing to a
"secure" https page.
So - in my understanding the username and password is send uncrypted
over the Net.
Only the later Communication is done secure.

Am i right that only a https login-Form-page would be safe?

Wilhelm,
Basically, yes.

HTTP = not secure, name and password sent without encryption

HTTPS = secure, name and password sent encrypted
Hope this helps

--
Philip
http://NikitaTheSpider.com/
Whole-site HTML validation, link checking and more

[Sherm Pendley]

Wilhelm Kutting <wk******@arcor.dewrites:

Hello, i got a little understanding Problem.
on some http-Sites i can log into my Account with Name/Passwort.
The Form-Login-Page ist only http with form action directing to a
"secure" https page.
So - in my understanding the username and password is send uncrypted
over the Net.
Only the later Communication is done secure.

Am i right that only a https login-Form-page would be safe?

Whether the form itself was fetched from an http:// or https:// URL is
irrelevant. If the action of the form lists an https:// URL, the data is
encrypted when the form data is sent to that URL.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[David Dorward]

Sherm Pendley wrote:

Whether the form itself was fetched from an http:// or https:// URL is
irrelevant. If the action of the form lists an https:// URL, the data is
encrypted when the form data is sent to that URL.

Although if the form is fetched without SSL the user won't get an
indication from the browser that the page they are on is secure and may
not trust the safety of their password.

[Chris Morris]

Sherm Pendley <sh***@Sherm-Pendleys-Computer.localwrites:

Wilhelm Kutting <wk******@arcor.dewrites:

Hello, i got a little understanding Problem.
on some http-Sites i can log into my Account with Name/Passwort.
The Form-Login-Page ist only http with form action directing to a
"secure" https page.
So - in my understanding the username and password is send uncrypted
over the Net.
Only the later Communication is done secure.

Am i right that only a https login-Form-page would be safe?

Whether the form itself was fetched from an http:// or https:// URL is
irrelevant. If the action of the form lists an https:// URL, the data is
encrypted when the form data is sent to that URL.

*However* it's worth having the form in https too, if that's
practical, so that a concerned user can be sure that the form they see
is the form your server sent (assuming they trust your server
certificate).

--
Chris

[Sherm Pendley]

Chris Morris <c.********@durham.ac.ukwrites:

Sherm Pendley <sh***@Sherm-Pendleys-Computer.localwrites:

>Wilhelm Kutting <wk******@arcor.dewrites:

>
Am i right that only a https login-Form-page would be safe?

Whether the form itself was fetched from an http:// or https:// URL is
irrelevant. If the action of the form lists an https:// URL, the data is
encrypted when the form data is sent to that URL.

*However* it's worth having the form in https too, if that's
practical, so that a concerned user can be sure that the form they see
is the form your server sent (assuming they trust your server
certificate).

Good point - I took the question too literally, and answered it in a
technical sense only. Putting your form on an https:// URL isn't strictly
necessary for technical reasons, but it will definitely help your users
feel safer.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Wilhelm Kutting]

Nikita the Spider schrieb:

In article <e9**********@newsreader2.netcologne.de>,
Wilhelm Kutting <wk******@arcor.dewrote:

>Hello, i got a little understanding Problem.
on some http-Sites i can log into my Account with Name/Passwort.
The Form-Login-Page ist only http with form action directing to a
"secure" https page.
So - in my understanding the username and password is send uncrypted
over the Net.
Only the later Communication is done secure.

Am i right that only a https login-Form-page would be safe?

Wilhelm,
Basically, yes.

HTTP = not secure, name and password sent without encryption

HTTPS = secure, name and password sent encrypted
Hope this helps

So if the loginform is http, the username and password is send via
cleartext.

So the login on this page is totally dumb:
http://www.aerzteblatt.de/cme/

They offer both login over http and https and the result is the Same:
Clear Username and clear password

This is not the only page where i saw such a thing.
i don't understand the misleading of users...

[Chris Morris]

Wilhelm Kutting <wk******@arcor.dewrites:

Nikita the Spider schrieb:

Wilhelm,
Basically, yes.
HTTP = not secure, name and password sent without encryption
HTTPS = secure, name and password sent encrypted
Hope this helps

So if the loginform is http, the username and password is send via
cleartext.

The protocol used to *retrieve* the form only affects the protocol
used to *submit* the form if a relative URL is used for the form action.

<form action='https://www.example.com/' method='post'(absolute URL)
will *always* submit securely whether the page with the form on was
retrieved via http or https (or even file, ftp, or other less likely
protocols)

<form action='/login' method='post'(relative URL)
on the other hand will use whatever protocol was used to load the page
to submit the form.

--
Chris

[Bert Lancaster]

On Fri, 14 Jul 2006 10:43:44 +0100, Wilhelm Kutting <wk******@arcor.de>
wrote:

> HTTP = not secure, name and password sent without encryption
HTTPS = secure, name and password sent encrypted
Hope this helps

So if the loginform is http, the username and password is send via
cleartext.

No, the statement you were replying to is incorrect.

If the form is submitted to a HTTPS address (or a HTTP address that set to
use SSL/TLS) then the form data will arrive securely, but there is another
issue with using insecure login pages like this.

How do you know what data is being sent there securely, and what else is
being sent to other addresses? By using an insecure login page, or by
including insecure elements inside an HTTPS page (javascripts, iframes,
etc), you make it possible for the login page to be tampered with by third
parties. Malicious Javascript could be inserted to read users' login
credentials when they submit the form, and this could then be sent
elsewhere just before they go to the real login page. Or they could divert
the form submission to a page of their own (such as a fake site to try and
get more information - "Important message from your friendly service
provider - Your credit card information is now out of date, please
<a...>update it now</ato avoid problems, thank you.")

It's good practice to have both the login page and the page you submit to
fully secure (with everything in that page sent over HTTP from the same
server - including the Javascripts, images and even any adverts!). Some
sites don't like doing this because HTTPS pages use more server resources
and all the hits from random passers-by can increase the load, but in an
age where phising scams and identity theft are rife, everyone should be
doing it regardless.

Security is only as good as the weakest link in the chain, and an insecure
login page is open to attack just as much as any other insecure page.
Wherever your password and username end up, remember that they're typed
into that insecure page first.

[Sherm Pendley]

Wilhelm Kutting <wk******@arcor.dewrites:

Nikita the Spider schrieb:

>In article <e9**********@newsreader2.netcologne.de>,
Wilhelm Kutting <wk******@arcor.dewrote:

>>Hello, i got a little understanding Problem.
on some http-Sites i can log into my Account with Name/Passwort.
The Form-Login-Page ist only http with form action directing to a
"secure" https page.
So - in my understanding the username and password is send
uncrypted over the Net.
Only the later Communication is done secure.

Am i right that only a https login-Form-page would be safe?

Wilhelm,
Basically, yes.
HTTP = not secure, name and password sent without encryption
HTTPS = secure, name and password sent encrypted
Hope this helps

So if the loginform is http, the username and password is send via
cleartext.

No.

It's the URL in the form element's "action" attribute that determines whether
the user name and password are encrypted, not the URL of the form itself.

As others have mentioned, fetching the form itself via https:// does provide
user feedback in many browsers which display "lock" icons and such. But it
technically makes no difference whatsoever in how the form data is sent to
the action URL.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Charlie Sorsby]

Sorry -- would have liked to have replied to Sherm but the post
didn't seem to have a working e-mail address.

In article <m2************@Sherm-Pendleys-Computer.local>,
Sherm Pendley <sh***@Sherm-Pendleys-Computer.localwrote:
[...]
= Web Hosting by West Virginians, for West Virginians: http://wv-www.net

I'm just curious (as a displaced West Virginian) why the registrant
for the domain, wv-www.net, is in Scottsdale, AZ?

Clearly, said registrant could also be a displaced West Virginian
but it does look a little funny...
--
Charlie Sorsby
cr*@swcp.com
Edgewood, NM 87015
USA

[Sherm Pendley]

cr*@sorsby.org (Charlie Sorsby) writes:

Sorry -- would have liked to have replied to Sherm but the post
didn't seem to have a working e-mail address.

Post here, reply here has been usenet tradition for decades. Besides, there's
a URL in my .sig, and my site has contact information. I'm not really hiding,
just trying to discourage automated spam harvesters.

In article <m2************@Sherm-Pendleys-Computer.local>,
Sherm Pendley <sh***@Sherm-Pendleys-Computer.localwrote:
[...]
= Web Hosting by West Virginians, for West Virginians: http://wv-www.net

I'm just curious (as a displaced West Virginian) why the registrant
for the domain, wv-www.net, is in Scottsdale, AZ?

I do my domain registration through GoDaddy.com, and lease server space from
Server Beach. My office (and home) is in WV though - Morgantown, to be exact.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Jack]

Charlie Sorsby wrote:

Sorry -- would have liked to have replied to Sherm but the post
didn't seem to have a working e-mail address.

In article <m2************@Sherm-Pendleys-Computer.local>, Sherm
Pendley <sh***@Sherm-Pendleys-Computer.localwrote: [...] = Web
Hosting by West Virginians, for West Virginians: http://wv-www.net

I'm just curious (as a displaced West Virginian) why the registrant
for the domain, wv-www.net, is in Scottsdale, AZ?

Clearly, said registrant could also be a displaced West Virginian but
it does look a little funny...

You appear to have misread the WHOIS results. The registrant for that
domain is keeping their personal details private, by using Godaddy's
Domains-by-Proxy registration service.

GoDaddy is located in Scottsdale, AZ.

--
Jack.