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