Re: RACF Database protection

2013-09-09 Thread Costin Enache
Are you sure? Could you please specify exactly where too look in the RACF docs? 
Or do you mean the ICHDEX01 exit (for which you can either choose masking or 
implement - program - your own algorithm)?

Costin




 From: Elardus Engelbrecht 
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 the new algorithm and that, once enabled, the new algorithm will 
>only be used incrementally.

Agreed, Shmuel. Thanks for your comment. I will be the last person to disagree 
with you. ;-D

They have already done that 'switch'. Read the RACF books about choice of 
password [1] encryption. But still, they will only do that if backward 
compatibility is NOT compromised. If backward compatibility could be 
compromised, they will warn you, just like they did with some product features. 
You remember that phasing out of ISAM? ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - technically, for RACF, not exactly passwords are encrypted, but userids. 
But I used word 'password' to make a point.

--
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: RACF Database protection

2013-09-08 Thread Elardus Engelbrecht
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 for your comment. I will be the last person to disagree 
with you. ;-D

They have already done that 'switch'. Read the RACF books about choice of 
password [1] encryption. But still, they will only do that if backward 
compatibility is NOT compromised. If backward compatibility could be 
compromised, they will warn you, just like they did with some product features. 
You remember that phasing out of ISAM? ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - technically, for RACF, not exactly passwords are encrypted, but userids. 
But I used word 'password' to make a point.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-08 Thread Shmuel Metz (Seymour J.)
In
<0539133098161601.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 09/05/2013
   at 03:31 AM, Elardus Engelbrecht 
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 enable the new algorithm and that, once enabled, the new
algorithm will only be used incrementally.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-05 Thread Elardus Engelbrecht
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 they 
will change their algorithms or be open to suggestions when it comes to 
security. Perhaps IBM updated those algorithms, but did not tell us.

Perhaps in a new operating system, yes. ;-D

If you don't like RACF, you can always write your own version of RACF + 
algoritms. :-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-05 Thread Costin Enache
The error can be easily demonstrated, see one of my earlier posts. But I'm only 
a security consultant and I don't work for one of those companies paying 
millions yearly to IBM, so I guess it has high chances to be ignored. 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.


Costin




 From: Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, 4 September 2013, 17:45
Subject: Re: RACF Database protection
 

On 4 September 2013 04:07, Costin Enache  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), but the 
> system cannot know if the correct password phrase has been used (and not one 
> of the others which also work). Or just invalidate the old phrases. The 
> system does not store enough hash bytes to decide which password is the 
> correct one ... in any case it would be a mess. The bug cannot be used to 
> brute-force authentication (the account will be locked before one can benefit 
> from the collisions) and, in case the RACF db is exposed, it is easy to crack 
> the hashes anyway, the collisions are not really needed. It will probably 
> just stay as it is :)

Not all APARs are opened for what seems to be their obvious reason. It
may well be that, with nothing beyond reported weaknesses in phrase
handling, there is nothing to APAR - even more the case if it is based
on reports from a third party's analysis rather than a customer's
business problem. But an easily demonstrable error (accepting the
wrong phrase and allowing logon) is blatant enough to perhaps get
action, and if the necessary action is to redesign the whole scheme
(or provide for customer/ISV supplied encryption routines, as is done
for passwords), then they might just do it. I'm sure it's not that the
IBM developers don't want to fix it; it's a matter of IBM management
devoting sufficient time and budget to it. And that requires a
customer squeaky wheel.

Tony H.

--
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: RACF Database protection

2013-09-04 Thread Tony Harminc
On 4 September 2013 04:07, Costin Enache  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), but the 
> system cannot know if the correct password phrase has been used (and not one 
> of the others which also work). Or just invalidate the old phrases. The 
> system does not store enough hash bytes to decide which password is the 
> correct one ... in any case it would be a mess. The bug cannot be used to 
> brute-force authentication (the account will be locked before one can benefit 
> from the collisions) and, in case the RACF db is exposed, it is easy to crack 
> the hashes anyway, the collisions are not really needed. It will probably 
> just stay as it is :)

