Re: No BPX-level interface for __passwd_applid? Was: Re: Code to verify LOGON password
It's probably a bug in SORT. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Thomas David Rivers Sent: Friday, January 15, 2021 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: No BPX-level interface for __passwd_applid? Was: Re: Code to verify LOGON password [External Email. Exercise caution when clicking links or opening attachments.] Kirk Wolf wrote: >/* > Check password for a userid. > Note: requires program-controlled environment > To build: > c99 -o checkpass checkpass.c i > extattr +p checkpass >*/ >#define _POSIX_SOURCE >#include >#include >#include >#include >#include >#include > >int main(int argc, char** argv) { > > if (argc != 3) { >fprintf(stderr, "Syntax: checkpass \n"); >return 1; > } > setenv("_EDC_ADD_ERRNO2", "1", 1); > if (__passwd(argv[1], argv[2], NULL)) { >if (errno == EACCES) { > fprintf(stderr, "password not authorized\n"); > return 2; >} else { > fprintf(stderr, "__passwd() - %s\n", strerror(errno)); > return 3; >} > } > return 0; /* no message - password valid */ } > >On Fri, Jan 8, 2021 at 11:19 AM Sam Golob wrote: > > > I took a moment to dig into the BPX interface for this, I found BPX1PWD, which documents __passwd(). It also documents __passwd_applid(), but provides no interface information for it (although it discusses it as if it were a different interface) and provides alternatives to using the __passwd_applid BPX interface if you wanted to set fields in the BPX thread info yourself. Seems like there is some doc confusion there... I didn't find a separate BPX offset definition for __passwd_applid(). Is the _only_ way to specify the APPLID via directly setting fields in the BPXYTHLI thread-info or is there an actual BPX-level interface for this? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
No BPX-level interface for __passwd_applid? Was: Re: Code to verify LOGON password
Kirk Wolf wrote: /* Check password for a userid. Note: requires program-controlled environment To build: c99 -o checkpass checkpass.c i extattr +p checkpass */ #define _POSIX_SOURCE #include #include #include #include #include #include int main(int argc, char** argv) { if (argc != 3) { fprintf(stderr, "Syntax: checkpass \n"); return 1; } setenv("_EDC_ADD_ERRNO2", "1", 1); if (__passwd(argv[1], argv[2], NULL)) { if (errno == EACCES) { fprintf(stderr, "password not authorized\n"); return 2; } else { fprintf(stderr, "__passwd() - %s\n", strerror(errno)); return 3; } } return 0; /* no message - password valid */ } On Fri, Jan 8, 2021 at 11:19 AM Sam Golob wrote: I took a moment to dig into the BPX interface for this, I found BPX1PWD, which documents __passwd(). It also documents __passwd_applid(), but provides no interface information for it (although it discusses it as if it were a different interface) and provides alternatives to using the __passwd_applid BPX interface if you wanted to set fields in the BPX thread info yourself. Seems like there is some doc confusion there... I didn't find a separate BPX offset definition for __passwd_applid(). Is the _only_ way to specify the APPLID via directly setting fields in the BPXYTHLI thread-info or is there an actual BPX-level interface for this? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
Even there are tasks that require access to the RACF DB, they can probably be done under a userid to which you have proxy access. Security constraints don't just protect against malice, they can also protect against some mistakes. Update access to what resource? I'm not aware of any command in ACF2, RACF or TSS that requires authority to the security data base. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob Bridges [robhbrid...@gmail.com] Sent: Thursday, January 14, 2021 7:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Code to verify LOGON password It isn't just UACC(READ) or UID(*). Why does ~anyone~ have read access to the database? (To say nothing of update.) At a client I served a while back, I pointed out that a lot of people had read access, and quite a few had update. They argued that it was necessary so that their admins could do their jobs. Apparently they believed that the admin needed update access to change permissions, create profiles etc. Now, it happened that was a TSS shop. But surely the answer is the same in RACF? I don't need update (or even read) access to the RACF database; when I issue a RACF command, RACF determines whether I have the authority and then executes the command under the authority of its own ID, whichever one runs the STC. My own rule (when I'm allowed my way) is that NO ONE has access to the database, except a system programmer doing migrations to a new version; for that purpose I'll grant the necessary access for a defined period, say two months, extendible upon request, but expiring automatically. The Logica breakin, as I understand it, started with the theft of the password of an ID that had read access to the RACF database. The bad guys then downloaded it and applied CRACF to it. Forensic investigators afterward tested the same utility and were able to get 10 or 20 thousand passwords from it in the first day of running on an ordinary PC. (Going by memory, but I think it's about right.) --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* We must picture Hell as a state where everyone is perpetually concerned about his own dignity and advancement, where everyone has a grievance, and where eveyone lives the deadly serious passions of envy, self-importance, and resentment. -C S Lewis, preface to _The Screwtape Letters_ */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Monday, January 11, 2021 11:44 https://secure-web.cisco.com/1iesSYf-0P7Z111PONKdFPj51TIo8fUKnSxQgEv6-FOvP_cg1RdEOEJAsogbGQKckKIinPKkXvRGW4R6-8YWVzKpOgxlQ-t0RU5zq129AKX6JI6RZRSI_GG4AT2ZoGcDoqCEFD0e6_XSmRBLoWIBP9e49maT1IrMAtyFtp3VtHN7RSNgCbi8bYYcKAANHTzrqOhrql_lVCftNpWRfrPn_bATNcadHXHyBI0u0SAQuFOd31cunlivurVjnb_ixTIsrUwO4PviyoJGbZrl4kcMojaMqtk2RH9DtaNZ11cQAKUjqkWdTiemtTrBENm27KHjdjC-Fc0ZnI1dTXx_VGDeHQzCamRdMasHFow5N8G573IDkHGxLl3D6kFSXYu4wcbd6fMAcZGL7dh5tUsfHh1fEtN_H-ogLpK0kPYA95dJCtFF0eHvOzcoxJqZZTAzXuLdK/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJohn_the_Ripper There is a downloadable plugin for RACF -- old RACF hashing only, I *think*. No one "gives" their RACF DB to anyone (I would hope). The problem -- and everyone reading this who is not sure about their RACF DB should go check right now -- is UACC or USERID(*) READ access to the RACF DB *or its backup*. If I can download your RACF DB and attack it off-platform I can defeat any "revoke the userid after 'n' tries" that you have in place. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, January 11, 2021 10:07 That's what we call brute force attack. There is no way to protect against it ...or maybe there are some things to help. 1. Do not give your RACF db to hackers. Never --- W dniu 11.01.2021 o 15:39, Tom Brennan pisze: > Isn't there a program someone wrote (talked about here many years ago) > that can try various passwords until something matches the hashed > value? If that's the case, hashing doesn't really do as much good as > people think it does, once someone gets hold of the RACF dataset of > course. -- 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
Re: Code to verify LOGON password
It isn't just UACC(READ) or UID(*). Why does ~anyone~ have read access to the database? (To say nothing of update.) At a client I served a while back, I pointed out that a lot of people had read access, and quite a few had update. They argued that it was necessary so that their admins could do their jobs. Apparently they believed that the admin needed update access to change permissions, create profiles etc. Now, it happened that was a TSS shop. But surely the answer is the same in RACF? I don't need update (or even read) access to the RACF database; when I issue a RACF command, RACF determines whether I have the authority and then executes the command under the authority of its own ID, whichever one runs the STC. My own rule (when I'm allowed my way) is that NO ONE has access to the database, except a system programmer doing migrations to a new version; for that purpose I'll grant the necessary access for a defined period, say two months, extendible upon request, but expiring automatically. The Logica breakin, as I understand it, started with the theft of the password of an ID that had read access to the RACF database. The bad guys then downloaded it and applied CRACF to it. Forensic investigators afterward tested the same utility and were able to get 10 or 20 thousand passwords from it in the first day of running on an ordinary PC. (Going by memory, but I think it's about right.) --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* We must picture Hell as a state where everyone is perpetually concerned about his own dignity and advancement, where everyone has a grievance, and where eveyone lives the deadly serious passions of envy, self-importance, and resentment. -C S Lewis, preface to _The Screwtape Letters_ */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Monday, January 11, 2021 11:44 https://en.wikipedia.org/wiki/John_the_Ripper There is a downloadable plugin for RACF -- old RACF hashing only, I *think*. No one "gives" their RACF DB to anyone (I would hope). The problem -- and everyone reading this who is not sure about their RACF DB should go check right now -- is UACC or USERID(*) READ access to the RACF DB *or its backup*. If I can download your RACF DB and attack it off-platform I can defeat any "revoke the userid after 'n' tries" that you have in place. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, January 11, 2021 10:07 That's what we call brute force attack. There is no way to protect against it ...or maybe there are some things to help. 1. Do not give your RACF db to hackers. Never --- W dniu 11.01.2021 o 15:39, Tom Brennan pisze: > Isn't there a program someone wrote (talked about here many years ago) > that can try various passwords until something matches the hashed > value? If that's the case, hashing doesn't really do as much good as > people think it does, once someone gets hold of the RACF dataset of > course. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
W dniu 12.01.2021 o 06:42, Timothy Sipples pisze: Radoslaw Skorupka wrote: That's what we call brute force attack. There is no way to protect against it ...or maybe there are some things to help. 1. Do not give your RACF db to hackers. Never. 2. Enforce periodic password change. 3. Use KDFAES. 4. Use passphrases. Here are some more examples for your list: 5. Don't grant overly generous permissions. Revoke permissions faithfully and promptly when required. 6. IBM Z Multi-Factor Authentication. 7. Use excellent data access management and Security Information and Event Management (SIEM) solutions. 8. "Stay sharp." Invest in talented security professionals, including in their ongoing skills development. Hire other talented security people to conduct periodic audits. 9. Stay at least reasonably current with software releases, including z/OS releases. Have and follow a reasonable preventive maintenance plan, including for security and integrity updates. 10. Use strong, properly implemented network encryption so that credentials aren't flying across any LAN or WAN in cleartext. z/OS Encryption Readiness Technology (zERT), a standard feature included with the base z/OS operating system starting with z/OS 2.3, can help identify gaps. Good points. IMHO the most important is 8. Of course it is not about RACF, it is about people. However no technology would help if the only effort was to buy it, but no necessaruly well implemented. Uneducated, lazy people, overloaded staff, lack of interest from management lead to mistakes, even serious neglects. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
W dniu 11.01.2021 o 17:44, Charles Mills pisze: https://en.wikipedia.org/wiki/John_the_Ripper There is a downloadable plugin for RACF -- old RACF hashing only, I *think*. @R.S. writes 1. Do not give your RACF db to hackers. Never. No one "gives" their RACF DB to anyone (I would hope). The problem -- and everyone reading this who is not sure about their RACF DB should go check right now -- is UACC or USERID(*) READ access to the RACF DB *or its backup*. If I can download your RACF DB and attack it off-platform I can defeat any "revoke the userid after 'n' tries" that you have in place. Charles, You missed the fine print between the lines : IRONY ;-) Of course matter of backup copies, user revoking, etc. was discussed ad infinitum. Of course it is important, but a little bit not closely related to discussed details in this thread. Regarding the ripper - There is password cracker for z/OS. You need APF update, dictionaries (or program generating passwords) and cpu cycles. APF update? Same configuration mistake as READ for RACF db. Despite of cracker implementation, KDFAES plus passphrases plus (included in passphrases) rules for password complexity make cracking much less efficient. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
Radoslaw Skorupka wrote: >That's what we call brute force attack. >There is no way to protect against it ...or maybe there are some >things to help. >1. Do not give your RACF db to hackers. Never. >2. Enforce periodic password change. >3. Use KDFAES. >4. Use passphrases. Here are some more examples for your list: 5. Don't grant overly generous permissions. Revoke permissions faithfully and promptly when required. 6. IBM Z Multi-Factor Authentication. 7. Use excellent data access management and Security Information and Event Management (SIEM) solutions. 8. "Stay sharp." Invest in talented security professionals, including in their ongoing skills development. Hire other talented security people to conduct periodic audits. 9. Stay at least reasonably current with software releases, including z/OS releases. Have and follow a reasonable preventive maintenance plan, including for security and integrity updates. 10. Use strong, properly implemented network encryption so that credentials aren't flying across any LAN or WAN in cleartext. z/OS Encryption Readiness Technology (zERT), a standard feature included with the base z/OS operating system starting with z/OS 2.3, can help identify gaps. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
https://en.wikipedia.org/wiki/John_the_Ripper There is a downloadable plugin for RACF -- old RACF hashing only, I *think*. @R.S. writes > 1. Do not give your RACF db to hackers. Never. No one "gives" their RACF DB to anyone (I would hope). The problem -- and everyone reading this who is not sure about their RACF DB should go check right now -- is UACC or USERID(*) READ access to the RACF DB *or its backup*. If I can download your RACF DB and attack it off-platform I can defeat any "revoke the userid after 'n' tries" that you have in place. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Monday, January 11, 2021 6:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Code to verify LOGON password Isn't there a program someone wrote (talked about here many years ago) that can try various passwords until something matches the hashed value? If that's the case, hashing doesn't really do as much good as people think it does, once someone gets hold of the RACF dataset of course. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
Yes - we used one years ago - as part of a govt audit - one year it got accidentally run multiple times and the multiple failed passwords exceeded the RACF/ACF2 threshhold - thousands of accounts were locked until unlocked the next day ... I do not have firsthand knowledge of the name of the product, only that it existed Chris Hoelscher Lead Sys DBA IBM Global Technical Services on assignmemt to Humana Inc. T 502.476.2538 or 502.407.7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Monday, January 11, 2021 9:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Code to verify LOGON password [External Email: Use caution with links and attachments] Isn't there a program someone wrote (talked about here many years ago) that can try various passwords until something matches the hashed value? If that's the case, hashing doesn't really do as much good as people think it does, once someone gets hold of the RACF dataset of course. On 1/10/2021 7:57 PM, Timothy Sipples wrote: > Here's a pedantic point: RACF doesn't actually know what the user's > password is -- thank goodness. RACF can only determine whether a > particular password or passphrase string mathematically corresponds to > the hashed value (derived from previous input) that RACF stores. True, > good hashing functions minimize collisions, and RACF uses good hashing > functions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
That's what we call brute force attack. There is no way to protect against it ...or maybe there are some things to help. 1. Do not give your RACF db to hackers. Never. 2. Enforce periodic password change. 3. Use KDFAES. 4. Use passphrases. First is obvious. Effectiveness of the second is disputable, but it rather won't help hackers. The idea is to a) give less time for password cracking. b) give less time for using of intercepted user/password. c) give less possibilities to peek co-workers password (next letters). There is also disadvantage: too complex and too frequently changed password lead to yellow stickers. Third can be surprising for some people, but this method provide much more time consuming method of password hashing. Much more is tens of thousands. That means brute force attack would take tens of thousands times more time. It is still finite, but much longer. Fourth method provide much more space for passwords. Let's forget about social hacking for a while, just "blind" brute force. To simplify - 8-char password could mean 39^8 combinations (roughly, these calculations are not exact). 16-char password is 39^8 * 39^8 - that's 5 352 009 260 481 times more combinations. And 24-char password gives 28 644 003 124 274 380 508 351 361 times more. The above is not exact analysis. Password and passphrase space is limited by some rules, but there are also shorter passwords and much more lenghts of passphrases - 100,99,98,97,96...11,10,9. A lot of. My €0.02 -- Radoslaw Skorupka Lodz, Poland W dniu 11.01.2021 o 15:39, Tom Brennan pisze: Isn't there a program someone wrote (talked about here many years ago) that can try various passwords until something matches the hashed value? If that's the case, hashing doesn't really do as much good as people think it does, once someone gets hold of the RACF dataset of course. On 1/10/2021 7:57 PM, Timothy Sipples wrote: Here's a pedantic point: RACF doesn't actually know what the user's password is -- thank goodness. RACF can only determine whether a particular password or passphrase string mathematically corresponds to the hashed value (derived from previous input) that RACF stores. True, good hashing functions minimize collisions, and RACF uses good hashing functions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.
Re: Code to verify LOGON password
Isn't there a program someone wrote (talked about here many years ago) that can try various passwords until something matches the hashed value? If that's the case, hashing doesn't really do as much good as people think it does, once someone gets hold of the RACF dataset of course. On 1/10/2021 7:57 PM, Timothy Sipples wrote: Here's a pedantic point: RACF doesn't actually know what the user's password is -- thank goodness. RACF can only determine whether a particular password or passphrase string mathematically corresponds to the hashed value (derived from previous input) that RACF stores. True, good hashing functions minimize collisions, and RACF uses good hashing functions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
Sam Golob asked: >Does anyone have user-written code for RACF, so that if the user >types in a password, the code will verify if it is the user's actual >LOGON password? Here's a pedantic point: RACF doesn't actually know what the user's password is -- thank goodness. RACF can only determine whether a particular password or passphrase string mathematically corresponds to the hashed value (derived from previous input) that RACF stores. True, good hashing functions minimize collisions, and RACF uses good hashing functions. I echo the other poster's cautions. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
What is wrong with RACROUTE REQUEST=VERIFY,ENVIR=CREATE,ACEE=@ACEE followed by RACROUTE REQUEST=VERIFY,ENVIR=DELETE,ACEE=@ACEE if the create worked? Should work on all security systems. On Sat, 9 Jan 2021 20:03:07 -0500 Sam Golob wrote: :>Dear Folks, :> :> I am just trying to get a very old program to work. It is so old, :>that it mucks with the TSB password field, and I don't want to deal with :>that. I don't care to reveal the password anywhere. I just want the :>user to enter a password, and the security system should say "GO" or :>"NOGO". That's all. :> :> Thanks for all your replies. Be well and safe. :> :>Sincerely, Sam :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
RACF Support for IBM Multi-Factor Authentication for z/OS (IBM MFA): https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.izsm100/abstract.htm Abstract for RACF Support for IBM Multi-Factor Authentication for z/OS (IBM MFA)<https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.izsm100/abstract.htm> Purpose of this information This information is a collection of all of the information that you need to understand and exploit the IBM Multi-Factor Authentication for z/OS (IBM MFA). Some of the information also exists elsewhere in the z/OS library. www.ibm.com From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Saturday, January 9, 2021 11:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Code to verify LOGON password On Sat, 9 Jan 2021 00:12:07 -0600, Brian Westerman wrote: > >With some restrictions, I think that just issuing the RACROUT request=verify, >would be okay. There should probably be some mechanism to revoke the ID if >there are two many guesses though. > Among these, I wonder about MFA. Does RACF support MFA? Why is sftp unable to mask the password entry on a 3270 while FTP does so readily? I once submitted an SR that tcsetattr() suppresses ECHO on a linemode terminal but not a 3270. IBM rejected it. -- gil -- 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
Re: Code to verify LOGON password
On Sat, 9 Jan 2021 00:12:07 -0600, Brian Westerman wrote: > >With some restrictions, I think that just issuing the RACROUT request=verify, >would be okay. There should probably be some mechanism to revoke the ID if >there are two many guesses though. > Among these, I wonder about MFA. Does RACF support MFA? Why is sftp unable to mask the password entry on a 3270 while FTP does so readily? I once submitted an SR that tcsetattr() suppresses ECHO on a linemode terminal but not a 3270. IBM rejected it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
You're right... and I'm sure Skip Robinson can remember the time we both were surprised when an internal penetration test revoked a particular RACF id simply because those scripts tried multiple passwords and failed. Guess what, it was FTP like your concerns! The fun part is that only about a week before (for an unrelated issue) we had added a WTO to an FTP logon exit/hook that spit out the client's IP address. So we tracked down the people doing the test and probably looked pretty good to our managers - just don't tell them it was sheer luck. And with my RACF SPECIAL id, I do remember logging on to say, TSO, and getting stuck for no visible reason until somebody noticed the RACF console message you mentioned. Our operators would "never" respond without calling us, but yeah, I can see another sysprog working on some other issue responding because they were thinking it was their problem. But I think that just gives you another try, and it's way too slow for brute force. On 1/9/2021 8:00 AM, Joel C. Ewing wrote: But keep in mind that while revoking a userid after excessive bad password attempts may prevent a password check routine being used to compromise a specific userid, at the same time that feature enables its use for a denial of service attack to disable a specific userid, or worse, to disable many accounts in a short span of time if the wrong party gains access to the interface and either knows or can guess many userids. You still need to further restrict its use in some way. Out of an abundance of caution, when z/OS FTP became available we used an FTP exit to block FTP logon attempts from userids that had no business using FTP (CICS-only userids, started task userid's etc), just to preclude the possible revocation of production userids from the intentional or accidental inappropriate use of an FTP script or FTP application on some corporate workstation. There used to be a console message reply required before your RACF Admin users could be disabled in this way, but if some operator blindly gave an inappropriate response for your last RACF Admin userid, you would still be SOL. I vaguely recall we had some console automation to preclude that possibility. Joel C Ewing On 1/9/21 1:46 AM, Tom Brennan wrote: I seem to remember the verify processing bumping up the password fail count and revoking the id without any additional logic - even returning codes indicating those issues. But it's probably been 20 years since I coded such things, and those brain cells have long since been loaded with other data. I shouldn't have watched so many Simpsons episodes. On 1/8/2021 10:12 PM, Brian Westerman wrote: I think if you were just going to take the password and verify that it was correct (or not), that shouldn't be a big issue. Although there should be some way to keep the user from using it to "guess" other people's passwords. Maybe a limit on tries, or a way to inform someone that they tried it more than once in a certain period of time. With some restrictions, I think that just issuing the RACROUT request=verify, would be okay. There should probably be some mechanism to revoke the ID if there are two many guesses though. Brian On Fri, 8 Jan 2021 21:02:50 +, Jousma, David wrote: Sam, I'm curious as to the usage scenario? This almost sounds like a security problem? So you take a users password input, go ask SAF if correct? Sounds like a man-in-the-middle situation? _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sam Golob Sent: Friday, January 8, 2021 12:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Code to verify LOGON password **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Dear Folks, Does anyone have user-written code for RACF, so that if the user types in a password, the code will verify if it is the user's actual LOGON password? I'd like to see code that does this, for ACF2 and Top Secret as well, but I'm primarily interested in RACF. Thank you very much. All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
But keep in mind that while revoking a userid after excessive bad password attempts may prevent a password check routine being used to compromise a specific userid, at the same time that feature enables its use for a denial of service attack to disable a specific userid, or worse, to disable many accounts in a short span of time if the wrong party gains access to the interface and either knows or can guess many userids. You still need to further restrict its use in some way. Out of an abundance of caution, when z/OS FTP became available we used an FTP exit to block FTP logon attempts from userids that had no business using FTP (CICS-only userids, started task userid's etc), just to preclude the possible revocation of production userids from the intentional or accidental inappropriate use of an FTP script or FTP application on some corporate workstation. There used to be a console message reply required before your RACF Admin users could be disabled in this way, but if some operator blindly gave an inappropriate response for your last RACF Admin userid, you would still be SOL. I vaguely recall we had some console automation to preclude that possibility. Joel C Ewing On 1/9/21 1:46 AM, Tom Brennan wrote: > I seem to remember the verify processing bumping up the password fail > count and revoking the id without any additional logic - even > returning codes indicating those issues. But it's probably been 20 > years since I coded such things, and those brain cells have long since > been loaded with other data. I shouldn't have watched so many > Simpsons episodes. > > On 1/8/2021 10:12 PM, Brian Westerman wrote: >> I think if you were just going to take the password and verify that >> it was correct (or not), that shouldn't be a big issue. Although >> there should be some way to keep the user from using it to "guess" >> other people's passwords. Maybe a limit on tries, or a way to inform >> someone that they tried it more than once in a certain period of time. >> >> With some restrictions, I think that just issuing the RACROUT >> request=verify, would be okay. There should probably be some >> mechanism to revoke the ID if there are two many guesses though. >> >> Brian >> >> >> On Fri, 8 Jan 2021 21:02:50 +, Jousma, David >> wrote: >> >>> Sam, >>> >>> I'm curious as to the usage scenario? This almost sounds like a >>> security problem? So you take a users password input, go ask SAF if >>> correct? Sounds like a man-in-the-middle situation? >>> >>> _ >>> >>> Dave Jousma >>> AVP | Director, Technology Engineering >>> >>> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand >>> Rapids, MI 49546 >>> 616.653.8429 | fax: 616.653.2717 >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Sam Golob >>> Sent: Friday, January 8, 2021 12:19 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Code to verify LOGON password >>> >>> **CAUTION EXTERNAL EMAIL** >>> >>> **DO NOT open attachments or click on links from unknown senders or >>> unexpected emails** >>> >>> Dear Folks, >>> >>> Does anyone have user-written code for RACF, so that if the >>> user types in a password, the code will verify if it is the user's >>> actual LOGON password? >>> >>> I'd like to see code that does this, for ACF2 and Top Secret as >>> well, but I'm primarily interested in RACF. >>> >>> Thank you very much. All the best of everything to all of you. >>> >>> Sincerely, Sam >>> >>> >>> >>> -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
If the question relates to CICS, you can use the VERIFY PASSWORD exec interface call. *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Jan 9, 2021 at 9:46 AM Tom Brennan wrote: > I seem to remember the verify processing bumping up the password fail > count and revoking the id without any additional logic - even returning > codes indicating those issues. But it's probably been 20 years since I > coded such things, and those brain cells have long since been loaded > with other data. I shouldn't have watched so many Simpsons episodes. > > On 1/8/2021 10:12 PM, Brian Westerman wrote: > > I think if you were just going to take the password and verify that it > was correct (or not), that shouldn't be a big issue. Although there should > be some way to keep the user from using it to "guess" other people's > passwords. Maybe a limit on tries, or a way to inform someone that they > tried it more than once in a certain period of time. > > > > With some restrictions, I think that just issuing the RACROUT > request=verify, would be okay. There should probably be some mechanism to > revoke the ID if there are two many guesses though. > > > > Brian > > > > > > On Fri, 8 Jan 2021 21:02:50 +, Jousma, David > wrote: > > > >> Sam, > >> > >> I'm curious as to the usage scenario? This almost sounds like a > security problem? So you take a users password input, go ask SAF if > correct? Sounds like a man-in-the-middle situation? > >> > >> > _ > >> Dave Jousma > >> AVP | Director, Technology Engineering > >> > >> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > Rapids, MI 49546 > >> 616.653.8429 | fax: 616.653.2717 > >> > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf Of Sam Golob > >> Sent: Friday, January 8, 2021 12:19 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Code to verify LOGON password > >> > >> **CAUTION EXTERNAL EMAIL** > >> > >> **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > >> > >> Dear Folks, > >> > >> Does anyone have user-written code for RACF, so that if the user > types in a password, the code will verify if it is the user's actual LOGON > password? > >> > >> I'd like to see code that does this, for ACF2 and Top Secret as > well, but I'm primarily interested in RACF. > >> > >> Thank you very much. All the best of everything to all of you. > >> > >> Sincerely, Sam > >> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > **CAUTION EXTERNAL EMAIL** > >> > >> **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > >> > >> This e-mail transmission contains information that is confidential and > may be privileged. It is intended only for the addressee(s) named above. > If you receive this e-mail in error, please do not read, copy or > disseminate it in any manner. If you are not the intended recipient, any > disclosure, copying, distribution or use of the contents of this > information is prohibited. Please reply to the message immediately by > informing the sender that the message was misdirected. After replying, > please erase it from your computer system. Your assistance in correcting > this error is appreciated. > >> > >> > >> -- > >> 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
I seem to remember the verify processing bumping up the password fail count and revoking the id without any additional logic - even returning codes indicating those issues. But it's probably been 20 years since I coded such things, and those brain cells have long since been loaded with other data. I shouldn't have watched so many Simpsons episodes. On 1/8/2021 10:12 PM, Brian Westerman wrote: I think if you were just going to take the password and verify that it was correct (or not), that shouldn't be a big issue. Although there should be some way to keep the user from using it to "guess" other people's passwords. Maybe a limit on tries, or a way to inform someone that they tried it more than once in a certain period of time. With some restrictions, I think that just issuing the RACROUT request=verify, would be okay. There should probably be some mechanism to revoke the ID if there are two many guesses though. Brian On Fri, 8 Jan 2021 21:02:50 +, Jousma, David wrote: Sam, I'm curious as to the usage scenario? This almost sounds like a security problem? So you take a users password input, go ask SAF if correct? Sounds like a man-in-the-middle situation? _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sam Golob Sent: Friday, January 8, 2021 12:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Code to verify LOGON password **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Dear Folks, Does anyone have user-written code for RACF, so that if the user types in a password, the code will verify if it is the user's actual LOGON password? I'd like to see code that does this, for ACF2 and Top Secret as well, but I'm primarily interested in RACF. Thank you very much. All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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
Re: Code to verify LOGON password
I think if you were just going to take the password and verify that it was correct (or not), that shouldn't be a big issue. Although there should be some way to keep the user from using it to "guess" other people's passwords. Maybe a limit on tries, or a way to inform someone that they tried it more than once in a certain period of time. With some restrictions, I think that just issuing the RACROUT request=verify, would be okay. There should probably be some mechanism to revoke the ID if there are two many guesses though. Brian On Fri, 8 Jan 2021 21:02:50 +, Jousma, David wrote: >Sam, > >I'm curious as to the usage scenario? This almost sounds like a security >problem? So you take a users password input, go ask SAF if correct? Sounds >like a man-in-the-middle situation? > >_ >Dave Jousma >AVP | Director, Technology Engineering > >Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, >MI 49546 >616.653.8429 | fax: 616.653.2717 > > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Sam Golob >Sent: Friday, January 8, 2021 12:19 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Code to verify LOGON password > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >Dear Folks, > > Does anyone have user-written code for RACF, so that if the user types in > a password, the code will verify if it is the user's actual LOGON password? > > I'd like to see code that does this, for ACF2 and Top Secret as well, but > I'm primarily interested in RACF. > > Thank you very much. All the best of everything to all of you. > >Sincerely, Sam > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL >EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >This e-mail transmission contains information that is confidential and may be >privileged. It is intended only for the addressee(s) named above. If you >receive this e-mail in error, please do not read, copy or disseminate it in >any manner. If you are not the intended recipient, any disclosure, copying, >distribution or use of the contents of this information is prohibited. Please >reply to the message immediately by informing the sender that the message was >misdirected. After replying, please erase it from your computer system. Your >assistance in correcting this error is appreciated. > > >-- >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
Re: Code to verify LOGON password
Sam, I'm curious as to the usage scenario? This almost sounds like a security problem? So you take a users password input, go ask SAF if correct? Sounds like a man-in-the-middle situation? _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sam Golob Sent: Friday, January 8, 2021 12:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Code to verify LOGON password **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Dear Folks, Does anyone have user-written code for RACF, so that if the user types in a password, the code will verify if it is the user's actual LOGON password? I'd like to see code that does this, for ACF2 and Top Secret as well, but I'm primarily interested in RACF. Thank you very much. All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
/* Check password for a userid. Note: requires program-controlled environment To build: c99 -o checkpass checkpass.c i extattr +p checkpass */ #define _POSIX_SOURCE #include #include #include #include #include #include int main(int argc, char** argv) { if (argc != 3) { fprintf(stderr, "Syntax: checkpass \n"); return 1; } setenv("_EDC_ADD_ERRNO2", "1", 1); if (__passwd(argv[1], argv[2], NULL)) { if (errno == EACCES) { fprintf(stderr, "password not authorized\n"); return 2; } else { fprintf(stderr, "__passwd() - %s\n", strerror(errno)); return 3; } } return 0; /* no message - password valid */ } On Fri, Jan 8, 2021 at 11:19 AM Sam Golob wrote: > Dear Folks, > > Does anyone have user-written code for RACF, so that if the user > types in a password, the code will verify if it is the user's actual > LOGON password? > > I'd like to see code that does this, for ACF2 and Top Secret as > well, but I'm primarily interested in RACF. > > Thank you very much. All the best of everything to all of you. > > Sincerely, Sam > > > -- > 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
Re: Code to verify LOGON password
On Fri, 8 Jan 2021 at 12:19, Sam Golob wrote: > Does anyone have user-written code for RACF, so that if the user > types in a password, the code will verify if it is the user's actual > LOGON password? More detailed specs, please. Are you fundamentally looking for sample code to learn from, or something to [adapt and] use as-is? Programming language? Execution environment? (TSO session? UNIX session? Some other environment?) Is this a program to run in an existing session to verify that the user at the keyboard knows the password that was used at logon? (TSS has a TSO command to lock the screen and prompt for the password upon resuming. It would be easy enough to write a similar command for any of the security systems.) Or is it a program that accepts both a userid and password at the keyboard (or in a batch job), and verifies that they are a good match? Or something else I'm not thinking of? Any program that accepts userids and passwords needs to have controls to prevent its use to try many passwords without penalty. Generally the required security system calls require at least an APF authorized state to make this query, for the reason above. > I'd like to see code that does this, for ACF2 and Top Secret as > well, but I'm primarily interested in RACF. If you use the SAF (RACROUTE REQUEST=VERIFY) approach, it should work identically for all three security systems. Your code has to decide if what you are verifying is a password or a phrase. If you are using an LE language (C, PL/I, ...) there is a library function __passwd(...) to do this. If you are writing in assembler, probably the easiest to use is IRRSPW00, documented in the RACF Callable Services book. IRRSPW00 may not work in the CA security systems - I'm not sure. Both the above assume password vs phrase based on the length. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
Something about this makes me nervous. At a minimum you need @Gils's suggestion that the password not exist in your address space (or if it does you really, really know what you are doing). And you need to make certain your code is not a vehicle for someone to mount a brute force attack while avoiding revocation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Golob Sent: Friday, January 8, 2021 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Code to verify LOGON password Dear Folks, Does anyone have user-written code for RACF, so that if the user types in a password, the code will verify if it is the user's actual LOGON password? I'd like to see code that does this, for ACF2 and Top Secret as well, but I'm primarily interested in RACF. Thank you very much. All the best of everything to all of you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Code to verify LOGON password
The code I have was / is very old for mid 90's to validate CATIA userid's using RACF, if you want I can provide as is Carmen Vitullo -Original Message- From: Sam To: IBM-MAIN Date: Friday, 8 January 2021 11:20 AM CST Subject: Code to verify LOGON password Dear Folks, Does anyone have user-written code for RACF, so that if the user types in a password, the code will verify if it is the user's actual LOGON password? I'd like to see code that does this, for ACF2 and Top Secret as well, but I'm primarily interested in RACF. Thank you very much. All the best of everything to all of you. Sincerely, Sam -- 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
Re: Code to verify LOGON password
On Fri, 8 Jan 2021 12:19:28 -0500, Sam Golob wrote: > > Does anyone have user-written code for RACF, so that if the user >types in a password, the code will verify if it is the user's actual >LOGON password? > > I'd like to see code that does this, for ACF2 and Top Secret as >well, but I'm primarily interested in RACF. > Ideally, such code should work alike under SSH, OMVS, TSO, ... And best if the SAF momentarily takes control of the terminal so the password never appear in cleartext in the user's address space or on the user's screen. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN