New RACF Database Encryption Enhancement

There are several z/OS enhancements that have recently shipped as "continuous delivery" features. One of them that I haven't seen mentioned yet in this forum is the new and improved RACF database encryption. z/OS RACF can now use a VSAM data set that can be both AES256 encrypted

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

19 09:26:58 -0300 From:Clark Morris Subject: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? [Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

Passphrases and MFA! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Rowley Sent: Friday, May 10, 2019 6:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can backup mechanisms be used to steal RACF database? was Re

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

On 11/05/2019 12:34 am, Dana Mitchell wrote: Doesn't the KDFAES password encryption algorithm make it *much* more difficult to crack passwords, given access to the RACF database? I realize nothing is impossible to crack.. but at least not currently feasible with current available hardware

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

-- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of ITschak Mugzach > Sent: Friday, May 10, 2019 1:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Can backup me

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? I found many security and system programmers assuming that in order to manage security, one need access to the security database.I many assessments I was able to copy the file with no prob

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

gt; The lesson I take from this, and pass on to > > > my clients, is that read access to the security database is a huge > exposure > > > and in most cases - that is, for most user IDs - completely > unnecessary. > > > > Doesn't the KDFAES password encryp

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

- that is, for most user IDs - completely unnecessary. > > Doesn't the KDFAES password encryption algorithm make itmuch more difficult > to crack passwords, given access to the RACF database? I realize nothing is > impossible to crack.. but at least not currently feasible with cur

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

d encryption algorithm make it *much* more difficult to crack passwords, given access to the RACF database? I realize nothing is impossible to crack.. but at least not currently feasible with current available hardware. Dana --

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

No argument there! :-) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Thursday, May 9, 2019 9:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can backup mechanisms be used to steal RACF database? was Re

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

product that directly read the racf database, so you need to have read access to use it. all products built around this product also requires at least read access. In some cases, when I recommended to switch to "server" mode, the vendor said that not all products support that. So, even i

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

sday, May 9, 2019 17:23 The only thing that I see that is relevant is where you quoted "There are also solid indications that they downloaded the RACF database (about 28MB", which certainly seems consistent with Bob's claim. From: IBM Mainframe Discussion List

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

> Yes, that assertion is incorrect. Read my post. The only thing that I see that is relevant is where you quoted "There are also solid indications that they downloaded the RACF database (about 28MB", which certainly seems consistent with Bob's claim. -- Shmuel (Seymour

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? What causes IBM integrity (code-based) APARs to be generated? Surely not all of them are found internally. The thing is, with the way integ

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

es > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Thursday, May 9, 2019 10:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: &

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

On Thu, May 9, 2019 at 2:45 PM Bill Johnson < 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: > 5 LPARS, shared DASD, same rules for each LPAR. Full volume backups were > controlled by 1 DASD Admin.(now deceased) I no longer work there. As the > installer of the security product, TSS, even

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

a sandbox LPAR that shares DASD? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Thursday, May 9, 2019 10:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can backup mechanisms be used to steal RACF database? was Re

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

to steal RACF database? was Re: mainframe hacking "success stories"? > And yes, it was a z/OS vulnerability. Are you saying that Bob Bridges was wrong when he wrote "The stolen ID also had read access to the RACF database.."? It's not a vulnerability of the lock when you leav

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

> And yes, it was a z/OS vulnerability. Are you saying that Bob Bridges was wrong when he wrote "The stolen ID also had read access to the RACF database.."? It's not a vulnerability of the lock when you leave your key on the porch for anyone to use. -- Shmuel (Seymour

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? All of the security datasets are locked down to all but a select few. It would be next to impossible for someone not considered highly trustworthy to do anything with them. Sent from Yahoo Mail

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

idges Sent: Thursday, May 9, 2019 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? I believe Peter's right. The hackers got a stolen ID with some RACF power, by means not positively i

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Tuesday, May 7, 2019 5:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? [Default] On 6 May 2019 20:10:27 -0700,

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

breakin occurred.) Once they were in, they fooled around in OMVS and were able to get more power. The stolen ID also had read access to the RACF database. "There are also solid indications that they downloaded the RACF database (about 28MB)Once they’d downloaded the RACF database, they subj

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

al Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Tuesday, May 7, 2019 5:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? [Default]

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

No. Read the original thread here. It was a vulnerability in a Web server. Hacking the RACF database was done well after the fact, by investigators. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Vander Woude Sent

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

If you can transfer the backup file (real or virtual tape) to another system, then you can use the admin authorization to restore any or all files in the backup file. Just like using a rescue system to restore at a DR site. On Thu, May 9, 2019 at 8:56 AM Peter Vander Woude wrote: > > On Tue, 7

Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

On Tue, 7 May 2019 09:26:58 -0300, Clark Morris wrote: >Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database >and then download the dump of the database? > >Clark Morris >> Clark, If they have read access to the database, yes. That's what happened in the Swedish bank hack,

Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >In most shops only 2 people have the required access to the RACF database.  > Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the da

Re: RACF Database

: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert S. Hansel (RSH) Sent: Thursday, May 25, 2017 2:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database Hi Skip, I usually assign a group as the owner of a profile. In the case of datasets, I

Re: RACF Database

www.rshconsulting.com -Original Message- Date:Wed, 24 May 2017 19:22:23 + From:Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: RACF Database A fallout of this thread is that we're looking to assign a new owner to profiles that cover the RACF data sets. I'd like som

Re: RACF Database

@LISTSERV.UA.EDU] On Behalf Of Robert S. Hansel (RSH) Sent: Wednesday, May 24, 2017 3:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database Hi Skip, Point of clarification. IRRDBU00 no longer required UPDATE access with NOLOCKINPUT as of z/OS 2.2. Regards, Bob -Original

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Robert S. Hansel (RSH) wrote: >Restricting access to the RACF database is essential, but it isn't enough to >save you if the database is not allocated as unmovable. DFSMSdss' data >management utility ADRDSSU, when used with the ADMINISTRATOR keyword, ignores >dataset profiles and

Re: RACF Database

-Original Message- Date:Tue, 23 May 2017 21:57:21 + From:Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: RACF Database So it turns out that the number of folks here with ALTER access to RACF data sets is way smaller than I expected. There are however several u

Re: RACF Database

- Date:Tue, 23 May 2017 21:57:21 + From:Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: RACF Database So it turns out that the number of folks here with ALTER access to RACF data sets is way smaller than I expected. There are however several userids with UPDATE

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Todd, Restricting access to the RACF database is essential, but it isn't enough to save you if the database is not allocated as unmovable. DFSMSdss' data management utility ADRDSSU, when used with the ADMINISTRATOR keyword, ignores dataset profiles and can perform functions such as compress

Re: RACF Database

Of Joel C. Ewing Sent: Tuesday, May 23, 2017 12:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database It should go without saying that ALTER (and even READ) access to the RACF database data set should be restricted to those that really need direct access to the database data set

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Radoslaw Skorupka Sent: Tuesday, May 23, 2017 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP

Re: RACF Database

It should go without saying that ALTER (and even READ) access to the RACF database data set should be restricted to those that really need direct access to the database data set itself. Ordinary users and even RACF administrators should have NONE access to the RACF database data set. I would

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is @STOP). It also can be started again as well. The only cost is "address space unavailable" issue. Of course *properly protected* RACF db cannot be moved or deleted, due to lack of authorities. No one should have even

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Wouldn't a simpler solution to protecting the RACF database simply be to give pretty much no one ALTER access to it? I know that at most shops only one or two folks had ALTER or UPDATE to the actual file and that seems like the best course of action to avoid accidental deletion? And we

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, May 23, 2017 11:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 22, 2017 4:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote: >RECFM PSU

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Tue, 23 May 2017 12:27:10 -0400, Tony Harminc (t...@harminc.net) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On 22 May 2017 at 12:57, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > ... In any case, a SAF product has to be available extremely early in > IPL, ... > > > How does ACF2, based on VSAM, meet this requirement of early availability? > The same way it would if ACF2

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

