A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
When logging in to a web app, I understand that doing a post to a page that is not https:// will send the username and password in clear text to the server.
What exactly are the risks of this? I just want to understand how an attacker would be able to compromise usernames/passwords under this setup. Do they need to be on the user's local network sniffing packets or can they be somewhere else along the request's path?
I guess I just want to understand how critical setting up an ssl server is for a fairly basic web app. Some sites put all login pages behind ssl, but most don't.
What are your thoughts?
I would say, pretty much everywhere these data goes will be open for all curious eyes, not just your local ISP net. But, for user/password for your club membership (not so critical information) could not be that important. Of course, if you are a Bank, or have your own CC transactions, you should not even dream of not using SSL.
Thursday, December 28, 2006
"What exactly are the risks of this? I just want to understand how an attacker would be able to compromise usernames/passwords under this setup."
Every computer or electronic device that forwards traffic from your client to the server and back, can make a copy of that traffic. For example, if I were to connect to Joel on Software's discussion board, I'd go through the following machines that I know about:
1 (My machine)
I recognize #s 2 through 4 and 7 through 11 as my ISP and the network backbone respectively and I suspect #12 is Joel's ISP but I really don't know who #6 is.
Since #6 has to see the traffic in order to pass it along, the only thing I can really do to keep #6 from doing anything bad with it, is make it appear to be gibberish, i.e., encrypted.
However, since encrypting it comes with a price of its own, people tend to reserve it for data that is potentially harmful if it falls into the wrong hands. My bank info should be encrypted. My Aunt Petunia's receipe for double chocolate chip cookies is not worth the effort.
Sunday, December 31, 2006
"Some sites put all login pages behind ssl, but most don't."
Incidently, these are two parallel concepts that protect seperate aspects of who you are.
SSL is just concerned with encrypting traffic so that no one else can eavesdrop on you. SSL really doesn't care who you are, just that Joe Hacker isn't you.
Login pages are concerned with identifying who you are and granting you privileges accordingly. If Joe Hacker says he's you, then he will get the same privileges you get.
They are complimentary, in the sense that if you send your password via SSL, it makes it harder for Joe Hacker to get your password and subsequently masquerade as you. However, for sites of "little value" such as your pastry baking club's forums, there's not much Joe Hacker can do with your password anyway, so there's no point in going to the extra effort.
Consider this analogy:
The login page is equivalent to your front door, complete with locks and deadbolts.
SSL is equivalent to the doberman pincher you've decided to tie up in the front yard, to prevent anyone from sneaking up to the door and making wax impressions of the locks.
Sunday, December 31, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz