Re: [whatwg] meta="encrypt" tag is needed

[Ian Hickson]

On Thu, 6 May 2010, juuso_ht...@tele3d.net wrote:
>
>  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.

What problem is this solving?

Please see the WHATWG FAQ for details on how to propose features:

   
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] meta="encrypt" tag is needed

[Mikko Rantalainen]

Juuso Hukkanen wrote:
> Mikko Rantalainen wrote:
>> Are you trying to suggest an user agent implementation of something
>> similar to this: http://angel.net/~nic/passwdlet.html ?
> Thanks Mikko for linking to those passsalt generator tools.

In truth, I was asking to figure out if that's what you're aiming for.
If I've understood correctly, this is the feature that you think should
be implemented.

I'm afraid that such system would not be safe and would not give all the
protection you're looking for.

Basically if you have a function

f(x) = sha256(domain + userpassword)

in reality you just have a SHA256 of userpassword with a custom IV
(initialization vector). A more secure hashing method would be along the
lines

f2(x) = sha256(sha256(userpassword) + domain)

where the output of sha256 is hex in ascii and "+" is string
concatenating operator. This would effectively prevent use of rainbow
tables contrary to f(x) above.

However, it wouldn't still be safe to use the same password for multiple
sites because the attack could be implemented offline against the salted
hash. If one has possession of database of salted hashes, figuring out a
single password is roughly equivalent processing to figuring out
(almost) all of the passwords. The complexity of processing is only
dependent on the length and complexity of user's password (and if it's
something in a dictionary, it's way too simple here).

Notice that the salting method described and implemented in URL above is
safe only if it's not too widely used, or if the master password is
complex enough for offline brute force attack. As such, it's not
suitable for common implementation in user agents. Notice that it does
not matter if the hash algorithm is md5 or sha1 or whatever. The problem
is that the user's master password is the only secret and that's almost
always too weak secret for brute force offline attack.

> PASSSALT:
> ^^
> Attributes:
>  Identification tag for html 5.01 content for 5.01
> conforming UAs

If something like this will be ever implemented, it should definitely be
a form input specific attribute, not a single meta element for the whole
page.


> passsalt="no|domainname"
> ^^^
> 1) no <=> UAs should send passwords unsalted (e.g. for the sake of
> compatibility)
> 
> 2) yes <=> (default value, 5.01 conforming UAs will salt passwords using
> domain name)
> 
> 3) domainname <=> domain(+TLD), if site wants hashes salted using it's
> current or some another domain name

How about just a simple extension to input type=password field instead?
Let's add a new attribute 'salt' with the following definition:

If 'salt' is defined for input element of type 'password', it will be
used as a string "domain" in the f2() function above. The output of that
function will be transferred as form data instead of real password.

This has all the security of your proposed scheme (because there's no
safety against MitM attack, there's no point to try to include any
external information into the hash -- including the domain name). The
server may use domain name as the salt or any random string it prefers.
If server uses the same salt every time, it does not ever need to know
the actual password. On the other hand, using the same salt makes the
database more vulnerable to offline attack if the database is ever leaked.

However, the server must be coded to accept BOTH salted password and
plain text password to support existing user agents.

It could be specified that entire ascii/UTF-8 (identical) hex encoded
sha256 output must be used as the form value. The length of inputted
password would then be a pretty good indicator of salted and hashed
password.


> Why passsalt in html5.xx specification
> ^^
> 1) multi-use of same passwords is a growing security problem. A
> successfull stealing single sites unencrypted real person names +
> passwords can lead to thousands of ID theft cases.

It is not safe to use the same password on multiple sites, hashed or
not. The only safe method is to use random password for every site and
use (real, not obfuscated) encrypted local storage for real passwords.

I do understand that the secure scheme is hard to implement if you're
using multiple devices to access the service. In addition, it's not
usable or safe on untrusted devices (but neither is any other scheme).

Allowing a scheme suggested here would allow something slightly better
than the current situation but it should be said plain and clear in the
spec that this is not a replacement for real security.

> 2) Voluntary salting of passwords has failed even on reputable sites.

The server must have knowledge of real password to use powerful salt
(that is, the salt is not shared)

> 3) Forcing the passwords salted is one solution. But the UA needs to
> know if it should send password salted or unsalted. Situation where one
> UA would send salted password and another unsalted is unacceptable

Why do you think so? If th

Re: [whatwg] meta="encrypt" tag is needed

[Juuso Hukkanen]

Thanks Mikko for linking to those passsalt generator tools. And thanks
Maciej for that analysis. Good that you at least see some benefit about
the passsalt parameter ;)

