By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,089 Members | 1,964 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,089 IT Pros & Developers. It's quick & easy.

JS and security.

P: n/a
According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."

How would using JS improve security?

Thanks.
Sep 1 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
osfwofujro said the following on 9/1/2005 10:11 AM:
According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."

How would using JS improve security?


It doesn't. It shows the incompetence of the programmers who programmed
the site.

Unless they mean its used for security reasons to hamper the ones that
don't understand how to defeat the security in the first place.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Sep 1 '05 #2

P: n/a
Randy Webb wrote:
osfwofujro said the following on 9/1/2005 10:11 AM:
According to a financial website I tried to access without
javascript: "the site uses JS for security reasons."

How would using JS improve security?

It doesn't. It shows the incompetence of the programmers who
programmed the site.

Unless they mean its used for security reasons to hamper the ones that
don't understand how to defeat the security in the first place.

I thought it might be to grab the users IP address (if perhaps they were
using a proxy)?
Sep 1 '05 #3

P: n/a
"osfwofujro" <jw*@9ewutr.com> wrote in message
news:6_***************@newsfe4-gui.ntli.net...
According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."

How would using JS improve security?


There might be several ways... but none particularly good.

Firs off for any of this to mean anything the sitew would have to only
function with JavaScript enabled. Second for any of them to function it
would have to operate on "soft" security - those little interface things
that prod the user in a certiain direction but don't actually address any
real "hard" security problems.

But still there are several things in that arena that might be done:

+) Many sites open their financial applications in secondary windows
(usually chromeless). This has the benefit that once that window is closed
the main browser window will not contain the history of the child window.
(Of course you can open a new window without JavaScript, but we all know
that JavaScript makes working with child windows a lot smoother.)

+) Using JavaScript/DHTML the site might, either automatically when it
senses no activity or on user request, mask out (make invisilble or cover
with an opaque element) the screen or mask out form field or other
potentially sensitive information. Automatic systems might require the
password to unmask the information although this isn't actual security of
course it does prevent casual observers.

+) Using AJAX-style data aquisition into JavaScript variables means that
your personal information isn't cached in the browser or the source code.
So even, say, if somebody were to disable JavaScript and view your source
code they couldn't actually see your data (which is abstracted into
variables). Again this isn't real security but it prevents a more
sophisticated class of potential thief. It also, of course means, that none
of the information can be viewed with JavaScript enabled.

+) JavaScript is very useful at nudging the user in the right direction.
Active reminders to close a browser window when leaving an application
(using the onunload()) to prevent history mining) are often effective.

+) There is some thought that using onscreen keyboards (keyboards written in
JavaScript or Flash or the like) will improve security. The idea (which has
at least some merit) is that this will prevent keystroke sniffers from
obtaining your password.

There are others but it should be clear that any option that would truly
address softsecurity issues will also almost definitely affect accessibility
for a site. Also none of them can address phishing campaings and the like
(which can just use the same features to make their phony sites look that
much more accurate).

There's no sense (although I'm willing to be conviced) in attempting to
address hard security issues via JavaScript. Things like data encryption,
key management, credential management, etc should all be centralized and
rigidly controlled.

Also while, in theory, everything that can be done should be done (and
there's legislation being written to enforce this idea in many countries)
all of these solutions address the client-side completely. While this isn't
a bad thing the vast (vast) majority of data compromise has occured on the
corporate side. No matter how successful phishing and keystroke logging may
be they pale in comparison to the loss of millions of records at a time
through corporate security gaffs.

Still - if you know (and can accept) the limitations there are definately
things to do with script which can _improve_ (aspects of) security. But
script itself can't _provide_ real security in any way.

Jim Davis
Sep 1 '05 #4

P: n/a
Jim Davis wrote:
"osfwofujro" <jw*@9ewutr.com> wrote in message
news:6_***************@newsfe4-gui.ntli.net...

According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."

How would using JS improve security?


There might be several ways... but none particularly good.

Firs off for any of this to mean anything the sitew would have to only
function with JavaScript enabled. Second for any of them to function it
would have to operate on "soft" security - those little interface things
that prod the user in a certiain direction but don't actually address any
real "hard" security problems.

But still there are several things in that arena that might be done:

+) Many sites open their financial applications in secondary windows
(usually chromeless). This has the benefit that once that window is closed
the main browser window will not contain the history of the child window.
(Of course you can open a new window without JavaScript, but we all know
that JavaScript makes working with child windows a lot smoother.)

