[whatwg] meta="encrypt" tag is needed

[Aryeh Gregor]

On Thu, May 6, 2010 at 8:44 AM,  <juuso_html5 at tele3d.net> wrote:
> <meta="encrypt" pubkey="ABABAEFEF2626EFEFEF" pubtool="EC256-AES|RSA2048-AES"
> passsalt="no|domainname" auth="verisign">
>
> Please try to fully decrypt the above meta-encrypt tag and *see* how the
> browser-server communication could utilize it. (HINT: browser submits a
> (session specific) 256bit elliptic curve public key to the server inside
> every URI-request AND if the target page has meta-encrypt tag, the server
> uses the  browser's elliptic curve key and encrypts the page content with
> that.) It is very simple, doable and STATELESS. And in html5 it would
> eliminate some of the biggest real life security threats at the internet. If
> you *could* learn and instinctly use the above meta-encrypt tag then it
> should be enough simple for actual usage.

To expand on the threat scenario And referred to: suppose I'm in a
position to tamper with your traffic.  For instance, I might have set
up a malicious free Wi-Fi hotspot that you're using (maybe even you
don't know you're using it).  So you submit your public key . . . then
I record the public key, alter your message to contain my own public
key, and send that.  The server returns the message encrypted with my
public key.  I decrypt it with my private key, re-encrypt it with your
public key, and send it back to you.  I'm reading all your messages
and you have no way to detect or prevent that.

Authentication is a necessary component of any usable public-key
encryption scheme for this reason.  If I can eavesdrop, I can very
likely tamper with the traffic too.

> Ok, let me start with the passsalt:
>
> passsalt => salts the password-field value into => SHA-256($password) format
>
> I think the passsalt="(no|domainname)" attribute should also be added as a
> form parameter (with a default value lowercase domain name). Passsalt
> attribute would prevent the site getting a plain text password as the
> browser would 'salt' it by default with a domain name string. Thus when
> internet users anyway
> use the same passwords on multiple sites, the passsalt will eliminate
> hacking into various online accounts user has.

A decently-written site should be doing this already on the server
side.  If the site isn't decently written, it probably won't use this
meta tag either, so what's the point?  Again, this doesn't hide
anything from a man-in-the-middle, because the attacker could just
remove the meta tag before passing the page on to you.

> Real life examples & reasons for adding passsalt to html5
> 1) A finnish site alypaa.com got hacked a month ago. The hacker stole some
> 100,000 (unencrypted) user passwords from their database. But what media
> noticed first were that many leading politicians had got their blogs, home
> pages and Facebook pages defaced.

If the site didn't hash its passwords in the database, why would it
use your meta tag?  The authors of the web app are obviously clueless
about security, after all.  This has to be done unconditionally on the
browser side to be useful, in which case HTML is irrelevant.  Indeed,
there are plenty of password managers that will autogenerate random
passwords for you for each site, solving this problem.

> 2) Couple of weeks ago a Russian hacker was selling his user names &
> passwords for 1.5 million Facebook accounts.

Doesn't tell us anything unless we know how he got them.  If they're
legitimate, he probably just got them via keyloggers, not
network-based attacks.

> That passsalt
> attribute alone would eliminate LOTS of identity thefts and it is easily
> doable.

No, it wouldn't.  The web page authors who would know enough to use it
are already protected against that kind of attack, by storing only
salted password hashes in the database.

> and please
> don't say you instead you can use https / JS or some other thing that JUST
> DOESN'T WORK in real life.

Well, HTTPS is too cumbersome to be deployed on most websites, yes.
Unlike your proposal, though, it has the advantage of actually
providing meaningful security.  :)  Your proposal really doesn't
improve anything.  If HTTPS had better (free) key certification and
played nicely with virtual hosts, it would be pretty much ideal except
for the performance hit, which is inevitable to some extent.  But if
SPDY gets deployed and only works over SSL, even that might be negated
for most users.

What particular parts of HTTPS do you object to?

On Thu, May 6, 2010 at 4:50 PM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Might be a wrong assumption but, if you place those values into an HTML element, it is visible by simply doing a view source. I am jumping in the middle of the conversation here but, this strikes me as opening another problem.

That's not a problem.  Public keys are expected to be available to
everyone in the world.