Good to know there are already tools that do the for of salting thing  
locally ( http://supergenpass.com/ ) I'd like nothing more than UAs to  
do the same and be guided to do that by HTML5.01.


Ok so I think passsalt is rather simple one, shouldn't have much complications

and as shown below site could choose to demand plain text passwords. Below

are the allowed values for passsalt. Unfortunately you all maybe right

that authenticated stateless active MITM attacks can't be avoided that  
simply -
Damn you Mallory. So that PKI could only protect against *most* cases  
of passive
listeners who the hell want's such, after all there might be some  
academic person next door playing with newest version PKI sniffing  
tools.



To me passalt is the important one. https can take care of  properly  
authenticated

 encryption,... but it sure would be nice if some PKI encryption

could be baked in HTML forms. help your self if you like that too.



How about explaining what those attributes do, WHY would you want
to use those and what are allowed values for each attribute.


PASSSALT:
^^
Attributes:
 Identification tag for html 5.01 content for 5.01  
conforming UAs



passsalt="no|domainname"
^^^
1) no <=> UAs should send passwords unsalted (e.g. for the sake of  
compatibility)


2) yes <=> (default value, 5.01 conforming UAs will salt passwords  
using domain name)


3) domainname <=> domain(+TLD), if site wants hashes salted using it's  
current or some another domain name


4) in all other cases:
a) empty string OR
b) invalid domain name OR
c) passsalt argument is not given at all
   <=> passwords are to be salted with domainname

5) passsalt argument could also be given as an argument of  -tag

how UAs should do the passsalt salting
^
1) read the lowercase utf-8 string of domainname (e.g. mydomain.com)
2) read the users given password
3) calculate sha256(password+domainname)
4) take the first 24 chars of hex output and submit those as password

I have no opinion if HTML5.01 should define a minimum lenght to which salted
passwords would be truncated. Or should the password field lengths be as the
form defines them


Why passsalt in html5.xx specification
^^
1) multi-use of same passwords is a growing security problem. A  
successfull stealing single sites unencrypted real person names +  
passwords can lead to thousands of ID theft cases.

2) Voluntary salting of passwords has failed even on reputable sites.
3) Forcing the passwords salted is one solution. But the UA needs to  
know if it should send password salted or unsalted. Situation where  
one UA would send salted password and another unsalted is unacceptable
4) defining the salting requirement in html5.xx would tell to UAs  
about the sites readiness to accept salted passwords if the page would  
not be marked html5.xx+ (or passsalt="no") UA would send passwords  
unsalted



-

You referred to "alypaa.com" case in your original post. Could you
explain why do you think this would prevent from similar information
leak in the future?



1) Site had stored the it's email addresses and passwords in unsalted format.
And as often is the case, same password had been multi-used on many sites.
If the alypaa.com had only gotten salted passwords from UA, it could not have
leaked out the passwords to peoples email, blog and facebook accounts.

"I did a test around year 2001 when I stumbled upon a small but similar
list (200+) of email addresses and "forgotten passwords". So, I send  
emails to all saying hi email if this is your password change it where  
you use it, because
anyone could find it at the internet. about 70% replied back to me and  
of those about a third said it's a bogus password, only for bogus  
sites. about a third thanked and said to be changing the passwords  
where needed. and about a third were furious and threatening to sue me  
for hacking his/her important password."


2) do you multi-use same passwords? (yes)

3) do you expect all login-requiring internet sites to start using https? (no)

4) do you expect all login-requiring internet sites to start salting  
passwords? (no)



You all had a million good questions, sorry but I will not elaborate anything
anymore as I am already busy and leaving this mailing list now.  
Fortunately, I am sure you all can consider the benefits and risks(?)  
of forcing passwords salted. Nice if that can be somehow applied into  
HTML standard; with or without PKI encryption parameters.


Juuso

Re: [whatwg] meta="encrypt" tag is needed

[And Clover]

On 05/07/2010 07:06 PM, Juuso Hukkanen wrote:


the auth="verisign" argument, which _is_ enough to prevent all practical
(,even if they are all theoretical!,) man-in-the-middle attacks.


No it doesn't. The initial page load stage is by necessity unencrypted, 
and so an active MitM attack could simply remove the tag, or add a JS 
keylogged script to the page, or whatever other method an attacker might 
choose. Unless the user is expected to view source and check every last 
byte of the page and scripts used in it (which will never happen), they 
have no way to know their communications are secure.


