Facebook's own TLS cert used by crooks in double logon phish Netcraft security man Paul Mutton says phishers are using Facebook's TLS certificate to create a 'remarkably convincing' scam that would go unnoticed by most users. The phish uses an iframe to serve a Facebook verification form, but that form isn't from The Social NetworkTM. Instead, the form comes from an external Hostgator …
Facebook and Google IDs are both more and more used as a sign-in alternative to creating local accounts by a LOT of online services. You know, for user convenience and ease of development (offload authentication and account management to Facebook = save days of work!)
So besides the obvious "high % of Facebook users will use the same password everywhere" and "their Facebook email will be behind the password recovery scheme of other sites", the actual Facebook ID itself is quite valuable - would take seconds to test every phished credentials against hundreds of sites where valuable things might be stored.
Which is why I never use my facebook account for anything except facebook, and I never use facebook for anything that could conceivably be of any value to any phisher, or indeed anyone.
Facebook, of course, wants to become the golden gate and front page to your entire online life. Not only making themselves custodian and reaper of all your juicy details, but also the ideal phishing target. You'd be foolish to follow their plan.
> What is the point in stealing somebody's facebook id?
Because Facebook is the new E-mail, and E-mail is the source of truth for authentication: if you can take over someone's E-mail you can do a password reset on pretty much any other service they use.
Banking credentials therefore are a click or two away.
Not to mention that anyone who uses Facebook is likely to use the same password for everything else anyway.
This post has been deleted by its author
Users should alter their security settings to enable login approvals that ask for two-factor authentication whenever logins occur from unknown origins. close their Faecebook account immediately.
They are even demanding passports and photo ID now to verify user accounts and claiming its OK to do it anywhere in EU because it's OK in Ireland.
They are the home of the fatuous. They offer nothing that can't be done better using other services that are not attempting to own the www and people are now embarrassed to admit they use Faecebook. Bin the bastard now.
I never use OAuth logins for anything, anywhere, ever. If the login provider gets hacked -- or spoofed, as in the article -- then my account on every site where I used that login service would be pwned.
On phone apps, where the login takes place within the app as opposed to in a browser, there's often no easy way to determine whether the login form is legit or fake. If a site or app requires Google or Facebook credentials, I find a different product.
Hacks aside, using FB or Google login also "shares" some of your personal information with the site, the amount of which might be arbitrarily changed at some future date. (You did read all 20K words of the T&C, right? Because I'll guarantee that their lawyers did) And, of course, FB or Google can track every time you log into the third-party site.
I use a password manager and a unique, machine-generated random password for each site. If a site's user DB gets hacked, those credentials won't work anywhere else. And unless the site truly needs my real name and address in order to function, the rest of my personal info is fictional.
Why can't the browser itself alert the user when there is a mixture of TLS certicates from different domains on the same page? Most of them already alert if you visit a page where the TLS certificate subject name does not match the URL you have visited.
Instead, the form comes from an external Hostgator site that uses HTTPS and Facebook's certificate.
This is wrong.
The main page, hosted on apps.facebook.com, uses Facebook's certificate, since it's a Facebook site.
The iframe hosting the form comes from (came from, as Hostgator has taken the site down) gator4207.hostgator.com, in Mutton's example. It sends a certificate for *.hostgator.com, of course; otherwise the browser would show a security warning.
The problem is that when a page combines content from multiple sources, and two or more of those sources are using HTTPS, browsers don't alert users to the discrepancy (as they do for, say, a mix of HTTP and HTTPS sources). It's common for sites to mix content this way, for example with external images or scripts on HTTPS sites. So users would quickly disable or ignore such browser warnings anyway.
This is broken by design. Websites assemble content from multiple origins; browsers communicate that to the user as a single document. We need a conceptual extension of the SOP to communicate that security boundary to the user, in a clear fashion. Good luck with that.
On the other hand, a start would be for browsers to warn the user if a form submission was headed to some destination not in the main page's origin (per SOP). IE had (has?) that "warn if form submission is redirected" option, which is misnamed and, if memory serves, did not communicate a warning that would be useful to non-experts. But it's the right idea.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