Not all APARs are opened for what seems to be their obvious reason. It
may well be that, with nothing beyond reported weaknesses in phrase
handling, there is nothing to APAR - even more the case if it is based
on reports from a third party's analysis rather than a customer's
business problem. But an easily demonstrable error (accepting the
wrong phrase and allowing logon) is blatant enough to perhaps get
action, and if the necessary action is to redesign the whole scheme
(or provide for customer/ISV supplied encryption routines, as is done
for passwords), then they might just do it. I'm sure it's not that the
IBM developers don't want to fix it; it's a matter of IBM management
devoting sufficient time and budget to it. And that requires a
customer squeaky wheel.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-04 Thread Costin Enache
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 (and not one of the 
others which also work). Or just invalidate the old phrases. The system does 
not store enough hash bytes to decide which password is the correct one ... in 
any case it would be a mess. The bug cannot be used to brute-force 
authentication (the account will be locked before one can benefit from the 
collisions) and, in case the RACF db is exposed, it is easy to crack the hashes 
anyway, the collisions are not really needed. It will probably just stay as it 
is :) 


Costin




 From: Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, 4 September 2013, 1:11
Subject: Re: RACF Database protection
 

On 3 September 2013 09:41, Costin Enache  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 
> cipher text block at the end, if the last clear-text block was padded. This 
> means that, if for example the last block had one character (say 1=F1) padded 
> to a length of 8 with spaces (F14040.), only the first byte of the 
> resulting DES cipher text will be stored. There are many clear-texts what 
> will generate the same byte on the first position when encrypted with DES. 
> Example: create user COSTIN with phrase Abcd1234Abcd1234a, then try to logon 
> with phrase Abcd1234Abcd1234X

I would think that should be APARable...

Tony H.

--
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: RACF Database protection

2013-09-04 Thread R.S.

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






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-03 Thread FRANCIS SOUSA
Ask your network guys to restrict FTP, maybe use ACL ?


On Sat, Aug 17, 2013 at 4:02 AM, mmjuma  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 some users. He had now access to the file in mainframe.
> I want to understand what happend, and how to protect against such issue.
>
>
>
> Send from Samsung Mobile
>
> --
> 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: RACF Database protection

2013-09-03 Thread Tony Harminc
On 3 September 2013 09:41, Costin Enache  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 
> cipher text block at the end, if the last clear-text block was padded. This 
> means that, if for example the last block had one character (say 1=F1) padded 
> to a length of 8 with spaces (F14040.), only the first byte of the 
> resulting DES cipher text will be stored. There are many clear-texts what 
> will generate the same byte on the first position when encrypted with DES. 
> Example: create user COSTIN with phrase Abcd1234Abcd1234a, then try to logon 
> with phrase Abcd1234Abcd1234X

I would think that should be APARable...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-03 Thread Costin Enache
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 a short key. IBM 
has tried to sort of adapt the CBC mode to this scenario, but did not word out 
very well.

Costin

On 3 Sep 2013, at 16:42, Paul Gilmartin  wrote:

> 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 look at:
> 
>http://en.wikipedia.org/wiki/Data_Encryption_Standard
> 
> (Yah, I know; "Wikipedia"), which says:
> 
>Like other block ciphers, DES by itself is not a secure means of encryption
>but must instead be used in a mode of operation. FIPS-81 specifies several
>modes for use with DES.[20] Further comments on the usage of DES are
>contained in FIPS-74.[21]
> 
> And from FIPS-81:
> 
>http://www.itl.nist.gov/fipspubs/fip81.htm
> 
> which seems to be rife with typos, confusing "zero" with "oscar" (not even
> "Oscar"), it would appear that the passphrase handling is using the simplest
> method, ECB, which is susceptible to paralleization.  Other methods, CBC,
> CFB, and OFB would seem to resist parallelization and to be stronger.
> 
>> Not possible directly with DES, but there are many other alternatives 
>> which would be quite secure at no additional cost. I have no idea why 
>> the password phrase is encrypted in this way, considering the available 
>> modern technology already employed by RACF.
> 
> I see.
> 
> -- 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: RACF Database protection