In any case, if you add CAs, your proposal becomes just as 'heavy' as 
HTTPS. What advantage does your proposal have over HTTPS, then? Because 
it appears to have many disadvantages.


As for password 'salting', client-side challenge-response authentication 
is already addressed much more securely by Digest Authentication, 
Kerberos, or JS approaches. And if you have HTTPS, it's not really so 
bad to send a plain password to the server, which will hopefully 
hash/salt it itself. You have to send a plain password in order to set 
it in the first place anyway.






Don't do that. That's a basic, beginner-author XSS vulnerability.

--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/

Re: [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

Re: [whatwg] meta="encrypt" tag is needed

[Mikko Rantalainen]

Juuso Hukkanen wrote:
> I was expecting criticism; as is unavoidable with all crypto issues.
> 
> You asked many questions, and unfortunately all you missed the
> auth="verisign" argument, which _is_ enough to prevent all practical
> (,even if they are all theoretical!,) man-in-the-middle attacks.

You keep referring to the source code excerpt you posted. How about
explaining what those attributes do, WHY would you want to use those and
what are allowed values for each attribute.

Also note that because the attribute 'auth="verisign"' is sent without
encryption, it cannot be used for preventing MitM attack. This is
because MitM attacker would be able to strip out that attribute or
replace it with any other value he prefers.

> the above 'page' using the meta-encrypt tag, which is enough for a
> client browser to submit to site
> a) a salted password
> b) and a user name transported in encrypted form; over the internet

I understand that you believe that this is important. Could you explain
to us, why do you think so?

You referred to "alypaa.com" case in your original post. Could you
explain why do you think this would prevent from similar information
leak in the future?

As you haven't explained why your proposed scheme really works, I can
only guess that you intent that the server never gets the original
password, only the salted version. Are you trying to suggest an user
agent implementation of something similar to this:
http://angel.net/~nic/passwdlet.html
?

> I am not suggesting replacing https with anything, government and
> business sites can and should keep on using it.  I am suggesting a small
> easy to use mini-encryption which would be enough for those 90% of sites
> should salt their passwords and encrypt sensitive data and but who
> currently aren't.

What is the attack you're trying to avoid?

> Obviously you people will keep complaining, so what do you want to
> complain next
> 1) Man-in-the-middle problem; which doesn't exists because
> a) those are just academic mind games

Huh?

What is the attack you're trying to avoid? (I'm repeating myself...)

> b) if auth="verisign" is used as external CA

This cannot be used for authentication because it's part of the
non-encrypted and unsigned content. See above.

> 2) HTTPS = good (even if it is typically NOT used with forms

?? (Are you trying to make some point? Please, elaborate.)

> 3) password salting = webmasters duty to do it (which 50% forget), after
> using the HTTPS (which 90% forget)

Is this the problem you're trying to fix? You don't like the fact that
if the server software is able to know your password, it's able to store
it encrypted?

Why do you think your proposed feature would fix this?

> 4) Declaring encrypt action doesn't fit into HTML (; then why is there a
> form method get/post)

?? (Are you trying to make some point? Please, elaborate.)

-- 
Mikko




signature.asc
Description: OpenPGP digital signature

Re: [whatwg] meta="encrypt" tag is needed

[Juuso Hukkanen]

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

As UA can verify the document's verisign signature and therefore  
observe site's certificate & public key being authentic and good for  
use.


I am not saying this meta-encrypt tag would solve *most* security /  
privacy problems. I am just saying it would eliminate some of serious  
ones. Like salting the multi-used passwords that easily facilitate  
identity theft.
For example a valid meta-encrypt tag could look like this:  
i.e. NOTHING no tag at all. Meaning if a html5.01 standard would  
require user agents to, by default, salt the passwords using the  
domain name.

sha256(userpass+domainname);

Then all browsers that confirm to the html5.01 would submit the salted  
passwords. but if target website had for

some (compability) reason a following meta-encrypt-tag

Then a html5.01 conforming browser would submit the password in plain  
text as it was typed


And if a site would e.g. change name and they wanted to use the old  
user-password-DB salted using the previous

domain name, then the meta-encrypt-tag could be just...


And if a site would e.g. change name and they wanted to use the old  
user-password-DB salted using the previous

domain name, then the meta-encrypt-tag could be just...


Thus a html5.01 conforming webpage could choose to use...





That password salting 'security feature' would not be threatened; no  
matter where a rogue DNS or pharming-tool would direct the UA. And as  
always there are still special threats against password salting, e.g.  
physical or software keyloggers. But hey nothing is perfect.


