It seems that most major websites will use a secure domain, but there are a few major exceptions, notably facebook and twitter.
The benefits of using a secure domain are obvious I suppose - your login credentials are never transmitted in plain text.
So how do major sites like facebook and twitter get away with it? If a secure domain is not available for some reason, what extra precautions might one take?
Not the page itself, but what it sends the POST to, yes.
In the case of Twitter, you can view their source and notice the page being POST(ed) to is secure with HTTPS.
I'm not sure what techniques are commonly used, but any information that isn't stored and only compared (i.e., username and password) could possibly be hashed (for example, SHA1 or MD5) on the client.
However, this requires client-side scripting which might be disabled or otherwise unavailable. It could just be that some sites don't consider their information sensitive enough to require secure transmission (you shouldn't send any sensitive information to Facebook or Twitter, etc.).
Hashing your password before transmitting it unencrypted doesn't really help in man in the middle situations, since someone who is intercepting the communication can easily replay your password and sign in with your credential.
I would say that some sort of encryption should be mandatory for authentication purposes. Regarding the question, yes, HTTPS would be the best option. Obviously, the most straightforward thing to check for is the location bar at the top if it starts with "https://", but that doesn't actually matter. What matters is where your authentication info (username/password) gets sent, which could be some other page through standard HTML forms, or some JavaScript magic. The best way is to check the source, or enable browser warnings regarding sending of unencrypted data.
HTH
If security is at all important: Yes, the sign in page must be https, as must the page that it posts to. There simply is no other way.
If you visit a page, and it isn't https, you absolutely can not trust anything submitted from that page. Since the connect is not protecteded, it can be easily tampered with (perhaps by making it submit to a non-https page, or perhaps submitting to an altogether different domain, which you will never know until it is too late). Whereas if you visit an https page, you can trust it. You know where the page originated from and that it hasn't been tampered with. And of course you must submit to an https page, since you want that data to be encrypted (and the browser should warn you if it tries to submit a form from an https page to a non-https page).
Sorry for the late post but I don't think anyone above addressed the key element to how facebook and twitter do it. The main part is, their non-HTTPS login form posts to an absolute URL over HTTPS.
Look at the action:
// facebook
<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">
// twitter
<form method="post" id="signin" action="https://twitter.com/sessions">
In this case, a form's "action" is set to use https and the ssl handshake takes place before any data is sent so the connection is secure. (Whether or not the original form is displayed using https doesn't matter). However, if the form action used a relative path, then it would default to the protocol that was used to display the form. Bottom line, you must use an absolute URL if you want to establish an SSL session before your credentials are sent.
I'll probably get downvoted but the answer to is it "totally necessary", the correct answer really should be no. In most situations it doesn't really matter. Even hotmail.com and other large sites have unencrypted sign in processes, some requiring you to click a link to goto the https page.
It really depends on what you're securing. HIPPA data, financial information yes totally necessary. Standard forum or other website, doesn't really matter.
Executing a man in the middle attack is also not a trival event, this is really more of a concern with hostile networks (like WIFI/school networks/etc) not the internet itself. It is mostly impossible to execute a live man in the middle attack on the web itself without compromising a root DNS server. Cross site scripting is much more of a real attack vector unlike man in the middle that only really has a purpose to try to execute against large banks.