2013-09-03 Thread Paul Gilmartin
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 look at:

http://en.wikipedia.org/wiki/Data_Encryption_Standard

(Yah, I know; "Wikipedia"), which says:

Like other block ciphers, DES by itself is not a secure means of encryption
but must instead be used in a mode of operation. FIPS-81 specifies several
modes for use with DES.[20] Further comments on the usage of DES are
contained in FIPS-74.[21]

And from FIPS-81:

http://www.itl.nist.gov/fipspubs/fip81.htm

which seems to be rife with typos, confusing "zero" with "oscar" (not even
"Oscar"), it would appear that the passphrase handling is using the simplest
method, ECB, which is susceptible to paralleization.  Other methods, CBC,
CFB, and OFB would seem to resist parallelization and to be stronger.

>Not possible directly with DES, but there are many other alternatives 
>which would be quite secure at no additional cost. I have no idea why 
>the password phrase is encrypted in this way, considering the available 
>modern technology already employed by RACF.

I see.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-03 Thread Costin Enache





 From: Paul Gilmartin 
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 in parallel. 
>>
>Sounds like a half-hearted implementation -- what would have been the
>additional cost of using larger blocks?

Not possible directly with DES, but there are many other alternatives which 
would be quite secure at no additional cost. I have no idea why the password 
phrase is encrypted in this way, considering the available modern technology 
already employed by RACF.

>>Another flaw, concerning the hash storage, allows for collisions in the last 
>>block, 
>>if the phrase length is not exactly multiple of 8.
>>
>The obvious question, then, is would the method be improved simply by padding
>that last block (with blanks, e.g.; or better characters invalid in the 
>passphrase)
>to a multiple of 8.  Does the passphrase syntax permit trailing blanks so that
>passphrases differing only in the number of trailing blanks are considered
>different?

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 cipher 
text block at the end, if the last clear-text block was padded. This means 
that, if for example the last block had one character (say 1=F1) padded to a 
length of 8 with spaces (F14040.), only the first byte of the resulting DES 
cipher text will be stored. There are many clear-texts what will generate the 
same byte on the first position when encrypted with DES. Example: create user 
COSTIN with phrase Abcd1234Abcd1234a, then try to logon with phrase 
Abcd1234Abcd1234X

>Does the method still operate by storing the user ID encrypted by the (chunks 
>of)
>the passphrase?  Is any weakness introduced by the 7-character (practical)
>limitation of user IDs?

Pretty much the same, with some obfuscation.

Costin


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-02 Thread Paul Gilmartin
On Mon, 2 Sep 2013 09:44:27 +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?

>Another flaw, concerning the hash storage, allows for collisions in the last 
>block, 
>if the phrase length is not exactly multiple of 8.
>
The obvious question, then, is would the method be improved simply by padding
that last block (with blanks, e.g.; or better characters invalid in the 
passphrase)
to a multiple of 8.  Does the passphrase syntax permit trailing blanks so that
passphrases differing only in the number of trailing blanks are considered
different?

Does the method still operate by storing the user ID encrypted by the (chunks 
of)
the passphrase?  Is any weakness introduced by the 7-character (practical)
limitation of user IDs?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-02 Thread Costin Enache
> I must be missing something.  A brute force attack on a one byte password
> must be prepared for 256 attempts.  The same attack on a two byte password
> must be prepared for 65,536 attempts which is significantly more than the
> 512 you suggest.  How is the increase not exponential?