The meta-encrypt tag, the passsalt="" argument alone, would have  
prevented facebook accounts and blogs of some of the leading finnish  
politicians being spied and vandalized - as recently happened after  
alypaa.com was hacked and 100,000+ username+passes were stolen. Ok  
that's all I want to say. Be well.


Juuso Hukkanen
www.colordev.com

Re: [whatwg] meta="encrypt" tag is needed

[Maciej Stachowiak]

On May 7, 2010, at 1:40 PM, Aryeh Gregor wrote:



In fact, do you know of *any* examples of MITM attacks being
successfully used against a public website?  It's not that I doubt
that it's happened, but I don't actually know of any specific cases.
In principle, you should be able to harvest lots of passwords by
dropping some free wireless routers in strategic locations.

(There's still an entirely different fatal problem with what you
quoted, though: if you aren't worried about MITM, then encryption is
pointless to begin with.  I don't dispute your conclusion.  :) )


"Pharming" is effectively a man-in-the-middle, and in particular would  
be 100% effective at defeating the proposed security feature. It is  
extremely common, to the point that it is considered one of the major  
security risks on the Web.


http://en.wikipedia.org/wiki/Pharming

Regards,
Maciej

Re: [whatwg] meta="encrypt" tag is needed

[Juuso Hukkanen]

On Thu, May 6, 2010 at 8:44 AM,   wrote:



Good observations Frank & Ash & Aryeh & others,


I see a few shortcomings in this approach:
a) each document is encrypted asymmetrically, affecting performance.

1) yes, that's partially true. What is asymmetrically encrypted is
the keys to symmetrical encryption; which is much faster

2) no, that is not required. if user agent stores the AES password
   e.g. inside a session cookie, "beyond the login page" the web-pages
   can have meta-encrypt-tag pubtool="cookie-AES".
   ==> thus when UA requests page, server requests a cookie named
according to meta-encrypt pubkey="_value_".
   ==> that cookie named _value_ contains the symmetrical AES key
   ==> so, server sees the UA has a proper pubkey
   ==> server encrypts the page using symmetrical AES and sends it to UA

3) no, that's not required for the passsalt="no|domainname" argument.
   salting happens only in UAs, passsalt argument is a hint to browser
   to hash the password field before submitting it to server. server
   would treat the salted password as any normal 'properly randomized'
   password.



b) there is no management of keys (expiration, revocation, trust, etc).

1) IF auth is used, CA can validate pubkey belonging to site until xx/yy/
   Browser can remember authentication and store
   'SHA256(domainname)','pubkey','validuntil'
2) IF external auth is not used site can generate it's own key pair ,  
using some
   w3c? accepted / authenticated key generator tool, and the  
webmaster then just
   puts the public key into meta-encrypt tag and the private key  
into... server

   accessable location maybe .htpasswd file
3) ...so Dear Watsons... as the browser sees the meta-encrypt tag it (*may* be
   configured) to contact CA and validate the pubkey belonging to site using
   all the formal https validation techniques... What is left to the webmaster
   is to insert a simple meta-encrypt tag


c) the values for the pubtool attribute (encryption algorithm) will need to

be spec'd, slowing the deployment of new encryption algorithms (or better
techniques altogether).
1) yes, that's true, some specsing is needed as there are competing  
PKI technologies, with small key sizes, elliptic curves good  
candidates as they are well studied and at least to sufficient degree  
patent free. Initial specsing has also been done e.g. by "the OpenSSL  
team accepted an ECC patch in 2005", Also NSA may provide helpful  
'ideas'

http://en.wikipedia.org/wiki/ECC_patents
http://www.nsa.gov/business/programs/elliptic_curve.shtml


d) how to handle XMLHttpRequests? how to handle XHRs receiving JSON or text?

1) I'm sure you'll find a solution ;)


e) information from the UA to the server is plaintext (e.g.,

logon/passwords).  If, instead, authentication relies only on possession of
the user's private key; then, any human can sit at the user's console and
automatically authenticate to all HTTP servers.
1) 'meta-encrypt'- tag encrypts only from UA -> server. IF there is a
meta-encrypt tag on a requested page, UA encrypts URI-request the form
parameters it sends to server using the pubkey="" public key


2)  submits the browser's own pubkey to the server inside
   each page-request to the server. the 'UA-encrypt' field may be valid only
   for a session. if a page has a 'meta-encrypt'-tag and a browser has
   a 'UA-encrypt'-field, the server
+) can generate a AES256 key and encrypt the page using it
+) return the requested AES256 _encrypted_ page to UA, but the  
pages first line is a PKI encrypted message containing the AES256 key  
that opens the 'page'

