Monday, May 07, 2007
LUPH - The Login URL Policy Framework
Is there a better way to fight phishing attacks? A method that allows banks and brands to protect themselves by specifying the correct place for users to enter credentials? Perhaps we could dream up an interoperable means of sharing and updating this information from brand owner to consumer quickly, efficiently and using technology that we already have?
If this sounds interesting read on for my proposal - LUPH. Login URL Policy Framework.
There are a lot of somewhat effective methods for blocking phishing attacks. You've got your browser plugins from Microsoft, Mozilla.org and Netcraft. You also have volunteer tracking and takedown teams like PIRT and PhishTank. There are numerous other anti-virus, anti-spyware and research companies also trying to solve the problem. Recently there have even been proposals to create new TLD's just for banks to allow them "exclusive" rights to these urls and eliminate consumer confusion.
I think that the problem is that we're not asking the right people to fix the problem. The only party that has the requisite knowledge to tell a browsing consumer if they are entering their username and password into the right online form is the bank. Why don't we just ask them what login urls should be allowed for a "brand" and then validate for the browsing consumer that they are on the right page?
This same problem was, and to a large degree still is, prevalent in the SMTP email system. Nobody knows what hosts should really be allowed to send mail on behalf of any given domain. This makes it nearly impossible to block messages fraudulently claiming to be from a legitimate source.
How did we try to solve the problem of forged emails? SPF - Sender Policy Framework. In SPF we ask every domain to specify the IP addresses from which we should allow mail from their domain to be sent. In theory if you receive a piece of mail from a server that is not authorized through SPF it should be rejected outright. In effect this solves the problem of forged email addresses right? Wrong.
In practice SPF has a medicore adoption rate and an even lower block rate. It's too much hassle for most domain owners without any real return on the small investment.
Now let's see how we can make this same concept successful to fight phishing. What was DNS made for? Acting as a distributed database for arbitrary ascii data of course. Don't believe me, check out RFC 1464 http://www.ietf.org/rfc/rfc1464.txt.
So applying this to phishing - we ask every brand owner that would like to be protected against phishing to create a txt record in their DNS zone containing the urls or url stubs that users should use to login to their services. Next we create browser plugins that do perform a DNS lookup every time a user wants to submit login information and check the domain against the valid urls.
Now the clever reader might be asking what happens if the phisher simply registers a domain like paypalisus.com and then creates the correct LUPH records for that domain? Wouldn't the proposed system allow the user to submit credentials to that site? Of course and that's where the secret sauce comes in.
The secret sauce lies in one additional step that the browser would need to enforce. The user would need to identify the brand that they think they are submitting their credentials to. This could be as simple as a list of possible legitimate domain matches based on page content to a pop-up box that would require the user to enter the domain that they think they are on. Once the browser knows where the user **thinks** the credentials are being submitted it can then perform the DNS check to validate the url.
Obviously there are a lot of hurdles that would need to be cleared to make this a viable system. My thinking is that this is a relatively simple, inexpensive and scalable solution that does not require an entirely new infrastructure to support.
Maybe this is the kind of idea that seems really good after you've been awake for 24 hours but turns out to . :)
If this sounds interesting read on for my proposal - LUPH. Login URL Policy Framework.
There are a lot of somewhat effective methods for blocking phishing attacks. You've got your browser plugins from Microsoft, Mozilla.org and Netcraft. You also have volunteer tracking and takedown teams like PIRT and PhishTank. There are numerous other anti-virus, anti-spyware and research companies also trying to solve the problem. Recently there have even been proposals to create new TLD's just for banks to allow them "exclusive" rights to these urls and eliminate consumer confusion.
I think that the problem is that we're not asking the right people to fix the problem. The only party that has the requisite knowledge to tell a browsing consumer if they are entering their username and password into the right online form is the bank. Why don't we just ask them what login urls should be allowed for a "brand" and then validate for the browsing consumer that they are on the right page?
This same problem was, and to a large degree still is, prevalent in the SMTP email system. Nobody knows what hosts should really be allowed to send mail on behalf of any given domain. This makes it nearly impossible to block messages fraudulently claiming to be from a legitimate source.
How did we try to solve the problem of forged emails? SPF - Sender Policy Framework. In SPF we ask every domain to specify the IP addresses from which we should allow mail from their domain to be sent. In theory if you receive a piece of mail from a server that is not authorized through SPF it should be rejected outright. In effect this solves the problem of forged email addresses right? Wrong.
In practice SPF has a medicore adoption rate and an even lower block rate. It's too much hassle for most domain owners without any real return on the small investment.
Now let's see how we can make this same concept successful to fight phishing. What was DNS made for? Acting as a distributed database for arbitrary ascii data of course. Don't believe me, check out RFC 1464 http://www.ietf.org/rfc/rfc1464.txt.
So applying this to phishing - we ask every brand owner that would like to be protected against phishing to create a txt record in their DNS zone containing the urls or url stubs that users should use to login to their services. Next we create browser plugins that do perform a DNS lookup every time a user wants to submit login information and check the domain against the valid urls.
Now the clever reader might be asking what happens if the phisher simply registers a domain like paypalisus.com and then creates the correct LUPH records for that domain? Wouldn't the proposed system allow the user to submit credentials to that site? Of course and that's where the secret sauce comes in.
The secret sauce lies in one additional step that the browser would need to enforce. The user would need to identify the brand that they think they are submitting their credentials to. This could be as simple as a list of possible legitimate domain matches based on page content to a pop-up box that would require the user to enter the domain that they think they are on. Once the browser knows where the user **thinks** the credentials are being submitted it can then perform the DNS check to validate the url.
Obviously there are a lot of hurdles that would need to be cleared to make this a viable system. My thinking is that this is a relatively simple, inexpensive and scalable solution that does not require an entirely new infrastructure to support.
Maybe this is the kind of idea that seems really good after you've been awake for 24 hours but turns out to . :)
Subscribe to Posts [Atom]