473,320 Members | 1,953 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

JS and security.

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
15 1827
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
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
"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
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

+) 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
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
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
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
"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
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
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
"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
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

"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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: robert | last post by:
well, talk about timely. i'm tasked to implement a security feature, and would rather do so in the database than the application code. the application is generally Oracle, but sometimes DB2. ...
116
by: Mike MacSween | last post by:
S**t for brains strikes again! Why did I do that? When I met the clients and at some point they vaguely asked whether eventually would it be possible to have some people who could read the data...
4
by: Ashish | last post by:
Hi Guys I am getting the following error while implementing authentication using WS-security. "Microsoft.Web.Services2.Security.SecurityFault: The security token could not be authenticated...
0
by: prithvi g via .NET 247 | last post by:
Hi I am a newbie to .NET remoting, I am trying to implementauthorization using SSPI example provided by Michael Barnett. Ihave included the required dll(Microsoft.Samples.Security.SSPI.dll...
1
by: Earl Teigrob | last post by:
Background: When I create a ASP.NET control (User or custom), it often requires security to be set for certain functionality with the control. For example, a news release user control that is...
7
by: Magdelin | last post by:
Hi, My security team thinks allowing communication between the two IIS instances leads to severe security risks. Basically, we want to put our presentation tier on the perimeter network and the...
0
by: Jay C. | last post by:
Jay 3 Jan. 11:38 Optionen anzeigen Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements Von: "Jay" <p.brunm...@nusurf.at> - Nachrichten dieses Autors suchen Datum: 3 Jan...
3
by: Velvet | last post by:
I ran FxCop on one of the components for my web site and the security rules what me to add " tags like the ones listed below: This breaks my ASP.NET application. So my question is,...
1
by: Jeremy S. | last post by:
..NET's code Access Security enables administrators to restrict the types of things that a .NET application can do on a local computer. For example, a ..NET Windows Forms application can be...
2
by: Budhi Saputra Prasetya | last post by:
Hi, I managed to create a Windows Form Control and put it on my ASP .NET page. I have done the suggestion that is provided by modifying the security settings. From the stack trace, I would...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.