In this blog, I would be talking about how secure is the
Essbase password encryption and decryption modules and try to explain the
motivation for using this. This is more of a personal inference so I can be
woefully wrong as well. In my previous blog, I had shown how the password
encryption and decryption works internally using the RSA algorithm.
The below snapshot shows the leys that are generated for
essmsh.
The first thing that you need to understand about the encryption is why RSA is as secure as it is. RSA depends on the difficulty of factorizing very large numbers into their prime factors. The reason for this is that there are no known algorithms that can factorize numbers in an efficient manner. However, there is a caveat. This factorization for small numbers can be done relatively easily. For example, in the above example, I can factorize 243031641 using a simple Excel sheet. 38153 is a factor of the above number calculated using a simple excel sheet as shown in the below snapshot.
For RSA to work, it needs numbers almost 1024 bits long
which is used by military grade applications. Unfortunately, the key value
specified in the above example is not that long and can be factorized easily.
So is Oracle essmsh encryption really strong?
Well, the answer is yes and that is because of the internal
implementation of the encryption and decryption. The below snapshot shows a
login using encrypted user name and password.
Observe that user name and passwords are encrypted as an
abnormally long string of numbers. This means that there is an internal
mechanism that maps or converts your user name and password into a string of integers
first and then applies the RSA algorithm to the derived number. During
decryption, we just apply the process in reverse. So long as the internal
mechanism remains secure, the encryption and decryption cannot be compromised.
Now, let us understand the motivation of why we should be
using the password encryption. Any good system design would try to keep access
to user names and passwords on a need-to-know basis. But, most good systems
also need information logging to handle the inevitable failures as and when
they occur. Now in an ideal system, you would have your passwords in just the
script file which only admin users would have access to. The logs would be
without user name and passwords and the world would be a much better place.
But, we do not live in the ideal world. There can be bad script design due to
which password may be logged into a log file. There can be a case where you may
need to share the log file of the run to a team of consultants for issue
analysis and debugging. Having your passwords flying around in log files is not
ideal.
This is where password encryption using essmsh comes in handy. It is a defensive programming tactic. As soon as your scripts are up and running and ready for production deployment, all that your admin needs to do is run the encryption on the scripts. This can be easily done using a shell script or a batch file. Once that is done, you can have scripts that can be deployed into an environment secure in the knowledge that you do not have stray user names and passwords flying around.
No comments:
Post a Comment