This is why I wrote "flawed implementation". The first 8-bytes behave as 
expected, meaning that each additional character in the password candidate 
increases the effort exponentially (depending on the alphabet size, which is 
not 256, but much smaller). One would expect that the 9th byte will increase 
the effort also exponentially, but this is not the case. The password phrase 
hash can be split into blocks of 8 bytes, and each of them "cracked" 
independently, also in parallel. Another flaw, concerning the hash storage, 
allows for collisions in the last block, if the phrase length is not exactly 
multiple of 8. This means that, cryptographically, the attack complexity is 
almost the same as for 8-byte passwords (except for the plain text alphabet, 
which for phrases is larger). I'd rather not give out the implementation 
details on the list as everybody seems to be a bit paranoid about releasing 
tech specs about this stuff (aid the hackers, etc.).

Costin




 From: retired mainframer 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, 2 September 2013, 0:16
Subject: 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 of password phrases instead of passwords does
:>: not
:>: increase the complexity of a brute-force attack against the encrypted
:>: hashes,
:>: in case the RACF DB gets compromised (flawed / insecure DES
:>: implementation).
:>: The time required for recovering a 16-byte password phrase is two times
:>: the time
:>: required for an eight-byte password, for a 24-byte phrase three times,
:>: etc.
:>: (the required time does not increase exponentially, as expected).

I must be missing something.  A brute force attack on a one byte password
must be prepared for 256 attempts.  The same attack on a two byte password
must be prepared for 65,536 attempts which is significantly more than the
512 you suggest.  How is the increase not exponential?

--
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: RACF Database protection

2013-09-02 Thread R.S.

W dniu 2013-09-02 00:16, retired mainframer pisze:

:>: -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 of password phrases instead of passwords does
:>: not
:>: increase the complexity of a brute-force attack against the encrypted
:>: hashes,
:>: in case the RACF DB gets compromised (flawed / insecure DES
:>: implementation).
:>: The time required for recovering a 16-byte password phrase is two times
:>: the time
:>: required for an eight-byte password, for a 24-byte phrase three times,
:>: etc.
:>: (the required time does not increase exponentially, as expected).

I must be missing something.  A brute force attack on a one byte password
must be prepared for 256 attempts.  The same attack on a two byte password
must be prepared for 65,536 attempts which is significantly more than the
512 you suggest.  How is the increase not exponential?

http://en.wikipedia.org/wiki/Birthday_attack
Of course, the theory you presented is still valid.
BTW, just to clarify: RACF password is NOT "8 byte password". Only 
subset of possible byte values is accepted (0-9, A-Z, @$#, lately a-z).
Its (as I counted: 10+26+3+26) 65 values per character. So the password 
could be 65^8 = .318 644 812 890 625.
This is simplification, I did not consider shorter passwords (which 
increases the base) and password rules (which decreases the base).


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-01 Thread retired mainframer
:>: -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 of password phrases instead of passwords does
:>: not
:>: increase the complexity of a brute-force attack against the encrypted
:>: hashes,
:>: in case the RACF DB gets compromised (flawed / insecure DES
:>: implementation).
:>: The time required for recovering a 16-byte password phrase is two times
:>: the time
:>: required for an eight-byte password, for a 24-byte phrase three times,
:>: etc.
:>: (the required time does not increase exponentially, as expected).

I must be missing something.  A brute force attack on a one byte password
must be prepared for 256 attempts.  The same attack on a two byte password
must be prepared for 65,536 attempts which is significantly more than the
512 you suggest.  How is the increase not exponential?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-09-01 Thread Costin Enache
Small
clarification: The usage of password phrases instead of passwords does not
increase the complexity of a brute-force attack against the encrypted hashes,
in case the RACF DB gets compromised (flawed / insecure DES implementation).
The time required for recovering a 16-byte password phrase is two times the time
required for an eight-byte password, for a 24-byte phrase three times, etc.
(the required time does not increase exponentially, as expected). The same tech
used for recovering passwords can also crack password phrases. There are also
collisions, meaning that, in specific cases, in addition to the configured
phrase, there will be another two or three distinct ones that also work to 
authenticate
the user (hmm…). The usage of password phrases is of course strongly
recommended, but not for saving the day in case of a RACF DB compromise.

Costin




 From: Walt Farrell 
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  
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 are in
>fact stored in encrypted form. The encryption method itself is not a state
>secret. It can be simulated.

Sorry, Skip, but that's wrong. The passwords are, in fact, not stored at all. 
(There is one exception, the "password enveloping" function, but that's a 
different discussion than this one.)

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.

>
>The brute force method alluded to here starts with a copy of a RACF data
>base. Then generated character strings are fed into an encryption program
>until the encrypted form of some random string matches what's found in the
>data base for a given userid. Voila. The password has been hacked.

No, it's not the "encrypted form of some random string", it's the encrypted 
form of the user ID, when using some random string as the encryption key.

>
>Once upon a time, it would have taken so long to perform this string match
>that passwords would likely have changed in the meantime. Nowadays
>computers all the way down to smart phones have gotten faster while the
>encryption algorithms have remained the same. There is to my knowledge no
>canonical defense for this hacking method. Best you can do is to prevent
>the data base from being copied in the first place.

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 you can decrease that to 9 with an exit) that will be 
harder. And with commonly available technology it's perhaps impossible today if 
you have only a slightly longer string. 

