[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Auditor's finding
From:       Stu Henderson <stu () STUHENDERSON ! COM>
Date:       2014-02-21 22:37:56
Message-ID: 5307D544.5030304 () stuhenderson ! com
[Download RAW message or body]

To simplify what I think people are saying, it comes down to two statements:

1.    If you have read access to the RACF database or its copies, then
you can learn the passwords by brute force.

2.    If you don't have such access, there is no practical way to learn
passwords (other than guessing or social engineering or other methods
that apply to any platform).


You can't control what hackers do once they have read access.  You can
control who has read access.  You can control options like "three
invalid passwords and the userid gets revoked".

Auditors would do well to make recommendations relating to what we can
control.  And not ask us to control things outside our capability.

HTH.  Best regards, Stu


On 2/19/2014 1:28 PM, R.S. wrote:
> W dniu 2014-02-19 19:09, Phil Smith III pisze:
>> "Sokolsky, Hayim Z." wrote, in part:
>>> 1. RACF does not store "password hashes", it stores a one-way DES
>>> encrypted
>> value for password checking. RACF actually encrypts the UserID using the
>> password to generate the encryption key. If you know the password,
>> you can
>> generate the resulting encrypted value. If you don't know the
>> password, you
>> don't know the password.
>>
>> "DES-encrypted" and "one-way" don't really go together. The key might
>> not be
>> available from a key server, but it's still Just Encrypted, is
>> reversible.
>> Presumably RACF doesn't reverse it, instead encrypting the input string
>> (going "forward" instead of "backward"), but it could.
> No, it couldn't. You are right, TYPICAL DES use is reversible. More: in
> order to use DES you have to know the key and then you can do decrypt as
> well as encrypt.
> However in RACF DES usage is specific. Password is not encrypted.
> Password (after some formatting) is a key. What is encrypted is the
> username. Username is not a secret, so the purpose of its encryption is
> to check encryption results - and then the key.
> There is no known method to find/restore the key form such construction,
> of course except brute force.
>
>> The real difference between this and a hash is that a hash is by
>> definition
>> *not* reversible, since it's lossy. But de facto, same difference,
>> since in
>> either case, you'd "break" it by processing input strings until you
>> found
>> one that matched the value. And in either case, the heat-death of the
>> universe is likely to precede your discovery of a match.
> Not to mention rainbow tables and other pre-hacked values.
>> I'm actually surprised that they don't use a hash, perhaps salted
>> with the
>> userid: that would achieve much the same result, and (I expect) be
>> faster.
>> But maybe when this was implemented, that wasn't the case (the fact
>> that DES
>> is used instead of AES supports that guess).
> Well, it's documented and implemented many years ago, so the surprise is
> not justified.
> Why not hash? because the method currently used can be broken only by
> brute force. That means, for 8-character passwords, no method could be
> better here. For longer passwords - that's another story, but not
> applicable here.
>> FWIW, SHA-2 is stronger than DES, though perhaps not stronger than this
>> pseudo-double-DES.
> See above.
>> ...phsiii (apologizing for being pedantic, but it seemed worth
>> clarifying!)
> Same disclaimer ;-)))
>
> Regards
>
> --
> 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 authorized 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.
>
> mBank S.A. z siedzib  w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kontakt@mBank.pl
> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
> Rejestru S dowego, nr rejestru przedsi biorców KRS 0000025237, NIP:
> 526-021-50-88. Wed ug stanu na dzie  01.01.2014 r. kapita zak adowy
> mBanku S.A. (w ca o ci wp acony) wynosi 168.696.052 z ote.
>
>

--
Stu Henderson (301) 229-7187  stu@stuhenderson.com  SITE= www.stuhenderson.com fax=301-229-3958
BLOG at:  www.stuhenderson.com/isauditblog
Next RACF Seminar: Feb. 25-28, 2014 in Clearwater, FL
Next Mainframe Audit Seminar March 3-6 in Clearwater, FL
[prev in list] [next in list] [prev in thread] [next in thread]