RE: Where are all of the /400's going. (was RE: QUSER on ODBC requests) -- MIDRANGE-L

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

------------
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: 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
requests)


Walden,

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


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.