-- 
Walt

--
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: RACF Database protection

2013-08-18 Thread Ron Hawkins
Skip,

There was an method posted many years ago that used a lexicon of common
words, and passwords, to encrypt a UID and match it to the value stored in
RACF. Is this what you are referring to?

The OP of that post mentioned this as an auditing tool, but I recall a
lengthy and robust discussion as to whether it was actually an audit tool,
or a crack. 

I'm no expert, but I would not count this as a brute force crack as the
scope of the attack would be the size of the lexicon, and how well it
matches the user and/or the community. I think it would be true to say that
lax password standards or enforcement would make this an easier crack.

I'm not enamored of brute force crackers. After five years trying to crack a
word 97 document that I forgot the password to I simply gave up. Not running
continuously, but for weeks at a time.

Ron

> -Original Message-
> From: IBM Mainframe 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 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
> secret. It can be simulated.
> 
> The brute force method alluded to here starts with a copy of a RACF data
> base. Then generated character strings are fed into an encryption program
> until the encrypted form of some random string matches what's found in the
> data base for a given userid. Voila. The password has been hacked.
> 
> Once upon a time, it would have taken so long to perform this string match
> that passwords would likely have changed in the meantime. Nowadays
> computers all the way down to smart phones have gotten faster while the
> encryption algorithms have remained the same. There is to my knowledge
> no canonical defense for this hacking method. Best you can do is to
prevent
> the data base from being copied in the first place.
> 
> As for what to do with the 'culprit', did he abscond with data or commit
some
> other mischief? Or did he reveal his activity to management as a wake-up
> call? The news today is replete with tales of 'ethical hackers'.
> Should we lock them up or bestow medals? Motivation is everything.
> 
> .
> .
> JO.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   mmjuma 
> To: IBM-MAIN@LISTSERV.UA.EDU,
> Date:   08/17/2013 01:04 AM
> Subject:RACF Database protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> 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 issue.
> 
> 
> --
> 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: RACF Database protection

2013-08-18 Thread Shmuel Metz (Seymour J.)
In <520f48c1.1010...@bremultibank.com.pl>, on 08/17/2013
   at 11:56 AM, "R.S."  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
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-18 Thread Shmuel Metz (Seymour J.)
In <791e2a3e-e500-46bd-98a9-02f34c650...@gmail.com>, on 08/18/2013
   at 08:48 AM, Louis Losee  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
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-18 Thread Louis Losee
Lets be specific here.

On Aug 17, 2013, at 12:30 PM, Skip Robinson  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 are in 
> fact stored in encrypted form. The encryption method itself is not a state 
> secret. It can be simulated.

The passwords are NOT stored.  The encrypted user id is stored
> 
> 
> The brute force method alluded to here starts with a copy of a RACF data 
> base. Then generated character strings are fed into an encryption program 
> until the encrypted form of some random string matches what's found in the 
> data base for a given userid. Voila. The password has been hacked. 
> 