+) Using JavaScript/DHTML the site might, either automatically when it
senses no activity or on user request, mask out (make invisilble or cover
with an opaque element) the screen or mask out form field or other
potentially sensitive information. Automatic systems might require the
password to unmask the information although this isn't actual security of
course it does prevent casual observers.

+) Using AJAX-style data aquisition into JavaScript variables means that
your personal information isn't cached in the browser or the source code.
So even, say, if somebody were to disable JavaScript and view your source
code they couldn't actually see your data (which is abstracted into
variables). Again this isn't real security but it prevents a more
sophisticated class of potential thief. It also, of course means, that none
of the information can be viewed with JavaScript enabled.

+) JavaScript is very useful at nudging the user in the right direction.
Active reminders to close a browser window when leaving an application
(using the onunload()) to prevent history mining) are often effective.

+) There is some thought that using onscreen keyboards (keyboards written in
JavaScript or Flash or the like) will improve security. The idea (which has
at least some merit) is that this will prevent keystroke sniffers from
obtaining your password.

There are others but it should be clear that any option that would truly
address softsecurity issues will also almost definitely affect accessibility
for a site. Also none of them can address phishing campaings and the like
(which can just use the same features to make their phony sites look that
much more accurate).

There's no sense (although I'm willing to be conviced) in attempting to
address hard security issues via JavaScript. Things like data encryption,
key management, credential management, etc should all be centralized and
rigidly controlled.

Also while, in theory, everything that can be done should be done (and
there's legislation being written to enforce this idea in many countries)
all of these solutions address the client-side completely. While this isn't
a bad thing the vast (vast) majority of data compromise has occured on the
corporate side. No matter how successful phishing and keystroke logging may
be they pale in comparison to the loss of millions of records at a time
through corporate security gaffs.

Still - if you know (and can accept) the limitations there are definately
things to do with script which can _improve_ (aspects of) security. But
script itself can't _provide_ real security in any way.

Jim Davis

Thanks - this was really useful and I learned a lot from it.
Sep 1 '05 #5

P: n/a

+) There is some thought that using onscreen keyboards (keyboards written in
JavaScript or Flash or the like) will improve security. The idea (which has
at least some merit) is that this will prevent keystroke sniffers from
obtaining your password.

In this case, the site does not use an onscreen keyboard, but it does
have a drop down menu where letters from the password have to be chosen
e.g. 1st and 5th letter. Presumably even if a sniffer was installed, it
would not be able to tell what password letters were used?
Sep 1 '05 #6

P: n/a
what about this:

Yahoo! use it for all non-SSL logins.

acording to this guy:

http://pajhome.org.uk/crypt/md5/

wich is a nice way to secure data troug non ssl stuff.

like, when u encrypt ypur pwd before u send it, however even the guy in
the page admints that:

In any case, JS interpreters are not designed for secure programming.
They may leave sensitive information lying about in memory. They're too
slow for some algorithms, e.g. BSD-style MD5 passwords, or RSA with
full-size keys. Bitwise operations are buggy in several
implementations.

Sep 1 '05 #7

P: n/a
osfwofujro said the following on 9/1/2005 12:31 PM:
Randy Webb wrote:
osfwofujro said the following on 9/1/2005 10:11 AM:
According to a financial website I tried to access without
javascript: "the site uses JS for security reasons."

How would using JS improve security?


It doesn't. It shows the incompetence of the programmers who
programmed the site.

Unless they mean its used for security reasons to hamper the ones that
don't understand how to defeat the security in the first place.

I thought it might be to grab the users IP address (if perhaps they were
using a proxy)?


Javascript has no means to get an IP address, whether behind a proxy or
not. So that's not a reason. It show's the incompetence of the authors
to proclaim that JS is used for security.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Sep 1 '05 #8

P: n/a
Randy Webb wrote:
osfwofujro said the following on 9/1/2005 12:31 PM:
Randy Webb wrote:
osfwofujro said the following on 9/1/2005 10:11 AM:

According to a financial website I tried to access without
javascript: "the site uses JS for security reasons."

How would using JS improve security?


It doesn't. It shows the incompetence of the programmers who
programmed the site.

Unless they mean its used for security reasons to hamper the ones
that don't understand how to defeat the security in the first place.

