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
I suggest you try the RACF List, but:
1. Protect all database amd their back-ups.
2. He does NOT have access to any passwords. They are not stored. In simple
terms the userid is encrypted, using the password when first set, and that is
what is stored. Then, with each sign on, the supplied
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
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
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
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
If you have not joined the RACF newsgroup, you can do it at this URL
http://www.listserv.uga.edu/archives/racf-l.html
Lizette
-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:
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 are in
fact stored in encrypted form. The encryption method itself is not a state
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
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
I of course defer to Walt. Fervent ignorance is to be eschewed even when
it's fired in the right general direction. In this case, password per se
is not stored, but 'something is stored' that could be stumbled upon by a
deftly written program running at very high speed forever.
Userids are
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
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
:: -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 to
14 matches
Mail list logo