help in secutrity features

[kev]

I am doing a mini intranet site, where one of the page is a password
protect page.

And i have used javascript for the password.

Its all running successfully.

So only if a person knows the password, can login in to that page....

but then, a person who knows the path of that file can easily access
the file by just copyin it and pasting in the address bar...

is there any way to prevent it??

please help

following is the link where u can find the password file......

http://cjoint.com/?dxx1gmlmTB

 

[The Magpie]

[snip] And i have used javascript for the password.

but then, a person who knows the path of that file can easily
access the file by just copyin it and pasting in the address bar...


is there any way to prevent it??

Nope. By definition, client-side Javascript must be sent to the
client. If its sent, they can read it.

 

[kev]

[snip] And i have used javascript for the password.

but then, a person who knows the path of that file can easily
access the file by just copyin it and pasting in the address bar...

is there any way to prevent it??

Nope. By definition, client-side Javascript must be sent to the
client. If its sent, they can read it.

how can i stop it???

 

[Jeremy J Starcher]

[snip] And i have used javascript for the password.

but then, a person who knows the path of that file can easily access
the file by just copyin it and pasting in the address bar...

is there any way to prevent it??

Nope. By definition, client-side Javascript must be sent to the client.
If its sent, they can read it.

how can i stop it???

As The Magpie said, it *MUST* be sent to the client. You can NOT stop
it.

The only thing you can do is use some alternate form of security,
something server-side.

I do not do much server-side coding so I couldn't point you to a good
example, but in general you would want to:

Ask the user for their password in a form.
Using https (note the S), send that form to a server-side script that
will validate the password and then display the page. Most that I've
seen store a cookie that indicates an authorized session.

(Extra points if you just pass the password hash, not the original
password.)

There are more examples of what NOT to do then good ones though, and I'm
not qualified to say what is good, but just setting a cookie that says
"logged-in=true" is bad.

 

[Michael Wojcik]

I am doing a mini intranet site, where one of the page is a password
protect page.

And i have used javascript for the password.

A couple of other people have already tried to explain this, but it
may not be clear to you. You have not protected anything. Client-side
authentication offers no security.

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but there's
no benefit to doing so, since in this scheme it's trivial to bypass
the authentication process entirely.)

but then, a person who knows the path of that file can easily access
the file by just copyin it and pasting in the address bar...

is there any way to prevent it??

Yes. Use proper server-side verification, implemented by someone with
some expertise in this area.

Security systems built by non-experts are nearly always fatally
flawed. Security is a complicated subject, and it's inherently
fragile: a single exploitable vulnerability breaks the security of the
whole system. Ad hoc checks only keep out the casually curious.

 

[Thomas 'PointedEars' Lahn]

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is only
possible to make it expensive for the cracker. Every encryption algorithm
is susceptible to a brute force key search attack. Providing the encryption
algorithm along with the resource to be protected makes it even more likely
that the so-called irreversible function can be reversed by them.


PointedEars

 

[Evertjan.]

Thomas 'PointedEars' Lahn wrote on 02 apr 2008 in comp.lang.javascript:

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is
only possible to make it expensive for the cracker. Every encryption
algorithm is susceptible to a brute force key search attack.
Providing the encryption algorithm along with the resource to be
protected makes it even more likely that the so-called irreversible
function can be reversed by them.

But, Thomas, there is no need for your 'brute force key search attack',
as the output of the 100% clientside encryption function surely
is a boolean, determining the choice between entry or no entry.

Just replace the body of that function with 'return true;'

 

[kev]

Thomas 'PointedEars' Lahn wrote on 02 apr 2008 in comp.lang.javascript:

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.
(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is
only possible to make it expensive for the cracker.  Every encryption
algorithm is susceptible to a brute force key search attack.
Providing the encryption algorithm along with the resource to be
protected makes it even more likely that the so-called irreversible
function can be reversed by them.

But, Thomas, there is no need for your 'brute force key search attack',
as the output of the 100% clientside encryption function surely
is a boolean, determining the choice between entry or no entry.

Just replace the body of that function with 'return true;'

...thanks a lot for the reply....

but a small correction......i am actually fine with password
encryption....

my problem is that, when a person, simply copies the address of the
page from addressbar and if pastes in new internet explorer , it
should not display the content of page.....

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

or passing a parameter value from first page to second page.....

so that the second page will work only if the value matches ....and if
the user copies the address of the page, he can view anything, coz
when the page checks the parameter, it will not match...

is there a way to do like this???

in java???

Please help?

 

[kev]

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is only
possible to make it expensive for the cracker.  Every encryption algorithm
is susceptible to a brute force key search attack.  Providing the encryption
algorithm along with the resource to be protected makes it even more likely
that the so-called irreversible function can be reversed by them.

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

...thanks a lot for the reply....

but a small correction......i am actually fine with password
encryption....

my problem is that, when a person, simply copies the address of the
page from addressbar and if pastes in new internet explorer , it
should not display the content of page.....

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

or passing a parameter value from first page to second page.....

so that the second page will work only if the value matches ....and if
the user copies the address of the page, he can view anything, coz
when the page checks the parameter, it will not match...

is there a way to do like this???

in java???

Please help?

 

[kev]

A couple of other people have already tried to explain this, but it
may not be clear to you. You have not protected anything. Client-side
authentication offers no security.

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but there's
no benefit to doing so, since in this scheme it's trivial to bypass
the authentication process entirely.)



Yes. Use proper server-side verification, implemented by someone with
some expertise in this area.

Security systems built by non-experts are nearly always fatally
flawed. Security is a complicated subject, and it's inherently
fragile: a single exploitable vulnerability breaks the security of the
whole system. Ad hoc checks only keep out the casually curious.

...thanks a lot for the reply....

but a small correction......i am actually fine with password
encryption....

my problem is that, when a person, simply copies the address of the
page from addressbar and if pastes in new internet explorer , it
should not display the content of page.....

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

or passing a parameter value from first page to second page.....

so that the second page will work only if the value matches ....and if
the user copies the address of the page, he can view anything, coz
when the page checks the parameter, it will not match...

is there a way to do like this???

in java???

Please help?

 

[kev]

kev wrote:
[snip] And i have used javascript for the password.
but then, a person who knows the path of that file can easily access
the file by just copyin it and pasting in the address bar...
is there any way to prevent it??
Nope. By definition, client-side Javascript must be sent to the client.
If its sent, they can read it.

how can i stop it???

As The Magpie said, it *MUST* be sent to the client.   You can NOT stop
it.

The only thing you can do is use some alternate form of security,
something server-side.

I do not do much server-side coding so I couldn't point you to a good
example, but in general you would want to:

Ask the user for their password in a form.
Using https (note the S), send that form to a server-side script that
will validate the password and then display the page.  Most that I've
seen store a cookie that indicates an authorized session.

(Extra points if you just pass the password hash, not the original
password.)

There are more examples of what NOT to do then good ones though, and I'm
not qualified to say what is good, but just setting a cookie that says
"logged-in=true" is bad.

...thanks a lot for the reply....

but a small correction......i am actually fine with password
encryption....

my problem is that, when a person, simply copies the address of the
page from addressbar and if pastes in new internet explorer , it
should not display the content of page.....

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

or passing a parameter value from first page to second page.....

so that the second page will work only if the value matches ....and if
the user copies the address of the page, he can view anything, coz
when the page checks the parameter, it will not match...

is there a way to do like this???

in java???

Please help?

 

[kev]

[snip] And i have used javascript for the password.

but then, a person who knows the path of that file can easily
access the file by just copyin it and pasting in the address bar...

is there any way to prevent it??

Nope. By definition, client-side Javascript must be sent to the
client. If its sent, they can read it.

...thanks a lot for the reply....

but a small correction......i am actually fine with password
encryption....