I thought it might be to grab the users IP address (if perhaps they
were using a proxy)?

Javascript has no means to get an IP address, whether behind a proxy
or not. So that's not a reason. It show's the incompetence of the
authors to proclaim that JS is used for security.

So which languages can get IP if one is using a proxy? Java? Active X?

Thanks.

I always was under the impression that JS coule get the IP from behind
the proxy.
Sep 1 '05 #9

P: n/a
"osfwofujro" <jw*@9ewutr.com> wrote in message
news:Zy****************@newsfe4-win.ntli.net...

[snip]
I always was under the impression that JS coule [sic] get the IP from

behind the proxy.

And I grew up with the impression that "they all lived happily ever after".
Sep 1 '05 #10

P: n/a
osfwofujro said the following on 9/1/2005 6:48 PM:
Randy Webb wrote:
osfwofujro said the following on 9/1/2005 12:31 PM:
Randy Webb wrote:

osfwofujro said the following on 9/1/2005 10:11 AM:

> According to a financial website I tried to access without
> javascript: "the site uses JS for security reasons."
>
> How would using JS improve security?

It doesn't. It shows the incompetence of the programmers who
programmed the site.

Unless they mean its used for security reasons to hamper the ones
that don't understand how to defeat the security in the first place.

I thought it might be to grab the users IP address (if perhaps they
were using a proxy)?
Javascript has no means to get an IP address, whether behind a proxy
or not. So that's not a reason. It show's the incompetence of the
authors to proclaim that JS is used for security.

So which languages can get IP if one is using a proxy? Java? Active X?


Java can. ActiveX might be able to if you allow it "rape my computer"
access. Just about any server-side language can get some form of IP, and
the behind-proxy can be found by some, depending on how many proxies it
goes through.
I always was under the impression that JS coule get the IP from behind
the proxy.


Nope.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Sep 2 '05 #11

P: n/a
Jim Davis wrote:

There's no sense (although I'm willing to be conviced) in attempting to
address hard security issues via JavaScript. Things like data encryption,
key management, credential management, etc should all be centralized and
rigidly controlled.


One good use for Javascript is the encryption of passwords before they
are sent to the server. Most users use the same passwords for multiple
applications, so sniffing out a users password on one application may
lessen the security on other applications the user has access to.

It is better for the user's point of view to never let the host have
access to the user's raw password. Therefore, none of the dishonest
employees with access to the user file on the host will have access to
the user's password.

To initially set a password, the host sends a form with fields for Logon
ID, Password, and a hidden static string unique for the host. The user
enters Logon ID and Password and clicks submit. Javascript on the
client hashes the 3 fields together and sends the result as the new
password (the result may be a 20 - 40 character string). The host
stores the hashed string as the password.

To login, the host sends a form with Logon ID, Password, and one hidden
field with the static string, and another Random Number unique to that
request. The user enters Logon ID, Pasword and clicks Submit.
Javascript on the client hashes the Logon ID, Password, and static
string (to arrive at the hashed password stored by the host), and then
hashes the hashed result and the Random Number and sends the result as
the password. The host hashes the stored hashed password and the Random
Number and compares it to the incoming password.

Security is increased because (1) no passwords are sent in the clear
(could do the same by encrypting the whole response), (2) the raw
password is never received nor stored on the host side.

Yahoo uses the above method for it email login routines. Google for
"sha1 javascript".

Roger
Sep 2 '05 #12

P: n/a
"Roger" <cr**************@cox.net> wrote in message
news:3s_Re.63787$Ji4.40484@fed1read03...
Jim Davis wrote:

There's no sense (although I'm willing to be conviced) in attempting to
address hard security issues via JavaScript. Things like data
encryption, key management, credential management, etc should all be
centralized and rigidly controlled.

One good use for Javascript is the encryption of passwords before they are
sent to the server. Most users use the same passwords for multiple
applications, so sniffing out a users password on one application may
lessen the security on other applications the user has access to.


I can see the point... but have two issues with this:

1) Doing "good" encryption is difficult to do in script (it's slow and
they're language issues). So, for the most part it'll be weak encryption
anyway.

2) In my opinion no passwords should be sent across an open pipe anyway: SSL
should always be used. This is MUCH stronger encryption that you'd get with
script and eliminates any benefit to manually encrypting the password.

However if you're unable to use SSL then this might be a "better that
nothing" solution.
It is better for the user's point of view to never let the host have
access to the user's raw password. Therefore, none of the dishonest
employees with access to the user file on the host will have access to the
user's password.


