Please Help with this Password Script .. Im Confused !!!

[Ritchie Valens]

Hi,

I am new to Javascript, and spend all my time reading, and trying to
learn Javascript.

I managed to find this free password script, but I cant work out how
to access the password page.

The script is free:

http://www.planet-source-code.com/v...&lngWId=14&txtForceRefresh=725201119393874427


I cant work out what the password is, or how to change it for my
website.
There is no documentation, to explain how it works.

Can anybody work it out?


I tried ringing the software creator, but the line is dead.

Can anyone help please?
Life is Good !!!

 

[Ben Bacarisse]

I am new to Javascript, and spend all my time reading, and trying to
learn Javascript.

I managed to find this free password script, but I cant work out how
to access the password page.

The script is free:

http://www.planet-source-code.com/v...&lngWId=14&txtForceRefresh=725201119393874427

I cant work out what the password is, or how to change it for my
website.
There is no documentation, to explain how it works.

Can anybody work it out?

The passwords are represented by script files. E.g. if there is a file
called jake123.js (as indeed there is in the test package) the user name
"jake" and password "123" will pass -- as will user name "jak" with
password "e123". The contents of these files determine the target page.

BUT! Don't use this method and don't use this script in particular --
it provides zero security. As a first step towards alternatives, read
up on HTTP authentication.

<snip>

 

[Evertjan.]

Ritchie Valens wrote on 26 jul 2011 in comp.lang.javascript:

I managed to find this free password script, but I cant work out how
to access the password page.

Do not use clientside scripts for passwords. Anyone reading the script can
find out the paqssword, or even "better", a way around the password.

Passwords should be autenticated on the server.

Secondly never use password autentication scripts you do not understand,
how would you know they are safe?

The script is free

Free can be very expensive for the above reasons.

===========

The only way I know to get some but very small measure of security without
serverside code, is to use a secret url filename:

<form
onsubmit = 'location.href= this.pw.value +
".html";return false;'>
<input type='password' name='pw'> password
<br>
<input type='submit'>
</form>

 

[Denis McMahon]

Ritchie Valens wrote on 26 jul 2011 in comp.lang.javascript:


Do not use clientside scripts for passwords. Anyone reading the script
can find out the paqssword, or even "better", a way around the password.

Passwords should be autenticated on the server.

Secondly never use password autentication scripts you do not understand,
how would you know they are safe?


Free can be very expensive for the above reasons.

===========

The only way I know to get some but very small measure of security
without serverside code, is to use a secret url filename:

<form
onsubmit = 'location.href= this.pw.value +
".html";return false;'>
<input type='password' name='pw'> password <br>
<input type='submit'>
</form>

Hmm, I had a thought.

Supposing you store some text files on a server, each text file contains
a json encoded string of the form

[{"p":"p0","u":"u0"},{"p":"p1":"u":"u1"},{"p":"p2":"u":"u2"}]

works like this:

read the "userkey" in a script, convert it to a url, request that url
using an xhr, JSON.parse it, then if the password given matches a p, load
the appropriate page url u.

It's security by obscurity, as soon as the "userkey" is compromised, it
falls apart, and anyone reading the code will see a means of brute-
forcing to obtain the password file.

You could use any phrase as the user key if you checksum it (eg http://
pajhome.org.uk/crypt/md5/) as part of generating the password file url,
this will make such brute forcing a bit harder.

Still an absolutely crap security model, but it might keep the parents
away from the risque photos of the girlfriend for a couple of days.

Rgds

Denis McMahon

 

[Ritchie Valens]

Ben,

Thankyou so much for that information.

I was starting to think that the Var statement added up to make a
third word.

But thats great to know.


I have started using newsgroups again after many years, and there is
so much spam, but now All of you have responded, I will stay in this
Newsgroup

Regards

The passwords are represented by script files. E.g. if there is a file
called jake123.js (as indeed there is in the test package) the user name
"jake" and password "123" will pass -- as will user name "jak" with
password "e123". The contents of these files determine the target page.

BUT! Don't use this method and don't use this script in particular --
it provides zero security. As a first step towards alternatives, read
up on HTTP authentication.

<snip>

Life is Good !!!

 

[Ritchie Valens]

Evertjan,

Thankyou for your careful advice.

Much appreciated


Regards

Ritchie Valens wrote on 26 jul 2011 in comp.lang.javascript:


Do not use clientside scripts for passwords. Anyone reading the script can
find out the paqssword, or even "better", a way around the password.

Passwords should be autenticated on the server.