my problem is that, when a person, simply copies the address of the
page from addressbar and if pastes in new internet explorer , it
should not display the content of page.....

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

or passing a parameter value from first page to second page.....

so that the second page will work only if the value matches ....and if
the user copies the address of the page, he can view anything, coz
when the page checks the parameter, it will not match...

is there a way to do like this???

in java???

Please help?

 

[Evertjan.]

kev wrote on 03 apr 2008 in comp.lang.javascript:

but a small correction......i am actually fine with password
encryption....

my problem is that, when a person, simply copies the address of the
page from addressbar and if pastes in new internet explorer , it
should not display the content of page.....

So you were not asking for security [secutrity ?] ?
What you want has nothing to do with security,
as it is not secure.

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

Same problenm, not securely.

==============

You should look into serverside programming and serverside sessions
when you want to have users login. Serverside javascript is a good choice.

Do not try to mow your lawn with a toothbrush,
claiming you have no mower.

 

[Jeremy J Starcher]

...thanks a lot for the reply....

but a small correction......i am actually fine with password
encryption....

my problem is that, when a person, simply copies the address of the page
from addressbar and if pastes in new internet explorer , it should not
display the content of page.....

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

This question has gone beyond what can be answered in this group, and
goes beyond my knowledge. Google for ".htaccess" This will allow you to
password protect directories.

Checking to see what page the user has come from is called "referer
checking" (the misspelling is intentional) and is not a secure.

This topic should be moved to another group.

 

[Michael Wojcik]

my problem is that, when a person, simply copies the address of the
page from addressbar and if pastes in new internet explorer , it
should not display the content of page.....

my friend suggested me to check whether, the user has come from some
page (login.html) or not...if not do not display....

is there a way to do like this????

Not on the client. It's possible to enforce this to a certain extent -
that is, to increase the work factor of bypasing it - on the server,
but you cannot guarantee that an attacker cannot get to the second
page without visiting the first. HTTP requests are stateless. You can
try to maintain state on the server and enforce virtual sessions, but
you'll never be able to close that window completely. Everything a
legitimate user can provide to tie a request to a session can
potentially be forged by an attacker.

or passing a parameter value from first page to second page.....

so that the second page will work only if the value matches ....and if
the user copies the address of the page, he can view anything, coz
when the page checks the parameter, it will not match...

is there a way to do like this???

in java???

In Java? Yes, on the server, if the server supports running Java. But
that has nothing to do with the topic of this newsgroup, which is
javascript (or, if you prefer, implementations of ECMA-262).

 

[Michael Wojcik]

Thomas 'PointedEars' Lahn wrote on 02 apr 2008 in comp.lang.javascript:

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is
only possible to make it expensive for the cracker. Every encryption
algorithm is susceptible to a brute force key search attack.

But, Thomas, there is no need for your 'brute force key search attack',
as the output of the 100% clientside encryption function surely
is a boolean, determining the choice between entry or no entry.

Just replace the body of that function with 'return true;'

Er, yes, as I pointed out in the first part of my original message,
quoted above. I imagine Thomas was also well aware of that.

 

[Michael Wojcik]

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is only
possible to make it expensive for the cracker. Every encryption algorithm
is susceptible to a brute force key search attack.

I'm not talking about encryption; I'm talking about one-way verifiers.
And while it's possible to find a preimage for a verifier, there's no
way to know that's the "password".

If the work factor's high enough, the probability of successful
brute-force search can be made asymptotically close to zero. That's
good enough for me.

Providing the encryption
algorithm along with the resource to be protected makes it even more likely
that the so-called irreversible function can be reversed by them.

There's no such thing as a one-way encryption function. There are
one-way functions and there are encryption functions; they do
completely different things. I was talking about the former. And a
one-way function by definition cannot be "reversed". (The last I
looked, it was an open question whether one-way functions actually
exist, or whether only asymmetrically-difficult ones do; but that's
irrelevant to the question at hand.)

 

[Evertjan.]

