FAQ Topic - How can I prevent access to a web page by using javascript? (2010-05-09)

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - How can I prevent access to a web page by
using javascript?
-----------------------------------------------------------------------

In practice you can't. While you could create a suitable
encryption system with a password in the page, the level of
support you need to do this means it's always simpler to do it
server-side. Anything that "protects" a page
other than the current one is definitely flawed.


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

 

[nick]

Anything that "protects" a page
other than the current one is definitely flawed.

The current what? Page? That sounds a little confusing.

Would something like this capture the intended meaning better?

'Any attempt to restrict access to a page using client-side scripting
is definitely flawed.'

 

[Garrett Smith]

-----------------------------------------------------------------------
FAQ Topic - How can I prevent access to a web page by
using javascript?
-----------------------------------------------------------------------

In practice you can't. While you could create a suitable
encryption system with a password in the page, the level of
support you need to do this means it's always simpler to do it
server-side. Anything that "protects" a page
other than the current one is definitely flawed.

I actually don't know what "level of support" means here.

Can the answer be shortened to:

| You can't. Access to a page can be restricted by requiring user
| authentication on the server.

?

 

[nick]

FAQ server wrote:

-----------------------------------------------------------------------

I actually don't know what "level of support" means here.

Yeah, the whole thing is awkward isn't it.

Can the answer be shortened to:

| You can't. Access to a page can be restricted by requiring user
| authentication on the server.

Maybe throw in a paragraph mentioning HTTP Digest Authentication and
the optional 'user' and 'password' parameters for XHR.open (and a
warning not to do that over a non-encrypted connection) for readers
looking for something "ajaxy?"

 

[David Mark]

Yeah, the whole thing is awkward isn't it.

Yes, the explanation itself is definitely flawed. I couldn't make heads
or tails of it.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Sat, 8 May 2010 22:22:54, Garrett Smith

I actually don't know what "level of support" means here.

Can the answer be shortened to:

| You can't. Access to a page can be restricted by requiring user
| authentication on the server.

No.

Firstly, the meaning of "access" must be clarified.

If the page is accessible at all, nothing purely client-side can prevent
someone who wants to see the content from reading it, as served.

At the other extreme, there's a significant proportion of authors who
firmly believe that the code of a page can ONLY be revealed using the
right-click menu. They are wrong; but disabling that menu will prevent
any of them seeing the code of a page.

Now consider a page consisting of two frames. One contains an ordinary
"enter password" box, ten characters wide but accepting many more. The
other frame contains the "meat" of the page, but in a hidden DIV encoded
to the author's private key. To reveal the "meat", one needs the
corresponding public key, which goes (in Hex, reversed) into the
password box. Entering the "password" causes the encoded material be
decoded by said public key and revealed on another DIV. And add a bit
of distracting material in each page.

 

[Thomas 'PointedEars' Lahn]

I actually don't know what "level of support" means here.

Can the answer be shortened to:

| You can't. Access to a page can be restricted by requiring user
| authentication on the server.

?

No. That would imply "javascript" would be client-side only, especially
that it could not be used server-side for user authentication.


PointedEars

 

[Ry Nohryb]

In comp.lang.javascript message <[email protected]
september.org>, Sat, 8 May 2010 22:22:54, Garrett Smith
<[email protected]> posted:









No.

Firstly, the meaning of "access" must be clarified.

If the page is accessible at all, nothing purely client-side can prevent
someone who wants to see the content from reading it, as served.

At the other extreme, there's a significant proportion of authors who
firmly believe that the code of a page can ONLY be revealed using the
right-click menu.  They are wrong; but disabling that menu will prevent
any of them seeing the code of a page.

Now consider a page consisting of two frames.  One contains an ordinary
"enter password" box, ten characters wide but accepting many more.  The
other frame contains the "meat" of the page, but in a hidden DIV encoded
to the author's private key.  To reveal the "meat", one needs the
corresponding public key, which goes (in Hex, reversed) into the
password box.  Entering the "password" causes the encoded material be
decoded by said public key and revealed on another DIV.  And add a bit
of distracting material in each page.

That's very interesting for the user's password doesn't travel through
the net. The problem is that the decryption logic is exposed as source
code in a JS function, and giving that plus the encrypted payload is
giving too much to a decided cracker.

 

[Ry Nohryb]

Ry Nohryb :


Not if the encryption used is any good. Security through obscurity
has long fallen out of fashion, all serious encryption schemes assume
that the enemy knows every detail of the algorithm. The secret is in
the key, and only in the key.

Good point.
So it would be just as secure as the pwd, right ?
Say I use AES and the pwd is 98Gh654f6z3sd, how safe/difficult to
crack would that be, in your opinion ?

 

[Ry Nohryb]

Ry Nohryb :

