Must logins be a https page

Several security experts have said in the past that the login page should be on ssl https. So what if my login is a block that's displayed on all pages. Does that mean that my entire website has to be https?

I read it's possible to put the form on http but post it to https, but I read someone saying that it can be exploited with a man in the middle attack. Can someone confirm this? I have a 100 point bounty for someone who can confirm this (and help me with a practical answer how to securely solve this). My login form is on every page, do I need to make the whole website on https? Please feel free to question anything I said here. They're only things I read but don't have experience with and didn't try it myself.

Edit: to those who asked, when I was posting the question, I tried setting the bounty but the system wouldn't let me. I checked the FAQ and saw that bounty can be posted after 2 days from posting the question. That's why you see no bounty yet. But I will not select an answer until I set a bounty 开发者_StackOverflow社区in 2 days. Sorry for any confusion.

I read it's possible to put the form on http but post it to https, but I read someone saying that it can be exploited with a man in the middle attack. Can someone confirm this?

Yes. The form is served up over HTTP, so a man in the middle could inject changes to it (e.g. so it sends credentials to their own server before the form submits).

a practical answer how to securely solve this

If security really matters — use HTTPS for the entire site. Even after the password has been sent, if you go back to HTTP then the cookie can be stolen (see Firesheep)

If security doesn't matter that much, then don't put the login form on every page. Just have a link to a login page instead.

Simple answer "Yes" your login page and rest of the websites should be served over SSL

And here is why from SSL Implementation FAQ:

• Can I put my Login form to HTTP and target my form to HTTPS?
• Is it secure switch back to HTTP after login over HTTPS?

Well, if you don't use SSL for logins, user's password may be revealed to anybody who has means to listen to the client-server communication (basically reading the data stream). (Which is not good ^^)

As said by above goreSplatter, you can easily set the form target to secured endpoint (i.e. https://site.com/login) and a secured connection will be used for sending user's credentials and receiving response.

Most websites then continue to communicate over basic HTTP, which "only" exposes their users to the risks of session hijacking (man-in-the-middle reads their session identifier/signature/nonce/whatever and then pretends to be the authenticated client, therefore if he succeeds, he can manipulate client's protected resources, but this method doesn't allow "stealing the entire account"). This is usually considered a minor threat and due to overhead associated with SSL communication, secure connection for all requests is used only in critical applications (online banking, for instance).

Finally, to answer your question: No, only transfers where sensitive data are being sent must be necessarily secured.

If you want your data to be safe you have to use SSL(certified) on your whole site. But you don't need to have SSL to keep your passwords safe. You could for example use openID, facebook connect, twitter sign-in to handle this part for you. This way never passwords get sent over the wire in plain-text.

Do you have the option to redesign the UI concept? The idea: Have informational login UI on every page but not the actual login control. Your new info control would list:

1. Logged In As <user_name> or Not Logged In
2. Login or Logout link depending on state

The links would then show a login pop up page whose contents are entirely secured.

This approach would get you close to what you already have (some login functionality on each page) but routed/layered in a way that your authentication is fully secured over SSL.

For example GMAIL has an option in configuration where you can enable SSL. Facebook, Twitter and all of Social Media don't have SSL or are not enabled.

I think if you really want your website safety from all malicious (bot or not) better you use SSL. (yet if are SSL enabled you have a risk of hijacking ) Otherwise you can try a js hardcode to obfuscate the form data.

Good Answers above, plus everything and get your own ideia about the matter!

Good Luck.

I read it's possible to put the form on http but post it to https, but I read someone saying that it can be exploited with a man in the middle attack.

No. The target of the <form> is a fresh call performed by the browser in use.

If the URL http://example.com/ has been visited and the page's content has been rendered by the browser, the unsecure connection is closed (yes. It may be kept open [Keep-Alive]. But the request for that URL is finished).

For the site's login target https://example.com/ an SSL-session will be negotiated between server and client using a different server port (usually 443) and no data from the prior page (except maybe "Referer") is used/transmitted after the secure connection has been established.

I read it's possible to put the form on http but post it to https, but I read someone saying that it can be exploited with a man in the middle attack. Can someone confirm this?

Yes. The form is served up over HTTP, so a man in the middle could inject changes to it (e.g. so it sends credentials to their own server before the form submits).

On a compromised site it doesn't matter, whether the content was served secured or not. A site's contents can be delivered via SSL but the code can still be compromised.

Also, cookies can be stolen. But they're just text. It's what your site does with that "text" is what it's important. If you rely on what a "browser" tells your scripts, your application is unsecure. Use cookie validation (IP based, browser based, whatever based) so cookies cannot be "stolen".

Use SSL secured sites whenever your users send data, that is worth protecting. Commenting a blog post is not a thing I would stress my server with establishing an SSL connection for...

Even if you tried to put the login block in an iframe that uses https , a man-in-the-middle attack might change the src of that iframe easily , so you either make the loginbox a login link (with https login page) or you will need more resources to run your website with ssl for all webpages that has the login box ...