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
