plexus wrote:Unfortunately this will likely not happen. if you are concerned about your personal info and password you should consider putting as minimal amount of personal info as possible in the registration info and use a unique password for this forum that you do not use elsewhere. thanks for looking into this.
jeromedayton wrote:plexus wrote:Unfortunately this will likely not happen. if you are concerned about your personal info and password you should consider putting as minimal amount of personal info as possible in the registration info and use a unique password for this forum that you do not use elsewhere. thanks for looking into this.
I don't mean to be an alarmist here (well maybe I do) but in this day in age, it's almost unconscionable that any website would manage passwords in the clear because the very purpose of passwords is to prevent someone from impersonating you and doing bad things in your name, (like posting profanity as me and getting me kicked off this website, let alone getting enough information to steal my identity).
I long ago adopted the habit of having a unique password for each website as not all website's are diligent about guarding where and how they store them and thus a breach on one website was a breach across multiple websites. But I assure you not everyone is as diligent about this as I am so there are probably a lot of forum users at risk right now!
I'm sorry if I'm paranoid but I worked on DOD stuff were security was paramount and this lack of encryption makes me quake in my boots. I've just seen what determined hackers can do. I can guarantee that hackers will target ANY website were passwords are used in the clear to see what they can harvest!!!!! I'm not the only one in jeopardy here.
Can you pressure dreamhost to change their password management?
Otherwise I'll have to seriously consider whether I can continue to post to this wonderful resource.
jeromedayton wrote:I also want to thank Plexus for his continuing efforts to keep this forum running.
evanalmighty wrote:Most non e-commerce sites, besides big ones like google and yahoo, don't use SSL. And just because the lack of SSL allows someone to sniff data being sent, it doesn't mean the data is in plain text. Imagine yourself listening in on a phone call and all your could hear is static noises. Lets say my password for this forum is password, but it's stored in the forum database as something like $H$7rssbSMgLmkpWoRKZMdk6ERZ4Fhrkq1.
thawkins wrote:SSL mainly protects against man in the middle attacks, an attacker would have to be between you and the site.
jeromedayton wrote:First my conclusions from above have not changed. However there are a couple of statements I need to challenge as I did application security for a living.evanalmighty wrote:Most non e-commerce sites, besides big ones like google and yahoo, don't use SSL. And just because the lack of SSL allows someone to sniff data being sent, it doesn't mean the data is in plain text. Imagine yourself listening in on a phone call and all your could hear is static noises. Lets say my password for this forum is password, but it's stored in the forum database as something like $H$7rssbSMgLmkpWoRKZMdk6ERZ4Fhrkq1.
Regardless of whether the password is encrypted by the client before it is sent to the server, what's important IS WHAT IS PRESENTED TO THE SERVER. So if my password is "password" but is encrypted to "$H$7rssbSMgLmkpWoRKZMdk6ERZ4Fhrkq1" by the client (perhaps by jscript) before it is sent to the server, I NOW HAVE THE KEY TO GET INTO THE SERVER. All I have to do in the future is to use the username (which I have also sniffed), and this "encrypted" password to get into the server. When I say "clear text" I mean unencrypted (non ssl) traffic.thawkins wrote:SSL mainly protects against man in the middle attacks, an attacker would have to be between you and the site.
Not quite true. SSL's main job is to encrypt traffic so packet sniffers can't decipher that traffic. Part of setting up an "encrypted" connection is making sure no one is defeating this setup by doing a man in the middle attack. When you ask for a HTTPS connection, you are going through a multi step handshake to establish the connection. First you negotiate over how strong the encryption should be (how many bytes the key will be). Then the client encrypts with the Server's public key (provided by the server's SSL certificate) both the key it wants to use for the connection/session AND a challenge. The Server then decrypts that connection/session key using it's private key (also provided by the Server's SSL certificate, and if the security officer has done his job, only available on the Server), encrypts the challenge with the connection/session key, and returns the challenge. The client then checks the returned challenge (encrypted with the connection/session key) and if it is okay, then proceeds to encrypt all communication with the Server with the connection/session key. The Server then does the same. A man in the middle who is attempting to act as the server and provide a false secure connection would first be defeated by his inability to decipher the connection/session key (encrypted with the public key) and as an extra precaution, his inability to properly return the challenge. The people who designed SSL really thought this through.
I've worked on systems where we not only routinely used ssl, but also used short time to live "credential" cookies. Typically in a web based system, a "version" of your credentials are stored as a cookie on the client so you don't have to be re-authenticated on each roundtrip. To guard against the possibility of someone hacking the client and getting these cookies, the cookies were only good for about 5 minutes. And on each roundtrip, we would return a new security cookie. If someone managed later to get the security cookie by hacking a client, it would only be good for about 5 minutes, hopefully too late to do the hacker any good.
To say that I'm security paranoid would be an understatement. We were exposed to multi-million dollar liability if we failed to adequately guard client assets.
thawkins wrote:But this is not an ecomm system, there is little more than lunch money envolved here, so ssl is overkill and not relevant.
evanalmighty wrote:I'm not going to debate SSL since you seem to be on top of what it is and what it isn't. I'm just saying it's like you're saying you won't take your kids to the park if the park doesn't have a metal detector with bomb snuffing dogs roaming the fields.
jeromedayton wrote:Well it looks like I overreacted.
And I had also falsely assumed that Plexus was using forum application software provided by dreamhost and come to find out that he built and maintains the website in phpBB and that it is fairly brittle. So to expect someone who is largely unpaid to fix this is unreasonable.
Users browsing this forum: No registered users and 1 guest