I'm not sure if you could keep ahead of the hackers, but I'd guess not. I
forgot about CPU serial number, but my intent is to include it in the tool
too (this isn't theory for me). Since we can safely say that this tool will
be used in the corporate environment I don't see a problem saying that the
PCs involved must allow the retrieval of the Intel serial number. AFAIK,
there is no way to emulate or override the CPUID machine instruction so this
would be very difficult to hack.

In a COM environment you'd use to tool something like:

Dim upm as new ProfileManager
Dim usr as string
Dim pwd as string

upm.GetProfile("AS400Name", "ServiceName")
Usr = Upm.User
Pwd = Upm.Password
Set upm = nothing

ServiceName is site-specific and could include things like "EndOfMonth
Accounting FTP" or "VRU Password Download" or whatever floats your boat.


Walden H Leverich III
Tech Software
(516)627-3800 x11

-----Original Message-----
From: jt [mailto:jt@ee.net]
Sent: Sunday, December 16, 2001 14:17
To: midrange-l@midrange.com
Subject: RE: Where are all of the /400's going. (was RE: QUSER on ODBC


Sounds like a keeper, to me...  Thanks...!

I would add processor serial number to the criteria to validate, at least
amongst 400s and other platforms that support this.  (Intel could have, but
was required by the user community to allow this feature to be disabled at
the user's option.)

But I'd like to take this to the next level...  (Again, don't know the
technology.)  I'd like to know more about the issues surrounding "Can it be
defeated, of course..."...

I think a part of the answer to this is collaboration amongst trusted
users...  Don't know any specifics, but it would seem that different methods
of security should be rotated, and continually evolved, to give the hackers
a moving target.  Spread the security methods around, along the lines that
the DNS addresses are spread through the Net (although at a MUCH quicker

My question is whether it's possible (theoretically AND practically) to keep
the security methods evolving fast enough to **simulate** staying one step
ahead of the hackers...?!?  (You'll always have a small minority of crooked
insiders, so you can only "simulate" staying ahead of the hackers, AFAIK.)

j "outta here for now!" t

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Walden H. Leverich
| Sent: Sunday, December 16, 2001 2:01 PM
| To: 'midrange-l@midrange.com'
| Subject: RE: QUSER on ODBC requests
| OK, so have the pc program ask the as/400 for a valid userid and
| password. The 400 could validate that the request was valid (remote
| ip, MAC, time,
| etc.) and return a user and password. A 5 second counter would then start
| and when it expires the password for that user would be changed. Can it be
| defeated, of course, but you'd have to set your ip, mac address
| and ask for
| the password at the specific date and time that's much more secure than a
| user called 'transfer' with a password of 'transfer'.
| -Walden
| ------------
| Walden H Leverich III
| President
| Tech Software
| (516)627-3800 x11
| WaldenL@TechSoftInc.com
| http://www.TechSoftInc.com
| -----Original Message-----
| From: jt [mailto:jt@ee.net]
| Sent: Friday, December 14, 2001 14:19
| To: midrange-l@midrange.com
| Subject: RE: QUSER on ODBC requests
| Rob,
| I'd sure like to see an acceptable solution to this one, myself...
| Hardcode passwords in code..: no good at all...!  But have password
| keyed in on every batch FTP and Domino app use...:  AIN'T GONNA
| HAPPEN...!

<huge snip of prior messages>

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.