Secondly never use password autentication scripts you do not understand,
how would you know they are safe?


Free can be very expensive for the above reasons.

===========

The only way I know to get some but very small measure of security without
serverside code, is to use a secret url filename:

<form
onsubmit = 'location.href= this.pw.value +
".html";return false;'>
<input type='password' name='pw'> password
<br>
<input type='submit'>
</form>

Life is Good !!!

 

[Ritchie Valens]

Denis,

Your information makes sense, but because I am still learning
Javascript, a lot of it is above my hear.

Thankyou for your responsetho, I will re-read the info that you
posted.

Regards

Ritchie Valens wrote on 26 jul 2011 in comp.lang.javascript:


Do not use clientside scripts for passwords. Anyone reading the script
can find out the paqssword, or even "better", a way around the password.

Passwords should be autenticated on the server.

Secondly never use password autentication scripts you do not understand,
how would you know they are safe?


Free can be very expensive for the above reasons.

===========

The only way I know to get some but very small measure of security
without serverside code, is to use a secret url filename:

<form
onsubmit = 'location.href= this.pw.value +
".html";return false;'>
<input type='password' name='pw'> password <br>
<input type='submit'>
</form>

Hmm, I had a thought.

Supposing you store some text files on a server, each text file contains
a json encoded string of the form

[{"p":"p0","u":"u0"},{"p":"p1":"u":"u1"},{"p":"p2":"u":"u2"}]

works like this:

read the "userkey" in a script, convert it to a url, request that url
using an xhr, JSON.parse it, then if the password given matches a p, load
the appropriate page url u.

It's security by obscurity, as soon as the "userkey" is compromised, it
falls apart, and anyone reading the code will see a means of brute-
forcing to obtain the password file.

You could use any phrase as the user key if you checksum it (eg http://
pajhome.org.uk/crypt/md5/) as part of generating the password file url,
this will make such brute forcing a bit harder.

Still an absolutely crap security model, but it might keep the parents
away from the risque photos of the girlfriend for a couple of days.

Rgds

Denis McMahon

Life is Good !!!

 

[Evertjan.]

Denis McMahon wrote on 26 jul 2011 in comp.lang.javascript:

Ritchie Valens wrote on 26 jul 2011 in comp.lang.javascript:


Do not use clientside scripts for passwords. Anyone reading the
script can find out the paqssword, or even "better", a way around the
password.

Passwords should be autenticated on the server.

Secondly never use password autentication scripts you do not
understand, how would you know they are safe?


Free can be very expensive for the above reasons.

===========

The only way I know to get some but very small measure of security
without serverside code, is to use a secret url filename:

<form
onsubmit = 'location.href= this.pw.value +
".html";return false;'>
<input type='password' name='pw'> password <br>
<input type='submit'>
</form>

Hmm, I had a thought.

Supposing you store some text files on a server, each text file
contains a json encoded string of the form

[{"p":"p0","u":"u0"},{"p":"p1":"u":"u1"},{"p":"p2":"u":"u2"}]

works like this:

read the "userkey" in a script, convert it to a url, request that url
using an xhr, JSON.parse it, then if the password given matches a p,
load the appropriate page url u.

It's security by obscurity, as soon as the "userkey" is compromised,
it falls apart, and anyone reading the code will see a means of brute-
forcing to obtain the password file.

"security by obscurity" makes no sense, it is no security at all.

And more:
If you puplicize the ueserkey,
and can read the stream on the web you plan to download by JSON,
and can read the clientside javascript method,
what obscurity is left?

Even more:
Why take the risk of walking on a motorway when cars are available?

Use serverside programming and serverside databases.

 

[Ritchie Valens]

I am learning Javascript, and I have messed with cgi also.

I know that people say PHP is alo worth learning, or being familiar
with.

Regards

Denis McMahon wrote on 26 jul 2011 in comp.lang.javascript:

Ritchie Valens wrote on 26 jul 2011 in comp.lang.javascript:

I managed to find this free password script, but I cant work out how
to access the password page.

Do not use clientside scripts for passwords. Anyone reading the
script can find out the paqssword, or even "better", a way around the
password.

Passwords should be autenticated on the server.

Secondly never use password autentication scripts you do not
understand, how would you know they are safe?

The script is free

Free can be very expensive for the above reasons.

===========

The only way I know to get some but very small measure of security
without serverside code, is to use a secret url filename:

<form
onsubmit = 'location.href= this.pw.value +
".html";return false;'>
<input type='password' name='pw'> password <br>
<input type='submit'>
</form>

Hmm, I had a thought.

