[whatwg] meta="encrypt" tag is needed

[Maciej Stachowiak]

On May 8, 2010, at 9:31 AM, Juuso Hukkanen wrote:

>>> In fact, do you know of *any* examples of MITM attacks
>>> being successfully used against a public website?
>> "Pharming" is effectively a man-in-the-middle, and in
>> particular would be 100% effective at defeating the proposed  
>> security feature. http://en.wikipedia.org/wiki/Pharming
>
>
> Good point,
> I agree that *without* external authentication (see  
> auth="verisign"), pharming, poisoned DNS router or various kinds of  
> malicious software on users computer could lead UA into  
> communicating with attackers site or allow MITM to open the
> encryption. But if external authentication service is using the  
> auth="verisign" parameter, practical MITM attacks can be prevented.  
> Someone said auth="verisign" would not suffice. No it doesn't...  
> alone. I wanted the meta-encrypt footpring on pages to be small. So  
> the actual CA company signed sertificate, which confirms  
> pubkey="FAFFFA262662EAEEA" belonging to mydomainZZZ.com would be  
> found from
> https://www.verisign.com/certificates/FAFFFA262662EAEEA.sig AND
> http://www.mydomainZZZ.com/verisign.sig

I have no idea what auth="verisign" is supposed to do, but I think we  
need to rewind this conversation a little.

When designing a security feature, it's important to understand the  
threat model - what kind of attacks it's supposed to defend against,  
and what kind of attacks may be staged against it. Here are some of  
the possible attacks against passwords sent as cleartext over non-SSL  
HTTP:

1) Passive network attacks
     1.a) Password sniffed from network traffic - use on same site.
     1.b) Password sniffed from network traffic - guess that user has  
the same password on another site.

2) Active network attacks
     2.a) IP-level man-in-the-middle attack, possibly alter content to  
obtain passwords.
     2.b) DNS-level man-in-the-middle attack ("Pharming")

3) Active attacks against origin server
     3.a) Break into server to steal password database - use passwords  
on same site.
     3.b) Break into server to steal password database -  guess that  
users have the same password on another site.
     3.c) Break into server and sabotage served content to steal user  
data.

4) Social engineering attacks
     4.a) Phishing
     4.b) Targeted Phishing (aka "Spear Phishing" or "Whaling")

To the best of my knowledge, exclusive use of HTTPS combined with  
Strict Transport Security will defend against all of the listed  
passive and active network attacks, barring a violation of SSL itself.

I'm not aware of a foolproof way to ensure the security of the origin  
server or to defend against social engineering attacks. Storing  
passwords only in a salted and hashed form may partially protect  
against reusing those passwords on another site, but is vulnerable to  
offline dictionary attack. Using a one-time password scheme with a  
physical authentication token is a better defense, but impractical for  
most use cases.

My understanding of the current proposal is that it hashes all  
passwords entered in a form using SHA-256, and optionally salts the  
password with the domain name of the site, as requested by a meta tag.  
Let's look at how it holds up against the various threat models above:

1) Passive network attacks
     1.a) Sniff password to use on same site - COMPLETELY INEFFECTIVE  
- the password hash has no defense against replay attacks.
     1.b) Sniff passwords to use on same site - PARTIALLY EFFECTIVE -  
still vulnerable to offline dictionary attacks.

2) Active network attacks
     2.a) IP-level man-in-the-middle attack - COMPLETELY INEFFECTIVE -  
attacker can modify the page to remove the meta tag.
     2.b) DNS-level man-in-the-middle attack - COMPLETELY INEFFECTIVE  
- attacker can modify the page to remove the meta tag.

3) Active attacks against origin server
     3.a) Break into server to steal password database for same site -  
COMPLETELY INEFFECTIVE - you get hashed passwords you can use directly.
     3.b) Break into server to steal password database for use on  
other sites - MOSTLY INEFFECTIVE - still vulnerable to offline  
dictionary attacks, which will be highly effective against a large  
password database.
     3.c) Break into server and sabotage served content to steal user  
data - COMPLETELY INEFFECTIVE - attacker can modify the page to remove  
the meta tag.

4) Social engineering attacks
     4.a) Phishing - COMPLETELY INEFFECTIVE - phishing attack sites  
wouldn't use the meta tag.
     4.b) Targeted Phishing (aka "Spear Phishing" or "Whaling") - same  
reason as 4.a.

In conclusion, it seems that the proposed mechanism is completely  
ineffective at protecting the site using it, and only marginally  
effective at protecting other sites where users may have used the same  
login info.

I may have misunderstood how the proposed mechanism is supposed to  
work, if so, please provide more detail than the original sketchy  
account.

Regards,
Maciej