d (!!!) >> the primary RACF data base. It was not enqueued on as previously noted. >> > >​Been there. Done that. Beat up the programmer. > One also gets a similar pleasing effect if you run an IRRUT200 step with DD SYSUT1 pointing to the RACF Database. Dana ---

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

John McKown wrote: >>Long before "z/OS", someone accidentally deleted (!!!) the primary RACF data >>base. >> Could not have done that with VSAM. ;-) >​Been there. Done that. Beat up the programmer. I hope he survived your cruel beating, because if he did the same error on the BACKUP RACF DB,

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 23 May, 2017 0:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RACF Database (was: Sample JCL for file transfer using > NJE/TCPIP)

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson wrote: > Brief war story. Long before "z/OS", someone accidentally deleted (!!!) > the primary RACF data base. It was not enqueued on as previously noted. > Data was intact and the system hummed along, but there was no

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

all the time (but which could be shut down if need be), >and added an unreferenced DD for the RACF database with DISP=SHR to >reduce the odds of both accidental deletion and movement. > Suppose one wanted to craft a started task expressly for that purpose, using minimum resource. Wou

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, 22 May 2017 09:21:48 -0400, Robert S. Hansel (RSH) wrote: > >... then immediately closes them. > Why? Does it also FREE then? Why? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

an unreferenced DD for the RACF database with DISP=SHR to reduce the odds of both accidental deletion and movement. I suspect performance may have also been behind the choice of not ever using VSAM for the RACF database. VSAM can usually behave pretty well these days if you can throw enough memory

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

ay, May 22, 2017 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Sun, 21 May 2017 14:19:39 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote: >On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wro

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David W Noon Sent: Monday, May 22, 2017 10:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in <507b5253-a062-4547-91f6-3de9e6f3b...@aim.com>): On 2017-05-22, at 10:01, Jesse

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On 2017-05-22, at 10:01, Jesse 1 Robinson wrote: > ... Nonetheless ACF2, based on VSAM, was well established ... > > ... In any case, a SAF product has to be available extremely early in IPL, > ... > How does ACF2, based on VSAM, meet this requirement of early availability? -- gil

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

. Nonetheless ACF2, based on VSAM, was well established by then. I can't speak for ASM1. (OK, it's a long way from Friday.) I don't think it matters much what DSCB attributes are assigned to the RACF database. RACF will open and process it only one way. I've seen PSU recommended to prevent

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) < r.han...@rshconsulting.com> wrote: > Gil, > > The RACF database is BDAM (Basic Direct Access Method) and has, to my > knowledge, always been so since it was first released in 1976. The index > records are s

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

>> >"Unmovable" would seem to imply uncopyable; the copy would have to go >in a different place. But there must be some provision for backing it up, >and little point in trying to move it to another system with such as FTP. "Unmovable" is recommended to

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Gil, The RACF database is BDAM (Basic Direct Access Method) and has, to my knowledge, always been so since it was first released in 1976. The index records are stored in the database with the profile (data) records, so it is completely self-contained. I know of no other product using

Re: RACF Database protection

...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, 8 September 2013, 17:17 Subject: Re: RACF Database protection Shmuel Metz (Seymour J.) wrote: You can wish, but big blue wants backward compatibility, How is that an obstacle? If they do it, I'm sure that there will be a switch to enable

Re: RACF Database protection

In 0539133098161601.wa.elardus.engelbrechtsita.co...@listserv.ua.edu, on 09/05/2013 at 03:31 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za said: You can wish, but big blue wants backward compatibility, How is that an obstacle? If they do it, I'm sure that there will be a switch to

Re: RACF Database protection

Shmuel Metz (Seymour J.) wrote: You can wish, but big blue wants backward compatibility, How is that an obstacle? If they do it, I'm sure that there will be a switch to enable the new algorithm and that, once enabled, the new algorithm will only be used incrementally. Agreed, Shmuel. Thanks

Re: RACF Database protection

