Re: No BPX-level interface for __passwd_applid? Was: Re: Code to verify LOGON password

[PINION, RICHARD W.]

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

[Thomas David Rivers]

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

[Seymour J Metz]

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

[Bob Bridges]

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

[R.S.]

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

[R.S.]

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

[Timothy Sipples]

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

[Charles Mills]

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

[Chris Hoelscher]

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

[R.S.]

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

[Tom Brennan]

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

[Timothy Sipples]

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

[Binyamin Dissen]

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

Code to verify LOGON password

[Sam Golob]

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

Re: Code to verify LOGON password

[Frank Swarbrick]

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

[Paul Gilmartin]

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

[Tom Brennan]

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

[Joel C. Ewing]

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

[Itschak Mugzach]

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

[Tom Brennan]

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

[Brian Westerman]

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

[Jousma, David]

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

[Kirk Wolf]

/*
  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

[Tony Harminc]

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

[Charles Mills]

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

[Carmen Vitullo]

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

[Paul Gilmartin]

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

Code to verify LOGON password

[Sam Golob]

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