+) UA notices the BEGIN-ENC-MESSAGE..END-ENC-MESSAGE on the first line
+) UA tries it's own session private key to ENC-MESSAGE, opens  
the message,

   reads the AES256 key
+) UA opens the page using the AES256, and shows the page content  
as any web page


3)  UA gets all page content in from requested URL in fully encrypted  
form server gets all the POST/GET parameters (from UA) to the page in  
fully encrypted form


4)  if page had a passsalt="no|domainname" form-field with or without  
the 'meta-encrypt'-tag, UA hashes the password field with SHA256 and  
submits the SHA256(password+domainname) to the server instead of plain  
text password.




I'd prefer a radically different approach (TLS = out of scope).


There certainly are many technically excellent solutions. My approach  
just focuses in and can

a) make it maximally easy and usable for 'typical' webmasters to use
b) and force the passwords salted; thus preemptively preventing id-thefts


Ash,

You're quite right, what I am suggesting is a server module which may  
be on/off.
- if the meta-encrypt module is off, server module doesn't read the  
page before submitting it.
- if the meta-encrypt module is off, the UA still sees e.g. encrypt passsalt="no|domainname"/> and the UA can salt the  
form-password field

- if the meta-e

Re: [whatwg] meta="encrypt" tag is needed

[Ashley Sheridan]

On Fri, 2010-05-07 at 16:40 -0400, Aryeh Gregor wrote:

> On Fri, May 7, 2010 at 4:21 PM, Tab Atkins Jr.  wrote:
> > On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen  
> > wrote:
> >> 1) Man-in-the-middle problem; which doesn't exists because
> >>a) those are just academic mind games
> >
> > You don't get to talk about security anymore.
> 
> I don't think "academic" is an *entirely* unfair characterization of
> MITM on the web, actually.  MITM is hard enough to pull off on the
> open web that unless you're a bank or PayPal or something, it's
> unlikely anyone would bother.  In practice, most web developers don't
> have to worry about MITM.  By contrast, something like XSS or SQL
> injection is often so easy to exploit when it exists that any site is
> at risk, from botnet operators targeting their outdated software or
> from script kiddies feeling bored or spiteful.
> 
> In fact, do you know of *any* examples of MITM attacks being
> successfully used against a public website?  It's not that I doubt
> that it's happened, but I don't actually know of any specific cases.
> In principle, you should be able to harvest lots of passwords by
> dropping some free wireless routers in strategic locations.
> 
> (There's still an entirely different fatal problem with what you
> quoted, though: if you aren't worried about MITM, then encryption is
> pointless to begin with.  I don't dispute your conclusion.  :) )


http://xkcd.com/341/

Maybe not exactly what you had in mind, but it is a man-in-the-middle in
a sort of sense.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] meta="encrypt" tag is needed

[Aryeh Gregor]

On Fri, May 7, 2010 at 4:21 PM, Tab Atkins Jr.  wrote:
> On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen  
> wrote:
>> 1) Man-in-the-middle problem; which doesn't exists because
>>        a) those are just academic mind games
>
> You don't get to talk about security anymore.

I don't think "academic" is an *entirely* unfair characterization of
MITM on the web, actually.  MITM is hard enough to pull off on the
open web that unless you're a bank or PayPal or something, it's
unlikely anyone would bother.  In practice, most web developers don't
have to worry about MITM.  By contrast, something like XSS or SQL
injection is often so easy to exploit when it exists that any site is
at risk, from botnet operators targeting their outdated software or
from script kiddies feeling bored or spiteful.

In fact, do you know of *any* examples of MITM attacks being
successfully used against a public website?  It's not that I doubt
that it's happened, but I don't actually know of any specific cases.
In principle, you should be able to harvest lots of passwords by
dropping some free wireless routers in strategic locations.

(There's still an entirely different fatal problem with what you
quoted, though: if you aren't worried about MITM, then encryption is
pointless to begin with.  I don't dispute your conclusion.  :) )

Re: [whatwg] meta="encrypt" tag is needed

[Ashley Sheridan]

On Fri, 2010-05-07 at 13:21 -0700, Tab Atkins Jr. wrote:

> On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen  
> wrote:
> > 1) Man-in-the-middle problem; which doesn't exists because
> >a) those are just academic mind games
> 
> You don't get to talk about security anymore.
> 
> ~TJ


+1

You only have to read a few XKCD comics to realise that
man-in-the-middle attacks are pretty easy to pull off!

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] meta="encrypt" tag is needed

