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