Database protection On 4 September 2013 04:07, Costin Enache e_cos...@yahoo.com wrote: It may not be APARable. Even if you fix the bug, what do you do with the old password phrases? Maybe update the RACF database with a secure hash value once the user logs in (to add the previously discarded

Re: RACF Database protection

Costin Enache wrote: Wishful thinking: that IBM, if they decide to change the algorithm, will learn the advantages of open, secure and open to debate cryptography over secret, obfuscated and most often broken schemes. You can wish, but big blue wants backward compatibility, so it is unlikely

Re: RACF Database protection

W dniu 2013-09-04 04:32, FRANCIS SOUSA pisze: Ask your network guys to restrict FTP, maybe use ACL ? It doesn't help. The problem is in READ to the dataset not the ability to use *one of existing* transfer methods. Protect resources, not the tools. -- Radoslaw Skorupka Lodz, Poland --

Re: RACF Database protection

It may not be APARable. Even if you fix the bug, what do you do with the old password phrases? Maybe update the RACF database with a secure hash value once the user logs in (to add the previously discarded hash bytes), but the system cannot know if the correct password phrase has been used

Re: RACF Database protection

On 4 September 2013 04:07, Costin Enache e_cos...@yahoo.com wrote: It may not be APARable. Even if you fix the bug, what do you do with the old password phrases? Maybe update the RACF database with a secure hash value once the user logs in (to add the previously discarded hash bytes

Re: RACF Database protection

From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, 2 September 2013, 22:09 Subject: Re: RACF Database protection The password phrase hash can be split into blocks of 8 bytes, and each of them cracked independently, also

Re: RACF Database protection

On Tue, 3 Sep 2013 14:41:49 +0100, Costin Enache wrote: The password phrase hash can be split into blocks of 8 bytes, and each of them cracked independently, also in parallel. Sounds like a half-hearted implementation -- what would have been the additional cost of using larger blocks? So I

Re: RACF Database protection

The DES modes are good for protecting a secret plaintext with a DES key, but in our case we have a short, known plaintext - the username, which is encrypted with the password (or with blocks of the password phrase). So we have a long key with a short plaintext, instead of a long plaintext with

Re: RACF Database protection

On 3 September 2013 09:41, Costin Enache e_cos...@yahoo.com wrote: The phrase clear text is already padded with spaces to a multiple of 8, but, after encryption, the resulting hash is truncated to the length of the original clear text, minus the padding. This leaves us with an incomplete DES

Re: RACF Database protection

Ask your network guys to restrict FTP, maybe use ACL ? On Sat, Aug 17, 2013 at 4:02 AM, mmjuma mmj...@yahoo.com wrote: Hi list Some one in our section, he was able to download RACF data base file SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get uid and password of

Re: RACF Database protection

From: Walt Farrell walt.farr...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Saturday, 17 August 2013, 19:54 Subject: Re: RACF Database protection On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: This exposure has been known--and discussed publicly

Re: RACF Database protection

:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Costin Enache :: Sent: Sunday, September 01, 2013 12:04 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: RACF Database protection :: :: Small :: clarification: The usage

Re: RACF Database protection

a problem. Second, if your RACF Database is in UACC(NONE) then how did he get access? RACF should have prevented any READ attempt. So either the user had a special authority or that person used a different id that had the authority to do this. I would review the RACF SMF data to see specifically

Re: RACF Database protection

W dniu 2013-08-18 06:50, Paul Gilmartin pisze: On Sat, 17 Aug 2013 12:54:41 -0500, Walt Farrell wrote: RACF encrypts the user ID using the password as the key, and stores the encrypted user ID. The password itself is not saved, in any form. What happens when the user ID changes? It won't

Re: RACF Database protection

: Fwd: RACF Database protection Hi list, Some one in our section, he was able to download RACF data base file SYS1.RACF.PRIM via ftp to PC, the file is UACC is none. then he used some tool to get uid and password of some users. I want to understand what happend, and how to protect against

Re: RACF Database protection

by RACF are known. It is typically a difficult task to get a list of user ids without read access to the RACF database. Even if you manage to come up with a list of user ids, it does you no good unless you have read access to the RACF database. Even if two users have identical passwords

Re: RACF Database protection

In 791e2a3e-e500-46bd-98a9-02f34c650...@gmail.com, on 08/18/2013 at 08:48 AM, Louis Losee llo...@gmail.com said: It is typically a difficult task to get a list of user ids without read access to the RACF database. It's easy to approximate. -- Shmuel (Seymour J.) Metz, SysProg and JOAT

Re: RACF Database protection

In 520f48c1.1010...@bremultibank.com.pl, on 08/17/2013 at 11:56 AM, R.S. r.skoru...@bremultibank.com.pl said: Everyone with computer and the db Presumably the point is that you *don't* have access to his RACF DB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2

Re: RACF Database protection

Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Saturday, August 17, 2013 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] RACF Database protection This exposure has been known--and discussed publicly--for several years. It is NOT true

RACF Database protection

Hi list Some one in our section, he was able to download RACF data base file SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get uid and password of some users. He had now access to the file in mainframe. I want to understand what happend, and how to protect against such

Re: RACF Database protection

@LISTSERV.UA.EDU Date: Sat, 17 Aug 2013 11:02:29 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: RACF Database protection Hi list Some one in our section, he was able to download RACF data base file SYS1.RACF.PRIM via ftp to PC

Re: RACF Database protection

W dniu 2013-08-17 10:02, mmjuma pisze: Hi list Some one in our section, he was able to download RACF data base file SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get uid and password of some users. He had now access to the file in mainframe. I want to understand what

Re: RACF Database protection

It's easy: he has READ to the db. He should have it. Why should he have it? Nobody needs read access to any password, copy, or back-up! Regarding passwords: no password is recorded in the db, but having the db he's able to use brute-force method to find the passwords. He wouldn't be able to

Re: RACF Database protection

W dniu 2013-08-17 10:57, Ted MacNEIL pisze: It's easy: he has READ to the db. He should have it. Why should he have it? Nobody needs read access to any password, copy, or back-up! My typo: he SHOULD NOT have it. Even for backup purposes. (WHEN(PROGRAM(IRRUT200)) is the solution for ad-hoc

Re: RACF Database protection

mmjuma wrote: Some one in our section, he was able to download RACF data base file SYS1.RACF.PRIM ... You and that someone should stay away from my z/OS! Your protection of RACF DB and all its backups are pathetic. UACC should be NONE (see other's replies). ... via ftp to PC, Your FTP is

Re: RACF Database protection

-MAIN@LISTSERV.UA.EDU Subject: RACF Database protection Hi list Some one in our section, he was able to download RACF data base file SYS1.RACF.PRIM via ftp to PC, then he used some tool. He was able to get uid and password of some users. He had now access to the file in mainframe. I want

Re: RACF Database protection

jo.skip.robin...@sce.com From: mmjuma mmj...@yahoo.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 08/17/2013 01:04 AM Subject:RACF Database protection Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi list Some one in our section, he was able to download RACF data base

Re: RACF Database protection

On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: This exposure has been known--and discussed publicly--for several years. It is NOT true that 'passwords are not stored'. If they weren't 'stored' at all, then how could RACF validate the password you supply? They

Re: RACF Database protection

On 8/17/2013 1:54 PM, Walt Farrell wrote: Where possible, you can switch to the use of password phrases rather than passwords. You're right that the brute fore attacks are increasingly simple for mere 8-byte passwords, but password phrases give you longer values (minimum 14 by default, though

Re: RACF Database protection

: RACF Database protection Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: This exposure has been known--and discussed publicly--for several years. It is NOT true that 'passwords are not stored

Re: RACF Database protection

On 17 August 2013 13:54, Walt Farrell walt.farr...@gmail.com wrote: Where possible, you can switch to the use of password phrases rather than passwords. You're right that the brute fore attacks are increasingly simple for mere 8-byte passwords, but password phrases give you longer values

Re: RACF Database protection

On Sat, 17 Aug 2013 12:54:41 -0500, Walt Farrell wrote: RACF encrypts the user ID using the password as the key, and stores the encrypted user ID. The password itself is not saved, in any form. What happens when the user ID changes? (We suffer a corporate standard that user ID _shall_ be

Re: RACF Database protection

:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of mmjuma :: Sent: Saturday, August 17, 2013 1:02 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: RACF Database protection :: :: Hi list :: :: Some one in our section, he was able