It is not possible to hack RACF passwords unless the user ids that access the 
system protected 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 they would be different in the database so cracking a 
password once does not allow simple checks to see if other users are using the 
same password.
  
> Once upon a time, it would have taken so long to perform this string match 
> that passwords would likely have changed in the meantime. Nowadays 
> computers all the way down to smart phones have gotten faster while the 
> encryption algorithms have remained the same. There is to my knowledge no 
> canonical defense for this hacking method. Best you can do is to prevent 
> the data base from being copied in the first place. 
> 
> As for what to do with the 'culprit', did he abscond with data or commit 
> some other mischief? Or did he reveal his activity to management as a 
> wake-up call? The news today is replete with tales of 'ethical hackers'. 
> Should we lock them up or bestow medals? Motivation is everything. 
> 
> .
> .
> JO.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   mmjuma 
> To: IBM-MAIN@LISTSERV.UA.EDU, 
> Date:   08/17/2013 01:04 AM
> Subject:RACF Database protection
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> 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 issue.
> 
> 
> --
> 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: RACF Database protection

2013-08-18 Thread Lizette Koehler
First, what version of z/OS are you running?

And another thought

I have not touched RACF directly in many years, so this may be old.  Make sure 
that your GLOBAL rules don't undercut your other rules improperly. Smart 
auditors look at the DSMON report to see if your sensitive datasets are 
properly protected. The really smart auditors then look at the DSMON Global 
Access Table Report to see if any of the GLOBAL rules permit access to a 
sensitive dataset. For example, if you have a GLOBAL DATASET rule that allows 
READ access to all SYS1.* datasets, then you likely have a weakness, even if 
other GLOBAL rules specify access of NONE for SYS1.UADS, SYS1.RACF, etc. A 
GLOBAL rule of SYS1.*/READ is only safe if you know ALL the SYS1 datasets which 
should have a UACC of NONE, both now and in the future. While you're looking at 
DSMON, check to make sure that the RACF dataset and its backup are on different 
disk packs.


Could you verify that your GLOBAL rules are setup correctly for us?  


Lizette

-Original Message-
From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of majuma
Sent: Saturday, August 17, 2013 9:48 AM
To: rac...@listserv.uga.edu
Subject: 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 such issue.



Send from Samsung Mobile

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-18 Thread R.S.

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 happen. RACF does not support change name of the object (user, 
group, other profiles). If you really want to change userid, you have to 
delete old one and create new one. It can be a pain for "messy" RACF db, 
and piece of cake for "clean" RACF db.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-18 Thread Lizette Koehler
Cross Posting to IBMMAIN and RACF

After reading Walt Farrell's response

The passwords are, in fact, not stored at all. (There is one exception, the 
"password enveloping" function, but that's a different discussion than this 
one.)  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.

It seems that your statement that he got the UID and Password of some users may 
not be complete.

Was your user able to prove to you that he could logon on with those Passwords 
and userids?  If so, then yes, you have 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 what this ID did and what 
was used to access the SYS1.RACF.PRIM database.

Could you post the RACF profile for this file?  It would help us to see if 
there is anything that might be missing.  Also, could you post the USERs ID 
with the LU userid command so we can see if there is anything that allowed the 
access?

Did he access the file from a different LPAR that did not have UACC(NONE) on 
SYS1.RACF.PRIM?

Did he access a backup of the database and transfer that the PC?

What was used on the PC that produced the RACF ID and Password?


Lizette


-Original Message-
From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of majuma
Sent: Saturday, August 17, 2013 9:48 AM
To: rac...@listserv.uga.edu
Subject: 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 such issue.



Send from Samsung Mobile

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread retired mainframer
:>: -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 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 issue.

There are several steps you should consider.

To limit the potential damage:

Since some accounts have been compromised, they should be revoked.  Have
each user physically come to your desk to have the account resumed and the
password reset.

 Since the passwords were cracked so quickly, I think a dictionary
