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

[Nikolaos Giannopoulos]

Carlo,


> -----Original Message-----
> From: advanced-java-bounces@lists.xcf.berkeley.edu
> [mailto:advanced-java-bounces@lists.xcf.berkeley.edu]On Behalf Of Carlo
>
>
> Surely from an e-commerce perspective security is also a big issue?

For sure.  To clarify - security is paramount.  The point is security like
optimization needs to be re-inforced where its needed most and using an
applet for our e-commerce app seems like the wrong area to focus *our*
efforts.  OS, network, appplication, and database security, not storing
unmasked card numbers, encrypting stored data, etc... rank higher on my list
than using an applet to encrypt data accross the channel.

With that said, we have used JavaScript to scramble password data - over
https - sent to a secure server in an Intranet environment so that the
password was not issued in plain text but it was understood that the
corporation had JavaScript support enabled AND that the encryption algorithm
was visible to all.


> 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.

Cool.  A banking application wherein someone could have full unfettered
access to someone's bank account is a different story and I could easily
understand the additional precautions.  Personally, I just wasn't aware of
many that resorted to this mechanism.


> 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.

I'm not up to speed on Java applet support on IE6.  Many moons ago I
remember talk of IE6 shipping without Java applet support installed as
default.  In addition, there's no guarantee that a 1.1 compliant VM will
exist in the next release of IE and considering IE's market share and MS
service pack - IE update - mechanisms Java 1.1 compliant support on the
browser could diminish rather rapidly.  Then there's the critical security
flaws in MS JVM that have been recently uncovered and the fact that applet
support can easily be disabled by users.  Throw in the fact that older
browsers (I'm not sure about newer ones) spawned a new VM each time and / or
caused a substantial delay for page load and the picture as a whole is not
very pretty.

In the end as long as there is a seamless fallback plan to the Java applet
mechanism then great but I'm still not convinced there's substantial
*security* bang for your buck involved here for *most* apps.

Thanks for the interesting feedback,

--Nikolaos