Supposing you store some text files on a server, each text file
contains a json encoded string of the form

[{"p":"p0","u":"u0"},{"p":"p1":"u":"u1"},{"p":"p2":"u":"u2"}]

works like this:

read the "userkey" in a script, convert it to a url, request that url
using an xhr, JSON.parse it, then if the password given matches a p,
load the appropriate page url u.

It's security by obscurity, as soon as the "userkey" is compromised,
it falls apart, and anyone reading the code will see a means of brute-
forcing to obtain the password file.

"security by obscurity" makes no sense, it is no security at all.

And more:
If you puplicize the ueserkey,
and can read the stream on the web you plan to download by JSON,
and can read the clientside javascript method,
what obscurity is left?

Even more:
Why take the risk of walking on a motorway when cars are available?

Use serverside programming and serverside databases.

You could use any phrase as the user key if you checksum it (eg
http:// pajhome.org.uk/crypt/md5/) as part of generating the password
file url, this will make such brute forcing a bit harder.

Still an absolutely crap security model, but it might keep the parents
away from the risque photos of the girlfriend for a couple of days.

Life is Good !!!

 

[Mike Duffy]

.. never use password authentication scripts you do not understand

You are much too reserved and understated. This should read:

"Never use scripts you do not understand."

As well as the possibility you mention of the code being unsafe (or
ineffective, inefficient, etc.), one must also consider the lifetime costs
of maintaining such code.

And I'm using the word "maintaining" very loosely here. It is more akin to
re-adapting the code by trial-and-error to meet new requirements. (Emphasis
on "error").

 

[Evertjan.]

Ritchie Valens wrote on 26 jul 2011 in comp.lang.javascript:

I am learning Javascript, and I have messed with cgi also.

Javascript and vbscript can be used serverside on an asp platform.

I know that people say PHP is alo worth learning, or being familiar
with.

PHP is the native serverside script language of linux servers.

So take your pick.

Serverside Javascript is the only one on topic on this NG,
and has the dual advantage of using the same function blocks both
serverside and clientside.

PHP is a Javascript lookalike, seen from a distance.

 

[Evertjan.]

Mike Duffy wrote on 26 jul 2011 in comp.lang.javascript:

You are much too reserved and understated. This should read:

"Never use scripts you do not understand."
Right.

As well as the possibility you mention of the code being unsafe (or
ineffective, inefficient, etc.), one must also consider the lifetime
costs of maintaining such code.

And I'm using the word "maintaining" very loosely here. It is more
akin to re-adapting the code by trial-and-error to meet new
requirements. (Emphasis on "error").

I do not need another's code for that. I can do that with my own code of
one year back easily, not understanding at all how and why it worked and
still works as was required then.

Rewriting essential parts of such code is fun, more fun than adaptation.

Evenso, as I use Dutch descriptive variable names, I have less difficulty
preventing the use of reserved words than many of you, and understanding
those names next year.

 

[Dr J R Stockton]

In comp.lang.javascript message <hm4s27p4vdo2m3pmecdai2aa1gnbbrv2en@4ax.

I managed to find this free password script,

Assume that anything offered for nothing on the Web is likely at best to
be trash, unless the author is clearly identifiable, with a good
reputation and some apparent reason for making the offer.

For real security, the password typed should be run through a one-way
function before being transmitted, and another one-way function before
being stored. A site which can tell you your lost password cannot be a
secure site.

However, true security is often not needed. A garden shed can be
protected, if in a visible and audible location, against mischievous
small children by using an ordinary padlock. More is needed to protect
against a gang of youths with chain-saws. Much more is needed if the
military really wants to get in or to destroy the contents.

A lock serves its purpose when it is though to be not worth trying to
open or break it.

 

[Ritchie Valens]

Dr J R Stockton,

Great point

Regards

In comp.lang.javascript message <hm4s27p4vdo2m3pmecdai2aa1gnbbrv2en@4ax.



Assume that anything offered for nothing on the Web is likely at best to
be trash, unless the author is clearly identifiable, with a good
reputation and some apparent reason for making the offer.

For real security, the password typed should be run through a one-way
function before being transmitted, and another one-way function before
being stored. A site which can tell you your lost password cannot be a
secure site.

However, true security is often not needed. A garden shed can be
protected, if in a visible and audible location, against mischievous
small children by using an ordinary padlock. More is needed to protect
against a gang of youths with chain-saws. Much more is needed if the
military really wants to get in or to destroy the contents.

A lock serves its purpose when it is though to be not worth trying to
open or break it.

Life is Good !!!