CEX cards support a hardware random number generator. Rob Schramm Senior Systems Consultant Imperium Group
On Tue, Nov 13, 2012 at 10:20 AM, Charles Mills <charl...@mcn.org> wrote: > Aha! > > Thanks. > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of michael.klaesc...@deutscherring-leben.de > Sent: Tuesday, November 13, 2012 1:44 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PassTicket usage logical flaw? > > For this case, there is a "NO REPLAY PROTECTION" option availabel. Check > the > APPLDATA field of your PTKTDATA profile. See chapter 7, Secured Signon > Function of RACF Security Administrators Guide for details. > > Cheers > Michael > > > > Von: Charles Mills <charl...@mcn.org> > An: IBM-MAIN@LISTSERV.UA.EDU > Datum: 2012-11-12 20:21 > Betreff: PassTicket usage logical flaw? > Gesendet von: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > > > 1. A given PassTicket may only be used once (source > http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom > . > ibm.cics.ts31.doc%2Fdfht5%2Ftopics%2Fdfht516.htm) > > 2. The PassTicket algorithm is deterministic: given the same time of day > (resolution one second), the same userid, the same application ID, and the > same secured signon application key, the algorithm will always produce the > same PassTicket (experimentation reveals this to be true). > > Consider a distributed application. Some large number of automated clients > sign on to some service at quasi-random intervals. A perfect application > for > PassTickets, right? But if a second client tries to log on within the same > TOD second as an earlier client, the sign-on will be rejected because the > generated PassTicket has already been used. What is the client to do? The > obvious answer is "wait a second and try again" but that approach has some > obvious shortcomings, one of which being there is no guarantee that THAT > PassTicket has not already been used. > > Yes, one solution would be a unique userid for each client, but suppose > this > is some "mass image rollout" application or there is some other reason why > unique userids are not desirable. > > What to do? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