[Tab Atkins Jr.]

On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen  wrote:
> 1) Man-in-the-middle problem; which doesn't exists because
>        a) those are just academic mind games

You don't get to talk about security anymore.

~TJ

Re: [whatwg] meta="encrypt" tag is needed

[Aryeh Gregor]

On Fri, May 7, 2010 at 1:06 PM, Juuso Hukkanen  wrote:
> You asked many questions, and unfortunately all you missed the
> auth="verisign" argument, which _is_ enough to prevent all practical (,even
> if they are all theoretical!,) man-in-the-middle attacks.

You haven't explained what it does.  Did you mean that the  tag
should include a certificate as well as a public key?  If so, how is
that better than HTTPS?

> Maybe someone can show a _complete_ alternative Javascript & https solution
> about how those can be achieved in a computer or PDA-device without
> javascript support.

Just serve the page using HTTPS, and have a normal HTML form.  It will
transmit the username, and the password.  The server can  salt and
hash the password.  (You could also easily have the client salt and
hash the password using JavaScript before submission, but this doesn't
improve security once you're using HTTPS.)

> I am not suggesting replacing https with anything, government and business
> sites can and should keep on using it.  I am suggesting a small easy to use
> mini-encryption which would be enough for those 90% of sites should salt
> their passwords and encrypt sensitive data and but who currently aren't.

It is not sufficient, because it's trivially circumventable by a
man-in-the-middle attack.  It therefore provides no security against
any attacker.  It also provides no greater assurance of security on
the server side, because anyone who's competent enough to include this
meta tag will probably also be competent enough to hash and salt
passwords on their own.

> Most servers are already configured to read the requested pages before
> submitting those over the internet.

I'm not aware of any HTTP server that attempts to parse outgoing HTML
content.  Could you provide a specific example?  In particular, I'm
rather certain that neither Apache, nor IIS, nor lighttpd parse
outgoing HTML pages, and that accounts for most servers already.

> For example my above form-page has a
> small php-script inside which the server program must notice; as the
> PHP-program needs to compile the script. Client never sees the  $_SERVER['PHP_SELF']; ?> part but is instead shown an URL. To implement
> meta-encrypt tag would just require (on/off) configuring server program to
> read the header of requested page and see if there is a meta-encrypt tag in
> there the server calls a program which decrypts! the client submitted data.

This requires HTTP servers to implement an HTML parser, and to run it
every time a page is submitted.  They don't actually do this right
now.  HTML parsing is actually very complicated and slow -- have you
looked at the HTML parsing algorithm
?

> 1) Man-in-the-middle problem; which doesn't exists because
>        a) those are just academic mind games

If so, there's no reason for encryption at all.  You can just send the
content unencrypted if no one is going to intercept it.

>        b) if auth="verisign" is used as external CA

Saying who the CA is is not enough to certify it.  You need to provide
the actual certificate, e.g., in X.509 format
.  To get a certificate, you will
typically have to pay a CA some sum of money, making it prohibitive
for casual sites.  What's the advantage over HTTPS at this point?

> 2) HTTPS = good (even if it is typically NOT used with forms

Many sites use HTTPS for everything, including login.  Most sites
don't, but that's mainly because 1) it's hard to get a certificate
(you don't solve this), and 2) it doesn't work well with shared
hosting (there are better solutions to this in progress).

> 3) password salting = webmasters duty to do it (which 50% forget), after

Then why will they remember to add the  tag you suggest?
They'll just forget both.  This is a problem, but the only solution is
to have the browser act more securely by default, regardless of what
the webmaster does.

> 4) Declaring encrypt action doesn't fit into HTML (; then why is there a
> form method get/post)

HTML is the wrong place to do encryption, because once you receive the
page, it might have already been tampered with.  The entire connection
needs to be specified as secure-only from the beginning, such that the
client will abort if it receives unencrypted/unauthenticated content.
This is what HTTPS does.  By the time you get to the actual contents
of the document, it's impossible to know whether it's been secured.


You haven't explained yourself very clearly, but in summary, this is
what I think you're trying to do and why it doesn't work:

1) You're trying to provide protection against MITM attacks that's
easier to use than HTTPS.  This fails, because a) you still need a
certificate (the most annoying part of HTTPS), and b) an MITM could
just alter the outgoing HTTP request to remove the encryption request,
get the plaintext reply, and encrypt that itself, with the client none
the wiser

Re: [whatwg] meta="encrypt" tag is needed

[Ashley Sheridan]

On Fri, 2010-05-07 at 17:06 +, Juuso Hukkanen wrote:

