RE: Storing encrypted passwords on AS400

We use a file to store the user profiles and an validation list (*VLDL)
to store the passwords.  When we access them from the web sites, there
is a process that uses an RPG program to check the password in the
validation list and return a value with the success, failure, or
messages.  The RPG calls can be done in JDBC or direct calls.  The
validation list does not store the information, it stores a hash value
of the information -- so there is no way to see the passwords.  We also
have the password rules and login rules build in the security RPG
program.  It allows for a large amount of flexibility in controlling the
users on the web.

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Holm
Sent: Thursday, February 10, 2005 1:45 PM
To: java400-l@xxxxxxxxxxxx
Subject: Storing encrypted passwords on AS400 


Brett,

In terms of securing external web users and passwords.

1.  Here is an interesting new feature in V5R3.  I don't think it helps
you
as much since changing files is a pain for you given your customer base.
We
share similar constraints.

http://www.eservercomputing.com/iseries/articles/index.asp?id=950

2. Will standard OS400 file and object security help you in this case?
a. For example, could you secure the authentication/password file to
only
authorized userid and even further you can create logical files or views
over the physical removing the password fields and then allowing userid
the
use of the authentication file without seeing or using the password?
The
net is only authorized people will be able to see your passwords.  Your
connection pools uses an appropriate connection userid.   It is also
possible to "swap user profiles" using an API but I haven't tried this.

3. We also often use the JT400 JDBC against a DB2 file for
authentication
for "self service" applications.  It works very well for menu based data
driven authorization to particular operations and as you mentioned, we
can't
create user profiles for all web users since they are outside agents or
the
public in cases.  It can make your application user aware and allow easy
integration for self service  (i.e.  when an insurance agent signons
they
can only see the claims and policies that they are entitled to and NOT
other
agent info.

4. We make use of the JT400 connection property  "access=read only; "  (
I
think that is the property) which ensures ONLY read or query activity
can be
performed on this connection.

5. This to me is a particularly interesting topic since the majority of
web
applications I see on the 400 are for "self service" where the user's
don't
and can't have user profiles and therefore most applications require
being
aware of the current user to restrict data.




Thanks,  Paul Holm

Business: 760-432-0600   Home: 760-432-6550
PlanetJ - Makers of WOW  (AKA... WebSphere on Steroids)
www.gotwebdata.net




--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2/7/2005


-- 
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.