Am I being overly zealous about "proper SSL implementation?"
June 30, 2008 8:49 AM Subscribe
Am I being overly zealous about "proper SSL implementation?"
We've been working with this new collections agency for a few months now. From the very beginning, I noticed that their PHP-driven website was not secured with SSL so I refused to use it and would instead manually encrypt data (256-bit AES) and submit it to them via email. My security concerns caused me to question the entire outfit, but I was informed about how reputable the company is, and how much better they would be than our current agency, etc.
They have a "Place Accounts" page on their website where you are expected to fill out a full-blown help-us-skip-trace form (including social security numbers) which was not secured. You also have the option of uploading CSV files. In either event, the page was not secured.
I asked them to implement SSL (and secure FTP, if possible). A month later, you go to their "Place Accounts" page and are told by IE "this page contains secure and non secure items..." The page itself was an https resource, but the "action" property of the form redirected to a non-secure URL, meaning that when you filled out the form (or uploaded the file) the transaction was not encrypted (correct?).
So I complained about this, and they changed the "action" property of the form to redirect to a secure resource, but then changed the way they link to the "Place Accounts" page, so that their "Place Accounts" page was once again a standard http resource, eliminating the "secure and non-secure items" warning from IE but giving the user no visual cue (no padlock icon, or https) that the site is secure.
I complained again; a month later we're back to an https "Place Accounts" page, the "action" property of the form is secure, but the page still contains "secure and non-secure items," which causes a warning, does not present a padlock icon, and therefore requires a careful user to scrutinize the source to truly know that the page is "secure enough." Sure, it's probably usable at this point, but this is sort of like dealing with terms and conditions that can change at any time; if I can't just glance and see a padlock, how do I know, each and every time I use the page, that it hasn't been tweaked and broken again?
At this point I feel I should inform them that their web administrator / developer is incompetent. Am I being overzealous? How should I approach this? I've been working with their IT manager who I'd expect should be able to communicate with the web team, but do I need to grab the bull by the horns and talk to these guys directly? Should it really be this complicated? Why not just secure the entire site and use SSL everywhere to eliminate all doubt?
I've explained what I'm looking for many times (the entire "Place Accounts" page should be secured in order to present the padlock icon and no warnings) and it seems they take an entire month to make a change and get back to me, and it's a different, less-than-ideal result each time.
I'm also curious about your general attitudes towards encryption of data in transit. I deal with HIPAA a lot, which contains "addressable" requirements for encryption. I am often told by different folks that my approach to security is paranoid; "nobody's going to intercept that file! That'd be too hard!" In the case of email there are plenty of ways to breach security without intercepting individual packets (i.e. guessing a webmail password), whereas in an HTTPS situation, there isn't a cheesy Yahoo account on the other end, and you're more specifically concerned about interception in transit.
This isn't the first business I've encountered that deals with confidential information yet can't seem to properly implement SSL. Back me up here or tell me how you see it. I don't want this to become chatfilter, but I need your help in calibrating my security perspective.
We've been working with this new collections agency for a few months now. From the very beginning, I noticed that their PHP-driven website was not secured with SSL so I refused to use it and would instead manually encrypt data (256-bit AES) and submit it to them via email. My security concerns caused me to question the entire outfit, but I was informed about how reputable the company is, and how much better they would be than our current agency, etc.
They have a "Place Accounts" page on their website where you are expected to fill out a full-blown help-us-skip-trace form (including social security numbers) which was not secured. You also have the option of uploading CSV files. In either event, the page was not secured.
I asked them to implement SSL (and secure FTP, if possible). A month later, you go to their "Place Accounts" page and are told by IE "this page contains secure and non secure items..." The page itself was an https resource, but the "action" property of the form redirected to a non-secure URL, meaning that when you filled out the form (or uploaded the file) the transaction was not encrypted (correct?).
So I complained about this, and they changed the "action" property of the form to redirect to a secure resource, but then changed the way they link to the "Place Accounts" page, so that their "Place Accounts" page was once again a standard http resource, eliminating the "secure and non-secure items" warning from IE but giving the user no visual cue (no padlock icon, or https) that the site is secure.
I complained again; a month later we're back to an https "Place Accounts" page, the "action" property of the form is secure, but the page still contains "secure and non-secure items," which causes a warning, does not present a padlock icon, and therefore requires a careful user to scrutinize the source to truly know that the page is "secure enough." Sure, it's probably usable at this point, but this is sort of like dealing with terms and conditions that can change at any time; if I can't just glance and see a padlock, how do I know, each and every time I use the page, that it hasn't been tweaked and broken again?
At this point I feel I should inform them that their web administrator / developer is incompetent. Am I being overzealous? How should I approach this? I've been working with their IT manager who I'd expect should be able to communicate with the web team, but do I need to grab the bull by the horns and talk to these guys directly? Should it really be this complicated? Why not just secure the entire site and use SSL everywhere to eliminate all doubt?
I've explained what I'm looking for many times (the entire "Place Accounts" page should be secured in order to present the padlock icon and no warnings) and it seems they take an entire month to make a change and get back to me, and it's a different, less-than-ideal result each time.
I'm also curious about your general attitudes towards encryption of data in transit. I deal with HIPAA a lot, which contains "addressable" requirements for encryption. I am often told by different folks that my approach to security is paranoid; "nobody's going to intercept that file! That'd be too hard!" In the case of email there are plenty of ways to breach security without intercepting individual packets (i.e. guessing a webmail password), whereas in an HTTPS situation, there isn't a cheesy Yahoo account on the other end, and you're more specifically concerned about interception in transit.
This isn't the first business I've encountered that deals with confidential information yet can't seem to properly implement SSL. Back me up here or tell me how you see it. I don't want this to become chatfilter, but I need your help in calibrating my security perspective.
If they can't be bothered to do a decent job of securing data while it is in transit, I'd have absolutely no faith in their ability or inclination to secure the data once it is stored on their servers.
I guess the mitigating factor is that identity thieves aren't going to be in a hurry to steal the identity of people who come to the attention of collection agencies.
posted by Good Brain at 9:16 AM on June 30, 2008
I guess the mitigating factor is that identity thieves aren't going to be in a hurry to steal the identity of people who come to the attention of collection agencies.
posted by Good Brain at 9:16 AM on June 30, 2008
Yeah, they don't know what they're doing. You're completely in the right. They're dealing with sensitive information and should be more careful.
posted by amtho at 9:17 AM on June 30, 2008
posted by amtho at 9:17 AM on June 30, 2008
"nobody's going to intercept that file! That'd be too hard!"
I'm sure I've heard Penn Jillette state that a fair proportion of magic tricks rely on the audience thinking "nobody would do it that way! That'd be too hard!" but people really do put that much effort in and often for less gain.
You're right to be cautious.
posted by edd at 9:25 AM on June 30, 2008
I'm sure I've heard Penn Jillette state that a fair proportion of magic tricks rely on the audience thinking "nobody would do it that way! That'd be too hard!" but people really do put that much effort in and often for less gain.
You're right to be cautious.
posted by edd at 9:25 AM on June 30, 2008
odinsdream, the page you enter the data into does not have to be https for the transmission to be secure. What matters is that the page that receives the data (the one specified in the "action" part of the form) is an https url. Your data is completely safe.
posted by zsazsa at 10:00 AM on June 30, 2008
posted by zsazsa at 10:00 AM on June 30, 2008
zsazsa: But you can't be expected to view source every time you submit a form. If the page with the form on it is not SSL, you have no idea where you are sending your data to, since the page could have been modified in transit.
aydeejones: Run away. Who knows what else they are doing insecurely. Not using SSL at all for this seems like a bad sign, and not using it correctly seems like a worse sign.
posted by sergent at 10:06 AM on June 30, 2008
aydeejones: Run away. Who knows what else they are doing insecurely. Not using SSL at all for this seems like a bad sign, and not using it correctly seems like a worse sign.
posted by sergent at 10:06 AM on June 30, 2008
If you're really serious about showing how insecure their setup is, schedule a demostration and pluck data out of the air for them. Be prepared to get fired for it, though, because you're an evil hacker.
posted by cellphone at 10:09 AM on June 30, 2008
posted by cellphone at 10:09 AM on June 30, 2008
Trust me, you're not being too paranoid. Packet sniffing does happen in the real world, I've seen the results and it ain't pretty. Hacking is the new growth industry for organized crime, and many former Communist countries are teeming with smart IT guys who can't get enough honest work to live off of. The economics are such that no method of compromising valuable data is "too hard" anymore.
posted by TungstenChef at 10:12 AM on June 30, 2008
posted by TungstenChef at 10:12 AM on June 30, 2008
Packet sniffing is real, and very much a problem. Simply ask this - do they believe every person that works at your company, everyone on their network, and everyone that works for every ISP in the middle to be either entirely trustworthy or entirely IT illiterate? Because it takes all of 5 minutes to start ARP spoofing traffic on your local network with a tool like cain and abel even if you're a tech moron. It's even easier for your ISP to slap a sniffer on there. You might want to demonstrate how easy it is to sniff the unencrypted data, with prior permission of management. Ask if they'd be happy sending the same information through the postal system printed on the back of postcards, because that's about the same security level as unencrypted http.
You're not paranoid, you're being sensible. I don't know what regulations cover the transmission of personal data in the US, but sensitive personal data in europe that gets handled improperly can lead to huge fines, big civil suits and in some rare cases, jailtime. And yes, their webdeveloper is either very cheap, or incompetent. SSL is not hard to do, assuming you're prepared to use a fixed IP and pay for a cert - and if you can do it at all, you can do it for everything.
posted by ArkhanJG at 10:25 AM on June 30, 2008
You're not paranoid, you're being sensible. I don't know what regulations cover the transmission of personal data in the US, but sensitive personal data in europe that gets handled improperly can lead to huge fines, big civil suits and in some rare cases, jailtime. And yes, their webdeveloper is either very cheap, or incompetent. SSL is not hard to do, assuming you're prepared to use a fixed IP and pay for a cert - and if you can do it at all, you can do it for everything.
posted by ArkhanJG at 10:25 AM on June 30, 2008
Putting just one page on SSL and having a form on it submit to an https:// URL is a no-brainer, I've done it tons of times. Their admin is incompetent and you should be going up the chain to ensure that your data is handled securely and professionally. You could also start researching other collection agencies to present to your bosses as just an aside: "This shouldn't be that difficult. Look, CompanyA, CompanyB and CompanyC all have secure submission forms." Or something like that, optionally presenting them as alternatives to your current group of losers. Don't worry about fixing this company so much as providing the company you work for with good vendors.
posted by rhizome at 10:36 AM on June 30, 2008
posted by rhizome at 10:36 AM on June 30, 2008
I think the time for complaining is over. They have repeatedly failed to fix the problem. AFAICT, they are only responding to your concerns in the most narrow way possible, rather than actually thinking about how to make the whole process secure. Even if they got the SSL submission right at this point, I wouldn't trust that the rest of the process is secure (e.g. are they storing the info in plain text on a shared web server, or where it might be accessible to others via the web? And I'd be surprised if they were downloading it from the web host to their office in a secure manner)
posted by winston at 11:11 AM on June 30, 2008
posted by winston at 11:11 AM on June 30, 2008
Talk to your company attorney. I wouldn't be surprised if your employer is responsible for any data leakage that occurs during transmission to the collection agency, even if it is their crummy system that allowed it to happen.
posted by Good Brain at 11:47 AM on June 30, 2008
posted by Good Brain at 11:47 AM on June 30, 2008
"the page you enter the data into does not have to be https for the transmission to be secure."
not true. if the form page is delivered over an insecure connection, it can be modified in-transit to send information to somewhere other than where the user think's it's going. to be secure, every part of the chain must be secure, beginning to end.
posted by klanawa at 11:57 AM on June 30, 2008
not true. if the form page is delivered over an insecure connection, it can be modified in-transit to send information to somewhere other than where the user think's it's going. to be secure, every part of the chain must be secure, beginning to end.
posted by klanawa at 11:57 AM on June 30, 2008
You're not crazy, they're incompetent.
posted by Brian Puccio at 12:08 PM on June 30, 2008
posted by Brian Puccio at 12:08 PM on June 30, 2008
Don't worry about fixing this company so much as providing the company you work for with good vendors.
That's gold advice, right there.
posted by gimonca at 12:08 PM on June 30, 2008
That's gold advice, right there.
posted by gimonca at 12:08 PM on June 30, 2008
Make sure you use the phrase "off-balance sheet legal liabilities" when describing this up the chain. You absolutely need a new vendor, this company is gone. Sure the actual chance of them being hacked is low, which is what makes this difficult. You have a ton of liability if the system is is hacked, very little reward if it is not hacked ("it just works").
They don't want to fix the problem because they probably don't understand the problem. Don't blame the admin on their end, there might be a very technical, complex reason they are not using SSL which usually boils down to them not having enough resources to fixing it since it "works" and no one wants to throw money at something that works. I would be surprised if this wasn't upsetting some IT people on their side as well.
That's really a secondary issue. All the e-mails in the world won't save your job if the data is comprimised, "I told you so" doesn't really quite have that actionable ring to it that firing you does.
posted by geoff. at 12:26 PM on June 30, 2008 [1 favorite]
They don't want to fix the problem because they probably don't understand the problem. Don't blame the admin on their end, there might be a very technical, complex reason they are not using SSL which usually boils down to them not having enough resources to fixing it since it "works" and no one wants to throw money at something that works. I would be surprised if this wasn't upsetting some IT people on their side as well.
That's really a secondary issue. All the e-mails in the world won't save your job if the data is comprimised, "I told you so" doesn't really quite have that actionable ring to it that firing you does.
posted by geoff. at 12:26 PM on June 30, 2008 [1 favorite]
You're absolutely right. Ask the "It's good enough" people if they'd trust a bank who doesn't encrypt passwords as it crosses the Internet. If they wouldn't trust their bank, they shouldn't trust this company. I think they've done more than enough to be fired as a vendor.
posted by cnc at 1:11 PM on June 30, 2008
posted by cnc at 1:11 PM on June 30, 2008
@odinsdream - My bank had this exact same issue. I complained for over a year, but it was never addressed properly. End result: I switched banks.
posted by LuckySeven~ at 1:36 PM on June 30, 2008
posted by LuckySeven~ at 1:36 PM on June 30, 2008
Your concerns are very reasonable. It wouldn't be too hard for you to find examples of businesses that have failed to follow good practise and have lived to regret it (Citybank and their lost, unencrypted backup tapes being a recent high-profile example).
Your own business should be concerned about what liabilities it opens itself up for by using a service with known bad practises.
posted by rodgerd at 5:51 PM on June 30, 2008
Your own business should be concerned about what liabilities it opens itself up for by using a service with known bad practises.
posted by rodgerd at 5:51 PM on June 30, 2008
aydeejones, people like you make this world a better place. Personally, i would stop dealing with the company all together.
posted by zackola at 6:23 PM on June 30, 2008
posted by zackola at 6:23 PM on June 30, 2008
The last place I saw that had an unencrypted credit card form was an ASP website for a local winery that was probably put together by the owner's nephew for a case of wine.
However, when I sent the winery owner a detailed email advising him that the data was not safe and I could not safely do business with them, they fixed it in one day and encrypted the whole series of transaction pages from end to end.
This is not rocket science. If you deal with HIPAA or any other privacy acronyms, you need to ditch this company fast.
posted by benzenedream at 11:48 AM on January 15, 2009
However, when I sent the winery owner a detailed email advising him that the data was not safe and I could not safely do business with them, they fixed it in one day and encrypted the whole series of transaction pages from end to end.
This is not rocket science. If you deal with HIPAA or any other privacy acronyms, you need to ditch this company fast.
posted by benzenedream at 11:48 AM on January 15, 2009
This thread is closed to new comments.
I don't think the chances of someone intercepting your file on the fly is high at all, but that's not really the point is it.
posted by zeoslap at 9:03 AM on June 30, 2008