> answer 1:
> Most servers are already configured to read the requested pages
> before  
> submitting those over the internet.

What do you base this on? I can't say I've ever seen a server set up to
parse HTML content

> For example my above form-page has  
> a small php-script inside which the server program must notice; as
> the  
> PHP-program needs to compile the script. Client never sees the  echo $_SERVER['PHP_SELF']; ?> part but is instead shown an URL.

PHP is a server language, parsed by the PHP program not the server
software (i.e. Apache or IIS) and as such, only parse PHP code within
PHP tags, not the HTML.

> To  
> implement meta-encrypt tag would just require (on/off) configuring  
> server program to read the header of requested page and see if there  
> is a meta-encrypt tag in there the server calls a program which  
> decrypts! the client submitted data.


What you're suggesting is that web servers be set up to parse HTML
pages, or an extra server module (like PHP) to parse HTML content. Not
only would this impact on the speed of some sites, but it's likely going
to be harder to convince web hosting companies to update their web
server software than it is to convince offices to upgrade a browser (and
anyone who's ever worked in an office will know how hard it is to get
updates and new software installed)

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] meta="encrypt" tag is needed

[Juuso Hukkanen]

I was expecting criticism; as is unavoidable with all crypto issues.

You asked many questions, and unfortunately all you missed the  
auth="verisign" argument, which _is_ enough to prevent all practical  
(,even if they are all theoretical!,) man-in-the-middle attacks.




  passsalt="colordev.com" auth="verisign"/>



  
  Username: 
  Password: 

  



the above 'page' using the meta-encrypt tag, which is enough for a  
client browser to submit to site

a) a salted password
b) and a user name transported in encrypted form; over the internet

Maybe someone can show a _complete_ alternative Javascript & https  
solution about how those can be achieved in a computer or PDA-device  
without javascript support.


I am not suggesting replacing https with anything, government and  
business sites can and should keep on using it.  I am suggesting a  
small easy to use mini-encryption which would be enough for those 90%  
of sites should salt their passwords and encrypt sensitive data and  
but who currently aren't.


question 1:

The server has to read and correctly parse each HTML page to decide
whether to encrypt it? (And how does the browser know that the page is
encrypted, vs. a legacy server that doesn't encrypt?)


answer 1:
Most servers are already configured to read the requested pages before  
submitting those over the internet. For example my above form-page has  
a small php-script inside which the server program must notice; as the  
PHP-program needs to compile the script. Client never sees the echo $_SERVER['PHP_SELF']; ?> part but is instead shown an URL. To  
implement meta-encrypt tag would just require (on/off) configuring  
server program to read the header of requested page and see if there  
is a meta-encrypt tag in there the server calls a program which  
decrypts! the client submitted data.


Obviously you people will keep complaining, so what do you want to  
complain next

1) Man-in-the-middle problem; which doesn't exists because
a) those are just academic mind games
b) if auth="verisign" is used as external CA
2) HTTPS = good (even if it is typically NOT used with forms
3) password salting = webmasters duty to do it (which 50% forget),  
after using the HTTPS (which 90% forget)
4) Declaring encrypt action doesn't fit into HTML (; then why is there  
a form method get/post)



Juuso Hukkanen
www.colordev.com

Re: [whatwg] meta="encrypt" tag is needed

[Frank Migacz]

On Thu, May 6, 2010 at 8:44 AM,   wrote:
>  passsalt="no|domainname" auth="verisign">
>

I see a few shortcomings in this approach:
a) each document is encrypted asymmetrically, affecting performance.
b) there is no management of keys (expiration, revocation, trust, etc).
c) the values for the pubtool attribute (encryption algorithm) will need to
be spec'd, slowing the deployment of new encryption algorithms (or better
techniques altogether).
d) how to handle XMLHttpRequests? how to handle XHRs receiving JSON or text?
e) information from the UA to the server is plaintext (e.g.,
logon/passwords).  If, instead, authentication relies only on possession of
the user's private key; then, any human can sit at the user's console and
automatically authenticate to all HTTP servers.

I'd prefer a radically different approach (TLS = out of scope).

Frank Migacz
Technical Instructor

Re: [whatwg] meta="encrypt" tag is needed

[Aryeh Gregor]

On Thu, May 6, 2010 at 8:44 AM,   wrote:
>  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
 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.

Re: [whatwg] meta="encrypt" tag is needed

[Schalk Neethling]

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.

Schalk

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of And Clover
Sent: Thursday, May 06, 2010 9:52 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] meta="encrypt" tag is needed

