Why logging in to some webpages might be the worst thing you can do.  


Way back in the good 'ol days, 1990, there were some really smart people proposing HTTP.  This is the technology you use today to talk to webservers and request web pages.  
If you're reading this, you're using http  (hopefully, https - as you will see)
In 1999 - the complete specification for HTTP was proposed, and this included "A Basic Authentication Scheme".  In simple terms, this was a way a web server could say "Yes, I have a document to show you, but you have to login first".   Your browser would provide you with a username and password prompt you would use, and send that to the webserver.   Hopefully, the web server would say 'ok, you logged in - here is your document' and all would be happy.   You can now password-protect web pages.
This wasn't ment to be secure.  It was ment to be the first steps towards secure logins over the web.  But, as is the nature of technology - the prototype became the product.
Today, you will still see HTTP Basic Authentication used in web applications to "Secure" a web page.  And if you are using unencrypted http, and using the public internet to reach the web server, when you type in your username and password - that data is sent past many many potentially malicious easedroppers.  Like the NSA, for example, but more likely your average hacker.
This is the conversation that someone 'listening in' will see:
Type in 'http://www.example.com' in to your web browser and hit enter: You send this over the internet to example.com and anyone interested can see it:
GET https://www.example.com/ HTTP/1.1
 :host: www.example.com
accept-language: en-US,en;q=0.8
user-agent: Mozilla/5.0
 :accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
 :version: HTTP/1.1
cache-control: max-age=0
example.com responds, and says you have to login.  It also asks you use the 'Basic Method':
HTTP/1.1 401 Authorization Required
Server: nginx/1.0.4
Date: Thu, 15 Sep 2011 22:44:41 GMT
Content-Type: text/plain
Connection: keep-alive
WWW-Authenticate: Basic realm="WallyWorld"
Your web browser provides you with a username and password prompt.  You happily enter it and hit "Ok"
Your browser sends this back to example.com
HTTP/1.1 Authorization: Basic QVNvY2lhbEV4cGVyaW1lbnQ6QXJlWW91UGF5aW5nQXR0ZW50aW9uPw==
user-agent: Mozilla/5.0
Host: www.example.com 
That big long string of random characters is your username and password - you have to send it somehow.
Well, you say "I can't read that, It doesn't LOOK like a username and password".   You might even say "It's encrypted"
Both of these statements are DANGEROUSLY wrong.
The HTTP 1.1 specification says:
The basic authentication scheme is a non-secure method of filtering unauthorized access to resources on an HTTP server. It is based on the assumption that the connection between the client and the server can be regarded as a trusted carrier. As this is not generally true on an open network, the basic authentication scheme should be used accordingly. In spite of this, clients should implement the scheme in order to communicate with servers that use it. 
It's the server's fault.  The server said 'use Basic Auth'  your web browser simply followed instructions.
The HTTP 1.1 specification says how to send it:
To receive authorization, the client sends the user-ID and password, separated by a single colon (":") character, within a base64 [5] encoded string in the credentials.
Base64 encoding is not encryption.  It is a "Two Way" function.    If you 'encode' a message, you can 'decode' the message.  That's two-way.   You can start with the encoded message and go back to the decoded message.
For a real-world example, let's say you and your friend are passing notes to each other, but they are 'coded' messages.   An easy coding is to just say "A=1, B=2, C=3,... Z=26"  and you write the message in all numbers and pass it to your friend.  Your friend just says "1=A, 2=B, etc" and decodes the message.  Simple.  You also advertise to the world and everyone around you that "This is how we encode messages".  Obviously, this is not very secure.
Another encoding method you're probably familliar with is ASCII encoding.  
Don't confuse "encoding" with "encrypting".  Base64 encoding is just another way of doing the same thing.   You can Base64 encode a message, and then Base64 decode the message without any more information - other than you know that Base64 was what was used to do the encoding.  And you know that already, because we just went over the HTTP 1.1 specification which says it right there.  How HTTP 1.1 works is not a secret.
So, while you were sitting in your favorite coffee shop, and logged in to your email over http using basic authentication, that creepy guy in the corner with his laptop just saw that conversation take place.  He has an evil smile on his face.  And this is what he does:
  Please decode "QVNvY2lhbEV4cGVyaW1lbnQ6QXJlWW91UGF5aW5nQXR0ZW50aW9uPw==" using base64
And up pops your username and password on his screen.
He didn't need a key.
He didn't need to run his computer for 15 minutes to brute-force decrypt the string.
He just decoded it.
Simple.  Very, very simple.  
I'll leave it to you to base64 decode the string above yourself.  Just a little bit of google research should get you the answer pretty quickly.
The Lesson to people using the internet:  Use HTTPS:// whenever possible.
  Don't use your favorite password on rinky-dink websites like forums and such.
Lesson to people creating web servers:  If you're going to make your users login, pick a different authentication scheme other than "basic".    Look at "Digest" authentication - it's much, much better than this. 
Shared publiclyView activity