Customers do notice the logos. I know from first-hand experience.
I've been selling my photo-deblurring product on the web for about a year now. I've always processed payments through Stripe, and I've always served the entire web site using SSL. The green padlock is in the address bar.
And yet, back in the early days, I got questions from potential customers several times a month asking if my purchase form was secure.
My solution? I added the text "Payments processed securely" and a generic padlock icon near the credit card info part of the purchase form. In the eight months since then, I haven't had a single person ask me whether or not my site was "secure." Silly, but effective.
Wait. So standard HN mod practice is to change the HN link text to reflect the original article's title, right? That's been my understanding (though I've usually disagreed with it).
So, here, the OP submits a post using the article's original title ("Why I am the world’s greatest lover (and other worthless security claims)"), and you then change the text of the HN link to the article's boring sub-head?
Mods, why do you treat the HN readership like children?
You should probably just send feedback like this to pg. There's no evidence that the mods read or respond to complaints in the comments, so all it's doing is cluttering up the discussion.
My company performs security assessments for businesses, and man do I hate the perception that having a security company's logo or "certification" is the correct way to "prove security."
While, unlike most of the badges you see on sites, we do not perform recurring or daily scans, we still field requests for this type of seal all the time.
It's our policy to refuse them outright.
Our reasoning for this is twofold: primarily, it provides a false sense of security. As the article rightly points out, having a badge on your site does not make you secure. Sure, maybe it'll find some "low-hanging fruit" that you can fix, but it's not going to address major security concerns.
The second reason is to protect our own reputation. Security scans, at best, provide a snapshot in time--even if it's a recurring snapshot.
Security is a process, not a state; these seals and logos do everything to lull people into forgetting that.
How is that a security hole? It's actually .Net having a bad default configuration for ASP.Net MVC, a lot of us made this same mistake when doing our first MVC projects. It's not actually exposing anything dangerous (in fact it's hiding the actual error like it should do).
Well, yes .NET (IIS, specifically) does have a poor default (or rather, the default *.config files created by things like VS have poor defaults). However, hiding the error isn't really enough. Yes, it doesn't expose very many things. But it has exposed, of course, that you're running IIS. And the site is .NET in some form.
Those might not seem a big deal, but you've just provided quite a lot of hints about what the attack surface looks like. Most vulnerability scans will flag up "leakage" of data. IIS also does annoying things by default like "powered by IIS" type HTTP headers (it's not alone in that of course). You'll usually be warned to switch that off because you don't want to make attacks easier than they otherwise would be. Internal error form leakage is just another example.
IIS still defaults to adding 'served by ASP.Net' as a 'x-powered-by'. Something I again often forget to remove. And certain versions of MVC you have to jump through hoops to remove their x-aspnetmvc-version. And on top of that you can often tell by just looking at which js files have been included. Is it using MS js files? Yes, then it's 99% IIS with ASP.Net.
So that's not what I, or I would think any reasonable developer, would considered even a vague security concern as an experienced developer with exposure to a few different frameworks can often tell the platform, and thus the probable server, by just looking at the HTML.
If it were a serious security concern MS would have patched the header by now! Instead they've added even more with MVC.
So are there any other reasons? Or is Troy just wrong in this instance?
It's harder than that to hide what server you're using. And keeping such a secret is barely worth it. You can test for characteristics or exploits of all the common servers easily. And it's pretty hard to hide all implementation details. At a glance through the source I can see it's using .axd files and microsoft webforms ajax with a specific version.
Most (all?) web servers stick their names in a header. I've never heard that that is controversial from a security POV. Also, .NET apps are incredibly recognisable from a quick glance of the source code (__doPostBack and VIEWSTATE are two easy tells). Again, most popular web app frameworks leave some hints in the source that makes it fairly easy to figure out what they are (utf8=✓ in rails).
It's harder to detect the framework when ASP.NET MVC is used. No view state in the source code, no .aspx extensions and the server response headers identifying IIS and ASP.NET can be removed. There's always HTTP server fingerprinting but you're moving on past the low-hanging fruit now.
Well, after removing all the default headers, there's the CSRF token, certain paths that will bypass a regular 404 detection, and so on... There are ways.
Most vulnerability scans inflate their findings with non-security stuff because it brings more business and false positives are always well received by management (less by those who actually has to evaluate the results technically). Better safe than sorry, they say. However, I have hard time seeing how it is a security vulnerability. Discovering IIS server is easy anyway, unless you take very special precautions which 99.999% of people never do, and any automated exploit tool that wanders on the site would do that discovery anyway, so would any focused attacker. So this specific thing is not nice, it looks unprofessional, it may annoy or scare the users that accidentally type a wrong thing, but I do not see how it's security related.
What it shows is that the server is not configured to return a custom error page when an exception occurs. Beyond the obvious usability issue, this may be used by an attacker to identify sites that leak internal information. It's not a vulnerability per se, but it's a gateway to helping find them.
this may be used by an attacker to identify sites that leak internal information
But what does that even mean? We've already discussed below that thinking you can hide an ASP.Net MVC site is wishful thinking unless you totally strip out every identifying part of the framework client-side, there are so many ways I can think of, including the ones below, like the js libraries, the CSRF style, the CSS style the validation uses, the wrapping of JSON responses in a object named d, etc. etc.
I even have vague recollections of coming across odd behaviours in IIS when it sends the allow-continue header in certain scenarios that no other webserver does. Though I can't remember the details now so might be wrong there.
I think you should stop classifying this as a vulnerability and just call it what it actually is, a misconfiguration.
I always assumed that the worth of these logos (along with the phrase "military grade encryption" and people who advertise "256bit AES") was that they enabled us to easily identify the projects that we didn't want to trust with our data.
The gist of it is that just having "256bit AES" tells nothing if it is properly implemented with a robust block mode, proper key generation and if it is signed.
What to customers think these seals mean? I think they're just being used to give the site a feeling of credibility.
> 2) 65% of consumers agree that a website displaying the Norton Secured Seal is safe to browse and won’t give them a virus.
> 3) 55% of consumers agree that a website displaying the Norton Secured Seal means that the website protects their online privacy.
In other words, customers primarily think that the seal means the website is legit and unlikely to intentionally mess up their computer. When browsing an online store you don't know, that kind of assurance is fairly valuable.
But of course, nothing prevents an illegitimate site from putting those logos up, too.
Everything I've seen points to these logos having a noticeable impact, consumers do look for them. It's an important thing to learn for tech people: you are not your customer.
What next, you'll tell me that software having fancypants 5-star awards from some random shareware-download site might not actually be all that great. I'm shocked I tell you, shocked!
I remember when I first saw these sorts of things becoming commonplace and I wondered "who believes this stuff?". Well apparently everyone because instead of going away they've exploded. There are hundreds of companies that have these sorts of seals and they guarantee almost nothing.
The best outcome for most of them is that they've reviewed your business practices and documentation and you conform with some sort of sanity check. Thats kinda what the ISO certifications are about, and a fair amount of what PCI/etc were about. For the most part though, the PCI certification was arbitrary at best, but required if you wanted to process credit cards/etc. There are still plenty of places that pass PCI style audits, but you'd never want to have your credit card number pass through.
The "scan" business is also interesting because it also doesn't really prove much, other than you might have a firewall or some sort of packet filter. Which is good, but not really great, but better than zero :)
I've noticed that a lot of these logos make claims about fraud protection/insurance with respect to the security certificates they provide (presumably the certificates, at least this is especially the case when you buy an SSL cert from a vendor). Isn't that coverage, in fact, usually limited to the scope provided by the vendor? That is to say, you're covered if something bad happens on their (the certificate provider's) end. If somebody manages to break the encryption outright (practically impossible) or the certificate authority is compromised, revealing your info (more likely, but still not common, and they hopefully have a disaster plan to mitigate this). What's most likely is that the website you're dealing with that has the logo presents the biggest security risk to you, the customer, on its own. This website, I'm guessing and please somebody if you can elaborate on this, probably isn't covered under these 100k+ policies, yes?
You usually get logos of this type "for free!" when you purchase an SSL certificate, and the SSL providers highlight it as some sort of competitive advantage. It's completely ridiculous.
We put a padlock image on our payment pages even though it does absolutely nothing for security, but it might help the conversion rate, so there it is.
Because rightly or wrongly, there's evidence that it increases consumer confidence and results in more purchases / subscribers / customer love. It's an empty promise, but people buy it anyway.
When I was working on WAN optimization I had a development prototype that did a man in the middle attack on SSL connections and resigned the connection with a locally generated certificate (also added to the browser).
My bank also had these logos, and despite me having a mitm attack going on, those logos stayed up. I failed to find a single scenario under which they went away!
Hell in one of our apps we just put the damned logo as an image with nothing behind it. Does anyone notice? No. It's a totally bogus feature. You may as well claim "free sex for purchases".
I've been selling my photo-deblurring product on the web for about a year now. I've always processed payments through Stripe, and I've always served the entire web site using SSL. The green padlock is in the address bar.
And yet, back in the early days, I got questions from potential customers several times a month asking if my purchase form was secure.
My solution? I added the text "Payments processed securely" and a generic padlock icon near the credit card info part of the purchase form. In the eight months since then, I haven't had a single person ask me whether or not my site was "secure." Silly, but effective.