On 05/06/2010 02:44 PM, juuso_ht...@tele3d.net wrote:

> 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

The server has to read and correctly parse each HTML page to decide whether to 
encrypt it? (And how does the browser know that the page is encrypted, vs. a 
legacy server that doesn't encrypt?)

This proposal is tackling the problem of encryption at entirely the wrong 
level: it's nothing to do with HTML, it's to do with the connection between the 
browser and the server. It is very likely that sites would want to encrypt 
transfers of other files than HTML pages. 
This is something that should be tackled at the HTTP level, not in HTML5.

And lo, there is already a quite suitable mechanism for deploying encryption 
between the server and browser: HTTPS.

Whilst it is true that HTTPS has more organisational overhead in the form of 
CAs, and more server overhead in the form of making virtual hosting difficult, 
there are technical approaches to improve this situation (DNSSEC-based certs, 
SNI), and, notably, this overhead is *necessary*.

Otherwise HTTPS would be vulnerable to active man-in-the-middle attacks, just 
like your proposed protocol is. Without attestation that the site receiving the 
`pubkey` token is who it says it is, the encryption between the two is 
worthless. It would only protect against passive MitM attacks, but in reality 
if you are in a position to MitM passively you are very likely to be able to 
throw in an active attack just as easily.

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

HTTPS works fine. JS client-side-password-hashing approaches suffer from the 
same problem as your proposal: they can only ever protect against passive 
attacks.

--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/

Re: [whatwg] meta="encrypt" tag is needed

[And Clover]

On 05/06/2010 02:44 PM, juuso_ht...@tele3d.net wrote:


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


The server has to read and correctly parse each HTML page to decide 
whether to encrypt it? (And how does the browser know that the page is 
encrypted, vs. a legacy server that doesn't encrypt?)


This proposal is tackling the problem of encryption at entirely the 
wrong level: it's nothing to do with HTML, it's to do with the 
connection between the browser and the server. It is very likely that 
sites would want to encrypt transfers of other files than HTML pages. 
This is something that should be tackled at the HTTP level, not in HTML5.


And lo, there is already a quite suitable mechanism for deploying 
encryption between the server and browser: HTTPS.


Whilst it is true that HTTPS has more organisational overhead in the 
form of CAs, and more server overhead in the form of making virtual 
hosting difficult, there are technical approaches to improve this 
situation (DNSSEC-based certs, SNI), and, notably, this overhead is 
*necessary*.


Otherwise HTTPS would be vulnerable to active man-in-the-middle attacks, 
just like your proposed protocol is. Without attestation that the site 
receiving the `pubkey` token is who it says it is, the encryption 
between the two is worthless. It would only protect against passive MitM 
attacks, but in reality if you are in a position to MitM passively you 
are very likely to be able to throw in an active attack just as easily.



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


HTTPS works fine. JS client-side-password-hashing approaches suffer from 
the same problem as your proposal: they can only ever protect against 
passive attacks.


--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/

Re: [whatwg] meta="encrypt" tag is needed

[Tab Atkins Jr.]

On Thu, May 6, 2010 at 5:44 AM,   wrote:
>  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.

Rather than ask us to figure it out ourselves, and possibly get it
wrong and have to be corrected, why don't you just tell us:

1) What the exact problem is you're trying to solve
2) What your suggestion is
3) How your suggestion solves the problem
4) How it is better than existing solutions to that problem

It's generally a much better use of my time to read something that's
well-thought out and explained than to try and decipher a clever idea
that someone had but doesn't want to fully explain.

~TJ

[whatwg] meta="encrypt" tag is needed

[juuso_html5]

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.


yes, this suggestion maybe a bit radical, so lets try to find the  
positive things first. Meaning if you don't understand or like the  
structure immediately shut up and let those who see the light to  
express themselves first.


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.

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.
2) Couple of weeks ago a Russian hacker was selling his user names &  
passwords for 1.5 million Facebook accounts.
3) a week ago a new data protection law for Massachusetts was  
suggested, basically it says personally identifiable information (that  
is usable for identity theft crimes) about Massachusetts residents may  
not be stolen or _you_ will get a fine of $5,000 per breach or lost  
record.


http://www.mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf

It can be expected that the laws around the world will be going to  
that direction as the identity theft problem keeps getting worse. That  
passsalt attribute alone would eliminate LOTS of identity thefts and  
it is easily doable.


Ok, try to hack the rest of that *beautiful* please don't say you instead you can use https / JS or some other  
thing that JUST DOESN'T WORK in real life.


Juuso Hukkanen
www.colordev.com