Save a most improbable weakness in AES, yes.


Assuming the password has been chosen in a suitably random manner,
say, by random choice of the 62 English alphanumeric characters, with
a length of 13... safe enough for any reasonable purpose Overkill,
actually. Unless your secret is worth millions of dollars to state
or corporate security services, 10 characters should be enough.

Great. That's awesome. Let's see if I got it right: if I use the chars
a..z, A..Z, 0..9 in the password, with 10 chars I get like
(31+31+10)^10 combinations (3.7e18), If I could test by the brute
force 1e6 keys per second, I would need 3743906242624s ===
62398437377m === 1039973956h= 43332248 days === 118718 years.Is that
correct ? Is this why you say that 10 chars is safe enough ?

(Incidentally, if it *is* worth millions of dollars, the "million
dollar attack" is likely to be more efficient than any attempt of
cracking : "One million dollars on your account in the Cayman Islands
if you give us the secret".)

LOL.

Thanks,

 

[Dr J R Stockton]

In comp.lang.javascript message <aOmdnWj-Up_v_nTWnZ2dnUVZ8r1i4p2d@gigane

Dr J R Stockton :


Assuming the standard vocabulary of public-key cryptology, if anything
is *encrypted* with the author's *private* key, it may be *decrypted*
with his *public* key. Which, as its name implies, is publicly
available to anyone.

In other words, that encryption is worthless from the point of view
of secrecy, but it provides a strong evidence of authenticity, which
is why one does that sort of things. In order to ensure secrecy, what
one does is to *encrypt* according to the *recipient's* *public* key.


If that key is indeed public, the assumption is that one has it.

On the other hand, your scheme seems to be quite workable using
symmetric encryption and relying on other, secure means to transmit
shared secret keys. E.g., the "meat" is encoded in AES and base64-ed.
There are reasonable implementations of AES in javascript, fast enough
for a few kilobytes of web page content. For example, here :
http://www.movable-type.co.uk/scripts/aes.html

Being able to remember the terminology correctly gives you a
considerable advantage.


This entry exemplifies a running problem with the FAQ; it grew in the
past by adding (to a first approximation) the actual answers to actual
questions, with the actual Subject lines. The original questions would
have included more text, often clarifying the OP's need; and the
selected answer probably fulfilled that need.

To be generally useful and reliable, however, a FAQ answer must be
adjusted to accommodate all reasonable interpretations of the Subject,
the Subject having first been adjusted to be clear and worth answering.

 

[Garrett Smith]

No. That would imply "javascript" would be client-side only, especially
that it could not be used server-side for user authentication.

The answer presumes that the question is about javascript running on the
client because it says that you can't and it is simpler to do it server
side.

I am wide open for suggestions on this entry. Neither the question nor
the answer are clear. Perhaps:

| FAQ Topic - How can I prevent access to resources in the browser?
|
| You can't. Scripts that attempt to password protect resources do not
| provide any real security.
|
| Access to resources can be restricted by requiring authentication on
| the server.

 

[Ry Nohryb]

Garrett Smith :


I have to disagree. It is quite possible to encrypt the body element
of a web page using, e.g., AES, (...)

For Smith the FAQ guardian the probability of (to read && !to
comprehend) is almost 1.

Maybe next year.

 

[Bwig Zomberi]

Garrett Smith :



I have to disagree. It is quite possible to encrypt the body element
of a web page using, e.g., AES, store the encrypted value either in an
Array of Numbers or as a base64-encoded String, present a provisional
body element that requests a password, decrypt the encrypted body
with the provided password, check that the result makes sense (that
it starts with '<body', perhaps), and if so, replace the previous
body with the decrypted value.
The level of protection is essentially dependent on the strength of
the password, and can be made as strong as one may wish.

I'm not sure that it would have any significant advantage over
classic, server-side solutions, but it is definitely possible.

Sending the password (encrypted or otherwise) to the client is simply a
wrong approach to security.

 

[Ry Nohryb]

Sending the password (encrypted or otherwise) to the client is simply a
wrong approach to security.

The pwd never ever travels through the net, it's entered by the user
of the page, and never ever leaves the client, it's just used to
decrypt the payload and then can be destroyed.

 

[Ry Nohryb]

Ry Nohryb :


I have to disagree with that too.

You'll end up agreeing.

Anyway, here is a quick and dirty proof of concept :http://baagoe.com/en/ES/encrypted.html

I shall leave the group enough time to attempt to prove that it does
not "provide any real security", and then publish the password.


Maybe an hour or two will be enough, if it is acknowledged that the
security seems to be adequate after all

$1k? :-D

I'd like to try a brute force attack with a bookmarklet and
webworkers, but, for that, could you please add there if you don't
mind, in that same page, another "secret" that uses a short pwd (say 3
or 4 chars no more) that only contains a..z, A..Z and 0..9 ? It's
just an experiment...

 

[Bwig Zomberi]

Ry Nohryb :


On the other hand, if the client is the human being who pays for the
service, I fail to see why sending her the password via gpg poses
a great security risk.

By "the encrypted value either in an Array of Numbers or as a
base64-encoded String" I thought you meant the password. I realize you
are suggesting key-pair technology, which means the password need not be
stored with the encrypted container. A neat solution. >

For adequate logging, you might add that a XHR is made to the server
after successful decryption.

 

[Bwig Zomberi]

Bwig Zomberi :



Dr Stockton's idea, actually. I hadn't thought of it before. I am not
sure it is useful, either...

Quite. It is only a proof of concept, and if it is ever to serve
a useful purpose, there is a lot to add and to tidy.

But it refutes the categorical statement of the FAQ.

So, the FAQ should say that while it is possible to do it on the
client-side (browser), it is not the recommended way. The web
application should be in control. Server-side code should authenticate
access. Sending encrypted content to unauthorised users would make the
content susceptible to brute-force and weakness attacks.

 

[Ry Nohryb]

Ry Nohryb :


No, no, that is VK, and it is $10k (Maybe, when he started on
Shannon's Clairvoyant being used by professional cryptographers,
I should have mentioned that I happen to have been one, with an
"Autorisation administrative d'usage, de détention et de fourniture
d'armes de guerre de deuxième catégorie" to prove it.)


OK, done. 4 chars.

Coov,***** This, I agree, is no real security

)

(function (v) {
function newVector (v, baseChars) {
v.__proto__= {
baseChars: baseChars,
base: baseChars.length,
getKey: function () {
var key= "";
var i= this.length;
while (i--) {
key= this.baseChars[this]+ key;
}
return key;
},
inc: function () {
var i= 0, resto;
do {
if (resto= (this+= 1) >= this.base) this= 0;
} while ((++i < this.length) && resto);
return this;
},
dec: function () {
var i= 0, resto;
do {
if (resto= (this-= 1) < 0) this= this.base-1;
} while ((++i < this.length) && resto);
return this;
}
};
v.__proto__.__proto__= Array.prototype;
return v;
}

var stat= document.getElementById('idStatus') ||
document.body.appendChild(document.createElement('pre'));
var vector= newVector(v,
"6WNtRvp3ThXgJIjSZxVb2m5saA4KfdCoBnHeOy7D8cz9LYlPkiMUuE1qQw0rGF".split(""));
var n= 0;

(function loop () {
var key= vector.getKey();
var txt= AesCtr.decrypt(crypt0, key, 256);
if (txt.substring(0, 5) === '*****') {
alert([key, txt]);
return;
}
if (!(++n % 100)) {
stat.innerHTML= [n, "[ "+ vector+ " ]", key];
setTimeout(loop, 0);
return;
}
vector.inc();
loop();
})();

})([0,0,0,0]);

 

[Ry Nohryb]

Ry Nohryb :


No, no, that is VK, and it is $10k (Maybe, when he started on
Shannon's Clairvoyant being used by professional cryptographers,
I should have mentioned that I happen to have been one, with an
"Autorisation administrative d'usage, de détention et de fourniture
d'armes de guerre de deuxième catégorie" to prove it.)


OK, done. 4 chars.

Coov,***** This, I agree, is no real security

)

(function (v) {
function newVector (v, baseChars) {
v.__proto__= {
baseChars: baseChars,
base: baseChars.length,
getKey: function () {
var key= "";
var i= this.length;
while (i--) key= this.baseChars[this]+ key;
return key;
},
inc: function () {
var i= 0, resto;
do {
if (resto= (this+= 1) >= this.base) this= 0;
} while ((++i < this.length) && resto);
return this;
},
dec: function () {
var i= 0, resto;
do {
if (resto= (this-= 1) < 0) this= this.base-1;
} while ((++i < this.length) && resto);
return this;
}
};
v.__proto__.__proto__= Array.prototype;
return v;
}

var stat= document.getElementById('idStatus') ||
document.body.appendChild(document.createElement('pre'));
var vector= newVector(v,
"6WNtRvp3ThXgJIjSZxVb2m5saA4KfdCoBnHeOy7D8cz9LYlPkiMUuE1qQw0rGF".split(""));
var n= 0;

(function loop () {
while (++n % 100) {
var key= vector.getKey();
var txt= AesCtr.decrypt(crypt0, key, 256);
if (txt.substring(0, 5) === '*****') return alert([key, txt]);
vector.inc();
}
stat.innerHTML= [n, "[ "+ vector+ " ]", key];
setTimeout(loop, 0);
})();

})([0,0,0,0]);

(Slightly better than the one in my previous post: no recursive calls
to loop())