New enhancements to Phishing Filter protection for IE

IEBlog New enhancements to Phishing Filter protection for IE | bar stools

IEBlog New enhancements to Phishing Filter protection for IE | bar stools — Sun, 14 Jun 2009 08:31:44 GMT

PingBack from http://barstoolsite.info/story.php?id=7205

IEBlog New enhancements to Phishing Filter protection for IE | Indoor Grills

IEBlog New enhancements to Phishing Filter protection for IE | Indoor Grills — Mon, 01 Jun 2009 22:16:53 GMT

PingBack from http://indoorgrillsrecipes.info/story.php?id=3147

IEBlog New enhancements to Phishing Filter protection for IE | Paid Surveys

IEBlog New enhancements to Phishing Filter protection for IE | Paid Surveys — Sat, 30 May 2009 02:43:41 GMT

PingBack from http://paidsurveyshub.info/story.php?title=ieblog-new-enhancements-to-phishing-filter-protection-for-ie

voor uw veiligheid: MS logt u ... IE7... - Pagina 2 | hilpers

voor uw veiligheid: MS logt u ... IE7... - Pagina 2 | hilpers — Fri, 23 Jan 2009 15:46:48 GMT

PingBack from http://www.hilpers.nl/55375-voor-uw-veiligheid-ms-logt/2

Sobre Phising | hilpers

Sobre Phising | hilpers — Tue, 20 Jan 2009 22:51:12 GMT

PingBack from http://www.hilpers-esp.com/351767-sobre-phising

IE7 - フィッシング詐欺検出機能

ウィンドウズ開発統括部 — Fri, 12 May 2006 14:58:02 GMT

IE7 - フィッシング詐欺検出機能

Techhash » Blog Archive » First Looks: Internet Explorer 7.0 Beta 2 Preview

Techhash » Blog Archive » First Looks: Internet Explorer 7.0 Beta 2 Preview — Thu, 16 Feb 2006 19:04:36 GMT

PingBack from http://techhash.com/blog/2006/02/01/first-looks-internet-explorer-70-beta-2-preview/

re: New enhancements to Phishing Filter protection for IE

Squire — Sat, 17 Dec 2005 03:41:59 GMT

'2. However if IE filter would stick to reporting centrally something to MS while the users browses, why not merely reporting the SHA-256 of the URL instead of URLs themselves and have the DB be fed with hashes instead of URLs ? '

If you give this 3 seconds of thought, you'll understand that sending a hash to the organization that generates the hashes is pointless. MS will already know what URL a particular hash points to because they'd need to have generated the hash from the URL in the first place. So sending them some cryptic SHA-256 hash is a waste of CPU cycles because it does not solve the "OMG MICROSOFT WILL KNOW WHERE I'M BROWSING!!!!!!!!!!!!!!" paranoia.

Not to mention they have given specific reasons. For example, http://malicious.site/a/ would hash to one value, and http://malicious.site/a/b/ would hash to another value, so now you either a) end up storing hashs of every possible variation of every possible malicious site, or b) you break the URL into pieces and compare hashes of the various pieces.

And as I already said, none of this protects your privacy in any way.

I'm beginning to see the light

Maurits [MSFT] — Thu, 01 Dec 2005 20:10:16 GMT

I'm beginning to see some justifications for the service model where the URL is sent unhashed.

Phisher tricks are common.

Existing tricks are things like wildcard DNS:
Phisher owns bad-site.example.com
Phisher sends out random-string web sites that work because of wildcarded DNS:
random-string-1.bad-site.example.com
another.random.string.bad-site.example.com

Or even simple case mixing:
bAd-sITE.example.COM

Adding a period:
http://bad-site.example.com./

Listening on many nonstandard ports:
http://bad-site.example.com:31337/

Using custom 404 pages:
http://good-site.example.com/bad-folder/random+string+here/

If the service model is kept, then the checking algorithm can be updated to work around these tricks without having to update all the clients... only the server would need to be updated

ways of listing badness

Maurits [MSFT] — Thu, 01 Dec 2005 01:29:34 GMT

So far several more privacy-friendly ways of implementing the bad-site lookup have been suggested:

The hash lookup similar to what Vipul's Razor uses (for Cloudmark) as an anti-spam technique. This works well for email because the "database of known hashes" is necessarily small. It will be somewhat less useful for URLs but still better than the current system.

The push-the-list-to-the-clients similar to what antivirus systems use. I suppose a drawback of this method is that the database could be hacked and the list of bad sites enumerated.

I wonder if the two methods could be combined?

1) Generate a hash for all the bad sites
2) Push the list of hashes to the clients

Then a site owner can easily test their own sites by computing the hash of their site and checking to see if that is listed.

Clients can compute the hash of any URL they're about to visit and check the LOCALLY STORED hash list to see if that hash is suspect.

Microsoft could still have a service which simply responded with the timestamp of the latest version of the list. That would allow the client to know when it was time to update.