See below - On Tuesday, September 10, 2002, at 01:47 PM, Matthew Byng-Maddick wrote:
> ``Mainframe Authentication'' ? > > Are the passwords stored in plaintext on the server, do they travel in > plaintext or repeatable form over the wire? How can the machine > requesting > the auth from the mainframe be *sure* it's talking to the mainframe? > 99% > of hackers are insiders. Yes - on the mainframe. The weakness in this regard is not my script. Anyone with the right CMS access can read the OV files on the Mainframe - but hell, you know how weak IBM mainframes are :P LOL. > >> 3) After the hand-shake, then a userid lookup table located on the >> server (which is only readable by www server ID and only writable >> by root via cron - and then must be eye-balled by a human) is read >> to determine the appropriate access level. > > Seems reasonable, of course, it does mean that if you have a remote > root > then all bets are off. No, no telnet, smtp, ftp, et al -- the hacker would only be able to use HTTP (ssh is there but internal only.) I *would* really like to use HTTPS, but since the systems are internal no one here would allow me to spend the $300 a year in SSL. I then said I can do it for free - but back then there were RSA license problems and the college was "worried." Actually what they want to use is either a FP2k approach or a DAV/Dreamweaver approach. Go figure. :) >> 4) The system menu is created based up this ID. > > Are you sure that there's no way to trick it? I will create a non-authenticated test server for interested parties to play with. When I say non-authenticated you obviously will not do the m/f portion of the hand shake -- but that issue is minor. > >> 5) The security bit contains these items: cookie, time-based, and >> one-way crypt'ed access key -- this is > > Can both ends believe that this access key was fresh? (ie. can both > recreate > it, and know that there was something in there that must have been new > (eg, a random nonce that they supplied or a timestamp). What algorithm > are > you using for the ``one-way crypt''? If you're using crypt(3), be > warned > that it's breakable in about a day on a reasonable machine, and easily > parallelisable. Only the server can control the handshake and it must match a dynamically made key. > Do you make sure that the hash verifies? We shall see when I publish the code. :) > If I see a message (U,t,k) go past me on the wire, as a cookie, then > I'm > going to simulate a network fault, disconnecting the user, but not the > server. I'm then going to send the cookie (U,t,k) and (having faked the > IP address, too (this is doable with access to just one of the routers > in between the networks in question), then I can get into your system. Hmmm, maybe you will need to be a student/employee here (fccj.edu) then? LOL :P BTW - It is not true cookies, I just liberally used those for general meaning. > strikes me you're trying too hard to justify what you've done. That is likely what I am doing -- but since this program has become throw-away (IE, after this maintenance session no more patches) I have no problem allowing the public to look at it -- up until now all everyone was doing is thinking about possibilities. Let's put this into practice and see if it is breakable. Cheers! -Sx- :]