attack was used.  In any event, the accounts that were compromised obviously
had very weak passwords.  You should create rules that require passwords to
be at or near the max length and to contain letters (both upper and lower
case unless you are using a very old version of z/OS) as well as numbers.

 User IDs used exclusively to run production jobs should not have
passwords.  Users who run these jobs should have surrogate authority to the
production IDs.

To prevent it from happening again:

 If your section mate's job description requires him to test the
effectiveness of your security practices, he did exactly what he was
supposed to but then I expect you would not be asking for help.

 If not, he should be immediately reported to management for
disciplinary action.  In the interim, his access to the RACF database should
be terminated.  Any "high level" privileges such as special, auditor,
operations, etc should also be terminated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Paul Gilmartin
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 (truncated) surname plus first
initial, slight flex allowed, only to avoid collisions.  Guess what.)
Is there any option to allow use of the encrypted UID, which is
relatively stable?  Open Systems admins made the rule; they're
not burdened with DSN prefixes.  (Actually, the rule hasn't been
enforced on mainframes; so far we're under the radar, but what
if?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Tony Harminc
On 17 August 2013 13:54, 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 you can decrease that to 9 with an exit) that 
> will be harder. And with commonly available technology it's perhaps 
> impossible today if you have only a slightly longer string.

It would be a better idea if IBM didn't require (on z/OS RACF) that
all userids continue to have a password! Why would an attacker bother
to attack the phrase when there is certain to be a short password with
a very restricted character set to attack? Of course you can write a
program to set the encrypted password to a value that is not the
result of encrypting a userid with a valid password. We put this into
our password synch/reset product primarily to make it easy to set
things up so a user with a phrase can have a password that isn't known
to the administrator or the user, but it has the additional advantage
of enlarging the domain of things to attack by "brute force" methods.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Skip Robinson
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 easily discernible. We run standard RACF utilities to 
determine for example what profiles a userid owns in order to prepare for 
deleting that userid. So userids don't have to be guessed at. They're 
visible in the (purloined) data base. One then 'merely' has to affix a 
random password string, then crunch the zeroes and ones to find a match in 
the copied data base. Certainly longer strings like password phrases will 
take longer to match. But hackers have nothing but time.

As my pal Leonard Woren once said: If you build a better mousetrap, the 
world will build a better mouse. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Walt Farrell 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   08/17/2013 10:54 AM
Subject:    Re: RACF Database protection
Sent by:IBM Mainframe Discussion List 



On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson 
 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 are in
>fact stored in encrypted form. The encryption method itself is not a 
state
>secret. It can be simulated.

Sorry, Skip, but that's wrong. The passwords are, in fact, not stored at 
all. (There is one exception, the "password enveloping" function, but 
that's a different discussion than this one.)

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.

>
>The brute force method alluded to here starts with a copy of a RACF data
>base. Then generated character strings are fed into an encryption program
>until the encrypted form of some random string matches what's found in 
the
>data base for a given userid. Voila. The password has been hacked.

No, it's not the "encrypted form of some random string", it's the 
encrypted form of the user ID, when using some random string as the 
encryption key.

>
>Once upon a time, it would have taken so long to perform this string 
match
>that passwords would likely have changed in the meantime. Nowadays
>computers all the way down to smart phones have gotten faster while the
>encryption algorithms have remained the same. There is to my knowledge no
>canonical defense for this hacking method. Best you can do is to prevent
>the data base from being copied in the first place.

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 you can decrease that to 9 with an 
exit) that will be harder. And with commonly available technology it's 
perhaps impossible today if you have only a slightly longer string. 

-- 
Walt



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Gerhard Postpischil

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 you can
decrease that to 9 with an exit) that will be harder. And with
commonly available technology it's perhaps impossible today if you
have only a slightly longer string.


My last employer, before my retirement, addressed the problem by giving 
each employee a gadget that displayed a password that changed about 
every minute. The only drawback was that it required a three-hour drive 
to the office to have it synchronized ever few months. Password phrases 
would have made it even trickier to enter the complete string before the 
algorithm kicked over to a new value?


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Walt Farrell
On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson  
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 are in
>fact stored in encrypted form. The encryption method itself is not a state
>secret. It can be simulated.