Ah - but you're not talking about encrption here (sorry to be a jerk - this
is a pet peeve of mine). This is called "hashing".

Encyption implies that you can retrieve the data again (to be plain
encyption implies unencryption). Hashing, on the other hand, is more like a
"fingerprinting" - it's an identification technology. While a fingerprint
can be used to identify somebody it can't be used to recreate the whole
person.

For hash generation I can definately see some use for doing it on the
client-side. There are still issues. (For example hashes, especially for
small values, aren't unique - so many possible passwords could have the same
hash - any of which would work to get into the user's account.)

But there is definately some value in it, you're right.

Jim Davis
Sep 2 '05 #13

P: n/a
Jim Davis wrote:
"Roger" <cr**************@cox.net> wrote in message
news:3s_Re.63787$Ji4.40484@fed1read03...
Jim Davis wrote:

There's no sense (although I'm willing to be conviced) in attempting to
address hard security issues via JavaScript. Things like data
encryption, key management, credential management, etc should all be
centralized and rigidly controlled.


One good use for Javascript is the encryption of passwords before they are
sent to the server. Most users use the same passwords for multiple
applications, so sniffing out a users password on one application may
lessen the security on other applications the user has access to.

I can see the point... but have two issues with this:

1) Doing "good" encryption is difficult to do in script (it's slow and
they're language issues). So, for the most part it'll be weak encryption
anyway.

2) In my opinion no passwords should be sent across an open pipe anyway: SSL
should always be used. This is MUCH stronger encryption that you'd get with
script and eliminates any benefit to manually encrypting the password.

However if you're unable to use SSL then this might be a "better that
nothing" solution.

It is better for the user's point of view to never let the host have
access to the user's raw password. Therefore, none of the dishonest
employees with access to the user file on the host will have access to the
user's password.

Ah - but you're not talking about encrption here (sorry to be a jerk - this
is a pet peeve of mine). This is called "hashing".

Encyption implies that you can retrieve the data again (to be plain
encyption implies unencryption). Hashing, on the other hand, is more like a
"fingerprinting" - it's an identification technology. While a fingerprint
can be used to identify somebody it can't be used to recreate the whole
person.

For hash generation I can definately see some use for doing it on the
client-side. There are still issues. (For example hashes, especially for
small values, aren't unique - so many possible passwords could have the same
hash - any of which would work to get into the user's account.)

But there is definately some value in it, you're right.

Jim Davis


Hashing would have been a better word to use than encryption. I
sometimes think of hashing as one way encryption.

I should have stated that the Logon ID, password and the host specific
string (often called "salt") are concatenated together before hashing.
Thus, when the salt is different (for different applications), the
hashed password is different even though the Logon ID and password are
the same. The salt can be as long as the host wants to make it.

Roger
Sep 2 '05 #14

P: n/a

"Roger" <cr**************@cox.net> wrote in message
news:T55Se.73798$DW1.21617@fed1read06...
Jim Davis wrote:
"Roger" <cr**************@cox.net> wrote in message
news:3s_Re.63787$Ji4.40484@fed1read03...
Hashing would have been a better word to use than encryption. I sometimes
think of hashing as one way encryption.


No problem - like I said, I tend to be a jerk about my pet peeves. ;^)
I should have stated that the Logon ID, password and the host specific
string (often called "salt") are concatenated together before hashing.
Thus, when the salt is different (for different applications), the hashed
password is different even though the Logon ID and password are the same.
The salt can be as long as the host wants to make it.


But in this case it seems that the salt is a known value, right (the host
string and log in ID)? Essentaially as long as you know those two values
(and how they're put together - which you would since it's done in
JavaScript) then it's pretty easy to find a password that (with the two
values) will work. The only unknown variable quantity is the password.

Not trivially easy, but not all that hard either. Still - "every little bit
helps" and this definately qualifies.

Jim Davis
Sep 3 '05 #15

P: n/a
osfwofujro wrote:
According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."

How would using JS improve security?


My guess is that "the site uses JS for reducing development costs."
did not sound near as good.

That's like when the goverment says
"in the interest of national security". It probably aint,
but it sounds better than "If we told you , we'd go to jail"

--
--.
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=-- C++,HTML/CSS,Javascript,TCP ...
--`
Sep 5 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.