Michael Wojcik wrote on 04 apr 2008 in comp.lang.javascript:

Thomas 'PointedEars' Lahn wrote on 02 apr 2008 in comp.lang.javascript:

Michael Wojcik wrote:
A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is
only possible to make it expensive for the cracker. Every encryption
algorithm is susceptible to a brute force key search attack.

But, Thomas, there is no need for your 'brute force key search attack',
as the output of the 100% clientside encryption function surely
is a boolean, determining the choice between entry or no entry.

Just replace the body of that function with 'return true;'

Er, yes, as I pointed out in the first part of my original message,
quoted above. I imagine Thomas was also well aware of that.

Michael, my comment responded on Thomases "to make it expensive for the
cracker", which I showed not to be true.

 

[Thomas 'PointedEars' Lahn]

A hostile user has complete control of the client. There's no way to
stop such a user from forging a valid request.

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]

It is not possible to prevent the determination of the password; it is only
possible to make it expensive for the cracker. Every encryption algorithm
is susceptible to a brute force key search attack.

I'm not talking about encryption; I'm talking about one-way verifiers.

A verifier includes either a decryption or an encryption algorithm.

And while it's possible to find a preimage for a verifier, there's no
way to know that's the "password".

Yes, there is, for the verifier will return success then. That is its function.

There's no such thing as a one-way encryption function.

While I don't agree with that, I have also not debated that.

There are one-way functions and there are encryption functions; they do
completely different things. I was talking about the former. And a
one-way function by definition cannot be "reversed". (The last I
looked, it was an open question whether one-way functions actually
exist, or whether only asymmetrically-difficult ones do; but that's
irrelevant to the question at hand.)

Name one.


PointedEars

 

[Michael Wojcik]

Michael Wojcik wrote:

(It's also likely that they can simply determine the password by
looking at your script. There are ways to prevent that - for example,
by implementing an irreversible function as the verifier - but [...]
It is not possible to prevent the determination of the password; it is only
possible to make it expensive for the cracker. Every encryption algorithm
is susceptible to a brute force key search attack.

I'm not talking about encryption; I'm talking about one-way verifiers.

A verifier includes either a decryption or an encryption algorithm.

That's simply wrong. You clearly do not know what you're talking about
in this case.

Probably the most common password-verification functions today are
based on cryptographic hash functions. They don't use encryption or
decryption algorithms.

Zero-knowledge-proof verifiers, as used in eg SRP-3 and PAK-RY, don't
use encryption or decryption algorithms.

Yes, there is, for the verifier will return success then. That is its function.

No, the verifier proves that a preimage is a preimage. It doesn't
prove that it's the password, which is one possible preimage. This is
an elementary property of irreversible functions.

While I don't agree with that, I have also not debated that

You're wrong twice there. First, there cannot be a "one-way encryption
function", because "encryption" (as a term of art) implies decryption,
which implies a bijection, and so excludes a one-way function. Second,
you clearly claim, in the passage quoted above, that the "irreversible
function" implements an "encryption algorithm", so you did in fact
implicitly claim that there was such a thing as a one-way encryption
algorithm. There is not, and your sentence above makes no sense.

Name one.

SHA-256 is a proper one-way function. So is every other lossy compressor.

An asymmetrically-difficult, believed-one-way, lossless function is
the discrete log problem. Another is the constructed-Hamiltonian-path
problem, sometimes used (at least conceptually, if not in practice)
for a zero-knowledge proof.

This is all very basic cryptographic math. Read Schneier, or the
sci.crypt FAQ.

I'll note in passing that the parenthetical above from my previous
post isn't correct as stated; I compressed two related but distinct
concepts - lossy functions (surjections) and lossless but
asymmetrically difficult functions ("trapdoor" bijections) - into
one-way functions. Obviously one-way surjections are known to exist;
all surjections are at least partially one-way, by definition. The
open problem is whether there are any bijections that are really
always asymmetrically difficult (ie, much easier to compute than to
reverse).