× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Walden,

Is that VB?

VERY interested in this tool, if you wanna elaborate.

==> But here's the thing:  (I'm NOT contradicting you, but just asking the
question.)  Has it ever been done AND/OR IS it theoretically possible:
COULD a 400 machine serial number be hacked...?!?  I guess I'm asking if
there's ANY WAY CONCEIVABLE?  I think this is a key question.

jt



| -----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 4:27 PM
| To: 'midrange-l@midrange.com'
| Subject: RE: Where are all of the /400's going. (was RE: QUSER on ODBC
| requests)
| Importance: High
|
|
| 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.
| _______________________________________________
| 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 ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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.