Sorry, Skip, but that's wrong. The passwords are, in fact, not stored at all. 
(There is one exception, the "password enveloping" function, but that's a 
different discussion than this one.)

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.

>
>The brute force method alluded to here starts with a copy of a RACF data
>base. Then generated character strings are fed into an encryption program
>until the encrypted form of some random string matches what's found in the
>data base for a given userid. Voila. The password has been hacked.

No, it's not the "encrypted form of some random string", it's the encrypted 
form of the user ID, when using some random string as the encryption key.

>
>Once upon a time, it would have taken so long to perform this string match
>that passwords would likely have changed in the meantime. Nowadays
>computers all the way down to smart phones have gotten faster while the
>encryption algorithms have remained the same. There is to my knowledge no
>canonical defense for this hacking method. Best you can do is to prevent
>the data base from being copied in the first place.

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 you can decrease that to 9 with an exit) that will be 
harder. And with commonly available technology it's perhaps impossible today if 
you have only a slightly longer string. 

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Skip Robinson
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 
secret. It can be simulated. 

The brute force method alluded to here starts with a copy of a RACF data 
base. Then generated character strings are fed into an encryption program 
until the encrypted form of some random string matches what's found in the 
data base for a given userid. Voila. The password has been hacked. 

Once upon a time, it would have taken so long to perform this string match 
that passwords would likely have changed in the meantime. Nowadays 
computers all the way down to smart phones have gotten faster while the 
encryption algorithms have remained the same. There is to my knowledge no 
canonical defense for this hacking method. Best you can do is to prevent 
the data base from being copied in the first place. 

As for what to do with the 'culprit', did he abscond with data or commit 
some other mischief? Or did he reveal his activity to management as a 
wake-up call? The news today is replete with tales of 'ethical hackers'. 
Should we lock them up or bestow medals? Motivation is everything. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   mmjuma 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   08/17/2013 01:04 AM
Subject:RACF Database protection
Sent by:IBM Mainframe Discussion List 



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 issue.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Lizette Koehler
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: 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, 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 issue.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Elardus Engelbrecht
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 unprotected! 

>...then he used some tool. 

With any of the available freebies you can download.

>... He was able to get uid and password of some users. 

As others said, only when you completed a brute force attack. No passwords are 
stored at all on the RACF DB and all its backups. Not even IRRDBU00 writes out 
protected fields.

>He had now access to the file in mainframe. 

Fire him. And the RACF admin too.

>I want to understand what happend, and how to protect against such issue.

Do a full review of your machine security. First, UACC=NONE on your RACF DB and 
all its backup. Then your PROGRAM class and FTP, then everything else.

And stay away from my machine.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread R.S.

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 backups).

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 brute-force mine!
Everyone with computer and the db is able to perform brute force attack, 
despite he should or should not.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Ted MacNEIL
>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 brute-force mine!
In my case, the term 'word' in password is a misnomer.

I won't even tell you how I come up with mine, but letters in my case are rare, 
even in 'long' ones?
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread R.S.

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 happend, and how to protect against such issue.

It's easy: he has READ to the db. He should have it.
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.
Las, but not least: it is bad idea to download in unecrypted form the db 
over the network, despite he has the READ.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: RACF Database protection

2013-08-17 Thread Ted MacNEIL
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 password is used to 
re-encrypt the userid. If matched sign-on is successful.

There arw more details, but I did say 'simple'.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: mmjuma 
Sender:   IBM Mainframe Discussion List 
Date: Sat, 17 Aug 2013 11:02:29 
To: 
Reply-To: IBM Mainframe Discussion List 
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 
to understand what happend, and how to protect against such issue.



Send from Samsung Mobile

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


RACF Database protection

2013-08-17 Thread mmjuma
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 issue.



Send from Samsung Mobile

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN