Hello all, That is an interesting point. However how many of you are still able to manage your passwords withiut using a password manager? I gave up many years ago. Regards Jack
On Wed, Feb 14, 2024, 15:13 Pommier, Rex <rpomm...@sfgmembers.com> wrote: > Steve, > > You make a good point about making security so onerous one can't use it. > At my employer, we use a third party cloud application (unnamed to conceal > the perpetrator) that doesn't use multi-factor yet. However their password > to get in has to be a minimum of 16 characters. No problem, right, just > use a passphrase type password. However, they also require upper, lower, > number, and special character. And they keep a history of 10 prior > passwords and require a change every 60 days. Their requirements pretty > much guarantee most people will be writing the passwords down, thus > bypassing a lot of the security they think they have. > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Steve Thompson > Sent: Wednesday, February 14, 2024 8:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: SDSF PS Command column > > Seymour, this is a very interesting observation you made. > > I'm now experiencing similar.... > > With a certain banking system we use, you logon, and then you have to > prove you are the person you say you are by providing more information. > While having 2 factor authentication. > > With a certain cell provider, you have to login, then provide your PIN, > then tell them your IMEI .... > > How many people have that information memorized? > > At some point we make being secure, *insecure,* because we won't talk to > you because we can't be sure you are who you say you are, even with 2 > factor authentication, and your password. > > Corporate paranoia. > > Steve Thompson > > On 2/13/2024 11:31 PM, Seymour J Metz wrote: > > The problem is not auditors; it is incompetent auditors. > > > > In the Army they taught us that preventing authorized access is a > security violation. An unthinking automatic timeout is a DOS attack when it > prevents running an annual job. > > > > -- > > Shmuel (Seymour J.) Metz > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!KjMRP1I > > xj6eLE0Fj!r3eDyWon_gy4rfKn8xiwhaf7-aligjydAdLV_p-26FcFegDBRI5PS9lR5OH9 > > bl_WBA3n8nAu4SOXe5hz$ > > עַם יִשְׂרָאֵל חַי > > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > ________________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > > behalf of Farley, Peter > > <0000031df298a9da-dmarc-requ...@listserv.ua.edu> > > Sent: Monday, February 5, 2024 12:27 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SDSF PS Command column > > > > I am constantly amazed at how much this whole “zero trust” meme is > violating the concept of sharing everything among application developers. > I for one have no qualms about any other application programmer at my shop > seeing any coding I am doing (though I might be occasionally embarrassed by > my own dumb mistakes). > > > > It is not “innocent” to share access to application programming > information and styles and pitfalls, it is crucial to application > programmer development and advancement. We learn from each other, > especially from sharing our mistakes as well as our best practices and > clever innovations. > > > > Add to that stupid security rules like “if you didn’t access this > resource for the last 180 days we revoke your access to that resource”, > which causes all kinds of headaches when you have to suddenly deal with > issues in a yearly weekend production process and you don’t have read > rights to the data files you need to view to resolve the issue and the > security team only works 9 to 5 weekdays and the on-call is out shopping > somewhere. > > > > Shakespeare was almost right – first get rid of all the auditors, the > lawyers are easy to deal with compared to them. > > > > Peter > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > > Behalf Of Paul Gilmartin > > Sent: Monday, February 5, 2024 11:02 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SDSF PS Command column > > > > > > On Mon, 5 Feb 2024 11:02:07 +0000, Rob Scott wrote: > > > >> ... > >> As to "why don't you just fix it ?"tstyle questions, we have to > consider quite a few compatibility issues across n-2 releases especially > when the "fix" requires changes to configuration and security ... > > Such as users' embedding cryptographic keys in commands? Ugh! > > > > > > > > UNIX arose in a more innocent age when no one worried much about such as: > > > > ls -lt /u > > > > > > > > -- > > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > > > > > ---------------------------------------------------------------------- > > 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 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > ---------------------------------------------------------------------- > 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
