Re: Password protection
Bruce Vining <[email protected]> Sat, 12 Jun 2010 13:05:51 -0500
| Newsgroups | gmane.comp.systems.as400.security |
|---|---|
| Message-ID | <[email protected]> |
Simon, Do you really need to determine today's password? One approach I've used in the past is calculate a new password (with the date not an input to your algorithm -- though I have found the microsecond counter of the Time of Day clock to be handy starting point, especially when manipulated a tad), encrypt "some data" using the password as a key (in your case I would suggest part of "some data" is the issuers current date), and store the returned encrypted value. For validation within the application re-encrypt the "some data" (now using the application current date as part of "some data") using the user provided password. Compare the generated value with the stored value. If the same then it's today's password. If it's not the same then it may or may not be a previous password, but it sure isn't todays password. The drawback of course is that you can't determine today's password. You can though verify that it's today's password (which I've usually found close enough). Hope this helps, Bruce On Fri, Jun 11, 2010 at 5:05 PM, Simon Coulter <shc-Q/[email protected]>wrote: > > Looking for suggestions: > > I want to protect access to an application via a password. I want the > password to automatically change daily. I want the application to be > able to determine today's password without having to read it from an > external source (i.e., algorithmically/programmatically derived). This > last requirement means: > > o no special profile with password changed daily > o no validation list use > o no encrypted password stored in external object such as *FILE or > *DTAARA > > I envisage: > o Application objects are *PUBLIC *EXCLUDE > o Application objects are authorised to a specific group profile > o Password generator is *PUBLIC *EXCLUDE > o Password generator is authorised to a specific profile (different > from the above) > > In actual use a user who is a member of the application group AND who > needs to use this particular application will request the password > from an authorised issuer. The issuer will use the password generator > to determine today's password. The user will then use the application. > > The "automatic daily change" requirement means the password generation/ > validation is tied to the date but obviously simple encryption linked > to the date will not be very secure nor will each daily password be > sufficiently different from the previous one. > > I have some ideas but thought I would see what others suggest--always > presuming you think this sufficiently interesting to bother with :) > > Regards, > Simon Coulter. > -------------------------------------------------------------------- > FlyByNight Software OS/400, i5/OS Technical Specialists > > http://www.flybynight.com.au/ > Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\ > Fax: +61 2 6657 8251 \ / > X > ASCII Ribbon campaign against HTML E-Mail / \ > -------------------------------------------------------------------- > > > > _______________________________________________ > This is the Security Administration on the AS400 / iSeries (Security400) > mailing list > To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected] > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/security400 > or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected] > Before posting, please take a moment to review the archives > at http://archive.midrange.com/security400. > > -- Regards, Bruce www.brucevining.com www.powercl.com _______________________________________________ This is the Security Administration on the AS400 / iSeries (Security400) mailing list To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected] To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/security400 or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected] Before posting, please take a moment to review the archives at http://archive.midrange.com/security400.