[Advanced-java] Sensitive Data -> StringgetParameter(String )Alternative

[Carlo]

----- Original Message ----- 
From: "Nikolaos Giannopoulos" <nikolaos@solmar.ca>
To: "Carlo" <carlo.ravagli@extropia.com>
Cc: <advanced-java@lists.xcf.berkeley.edu>
Sent: Tuesday, May 06, 2003 1:08 AM
Subject: RE: [Advanced-java] Sensitive Data ->
StringgetParameter(String )Alternative


> > Carlo wrote:
> > What we have had to do in the past is actually encrypt
> > the sensitive data on the browser with an applet (in addition
> > to HTTPS). Here is the process:
>
> And although this is a more iron-clad solution - as it protects data
> end-to-end - there are some issues for its general adoption IMO.  I'll
> re-use some comments from my reply to Martin's post (as they apply here
for
> somewhat similar reasons):
>
> "...unless any solution can be easily integrated to a browser
> HTML/CSS/JavaScript OR JSP mechanism its just not going to help very much
> i.e. a solution that offers "more" security at the cost of nobody using it
> is more secure but with very little OR zero value."

Well you could write the encryption algorithm in Javascript. However,
some of your arguments against Java applets also apply to
Javascript. E.g. I know that some corporates prevent their employees from
installing plugins. Therefore if your target user base for your e-commerce
site is going to be corporate users then I can see your concerns.
However, if that is the case you'll also need to be careful about using
Javascript as well because by the same token these same corporates
generally prevent javascript being enabled on employee browsers as well.

>
> "In the end, I totally welcome any solution that will make things more
> secure as long as it doesn't create a greater hassle for the customer e.g.
> Java applets and plug-ins are out for numerous reasons as history has
> already shown i.e. Security considerations must always be balanced against
> other considerations and unfortunately for e-commerce ease of use is a big
> one to balance against."
>

Surely from an e-commerce perspective security is also a big issue?
As a user would you want to use an e-commerce site that you did
not think was secure? I know most users are content so long as they
see they are using https (or they see the little padlock in the bottom
corner of their browser window) but if your site gets hacked and
credit card numbers are stolen....well I don't think many people
would be using your site. I agree with you that as with any risk,
it needs to be weighed up and generally it's you (or your client's)
responsibility (with the help of a security consultant) to determine
what exposure you (or you client) is willing to live with. In our case,
our clients are banks so security is very important to them. If your
site is just a credit card gateway then perhaps security does not
need to be so tight. I mean, most of us give our credit card
number to complete strangers everyday i.e. at gas stations to the
attendents, at supermarkets to the check out operators, at bars to
the bar men and women , at resturants to waiters and waitresses staff etc...

>
> > Many banks use this technique to protect user passwords/pins
> > within their on-line banking applications.
>
> Interesting.  In Canada, I know of no bank that actually utilizes Java
> applets to do this.  Is this "use" for customers OR for bank employees?
If
> its for employees I can understand and can envision it but if its for
> customers doing online banking I just don't see it happening.
>
> Out of curiosity - which banks do you know of that employ this?

Go to https://internet-banking.dbs.com.sg/
if you type in any random username at the first page you
will directed to the password page. You will see a small
java applet being loaded for the password text input box.

http://www.bcb.com.my (Malaysia's second largest bank)
also uses a java applet to protect user passwords on their
personal internet banking site.

>
> The way I see it Java applets have very limited use for Internet settings
> (Intranet settings are another story) and can't fathom that a bank would
> adopt such a strategy especially in light of Java applets questionable
> future in the "windoze" browser.
>

This is a very valid point. However, you can still write a simple
applet in Java 1.1. Most common day browsers (new and old)
come with a Java 1.1 compliant JVM (even IE6). No plug-in
required.

Carlo.