We need to ecrypt some data in ADABAS on UNIX system. I found some forum discussions for security on mainframes. Does it apply to UNIX?
Hello,
Yes, it is supported.
Please look in Adabas V513 Documentation for Unix and Windows in section “Administration / Database Design / Adabas Security Facilities / Ciphering”
Or just search for “cipher”.
It seems to have a slightly different implementation.
Yes, I looked through documentation. But ciphering is a file level (as well as on mainframe), we need field level. And mainframe guys were referring to UEXA and UEXB which I could not find for UNIX.
I am not sure if we have to write our own User Exits and call to some ciphering algorithm?
Any help would be greatly appreciated.
Thanks
Yelena
Yes, Adabas chipering support is on file level. It is identical on both mainframe an open systems.
UEXITB and UEXITA is on mainframe only. It is for customer usage where you receive control of the Adabas call in the link routine Before and After the call is sent to Adabas. Maybe the guys you mention have implemented some ciphering/deciphering of specific fields there?
But why not use the standard implementation in Adabas? To me it seems much easier and simple than using UEXITB/UEXITA.
Sorry for asking: Do you need the ciphering for user passwords?
No, this is not for user password. And we do not need ciphering for the entire file, just for several fieds with the sensitive customer data (client requirement).
Any help would be greatly appreciated.
Yelena
Do you think it is an disadvantage to have all fields encrypted?
An UEXITB/A implementation would require own coding! And the cpu usage may turn out to be even higher because you have to do selective encryption.
I was asking because I think crypting a user password would be the most simple thing. You can do it like Linux and some Unixes does:
Just make an md5sum (or AES-1) and store the hash in the database. Advantage: You don’t have to decipher the password. You will only compare hashes in future.
But anyway…
Let me ask you another question: What types of fields are we talking about? Numerics? Dates? This could cause problems.
For example: Let’s take a field called CREDIT-CARD-VALID-FROM. I guess you would take a widely known crypting-algorithm like 3DES, AES or something like that. But even if you take the “best” crypting-algorithm, it would be very easy to find out the value of CREDIT-CARD-VALID-FROM without knowing the key for deciphering.
The reason is: Every CREDIT-CARD-VALID-FROM is starting at the 1st of a month. So this field can have something about 100 possible values (this would cover 8 years). I think it would be easy for a hacker to crack this.
Of course you can combine the ADAISN or the ADABAS field name with your password before ciphering the data. But this would also be quite easy to find out - if you got some ADABAS-knowledge. So field based crypting can be very insecure.
Finally I don’t know how secure the ADABAS-ciphering is. I never used it. But the documentation says:
From my point of view, this would solve the problem with my example.
But if you really want to do a field based ciphering, it depends on the field type to find a suitable solution …
P.S.: I’ve edited this post, because the first draft was bull**** 