09-10-2014 04:13 PM
Here is no functionality in SAS for decrypting a password encrypted using proc pwencode. You can still use the encrypted password in your SAS programs without knowing what the original password is. The whole point of encrypting a password is to ensure that it cannot be easily decrypted.
It is the responsibility of the person encrypting the password to safely remember or store it somewhere secure such as in a password safe application.
I am curious to know why you want to decrypt - is it simply because the oroginal password has been forgotten?
09-10-2014 06:04 PM
Which "encryption" algorithm have you used? The password should tell you (SAS1, SAS2, or SAS3).
And same question like SASKiwi: Why do you want to decrypt?
09-12-2014 12:44 AM
Proc Pwencode method SAS001 and SAS002 is only encoding. So for these 2 methods there is a way. SAS001 uses Base 64 so this is very simple. What SAS002 uses is not published but I would assume SAS TechSupport could help if really required and proven justified and legal.
SAS003 and SAS004 is real encryption so there I would also say "no way" as much as this can be said considering the SSL story.
09-12-2014 04:39 AM
Not agreed.... SAS002 is MD5 (somewhere) found. SAS003 is coming with SAS/secure must be AES.
Think about the following:
- You can pwencode passwords for external databases.
- External databases can not understand the SAS pwencoding (it is starting with sas isn't it)
- Conclude there is a password decrypt function for pwencode in the SAS environments.
This function is not published, but must be there. How can it work when it does not exist?
When you are in a SAS environment and see a pwencoded string there is no need for decrypting, just do a copy paste to any other location you want and it will work.
There are several other things to think about before claiming pwencode is secure. These two (used obscurity of a function) and being copy paste-able are already serious enough for distrust.
10-04-2014 08:50 AM
Isn't the question if "you" can reverse the password if given to you? Good luck with AES.
Update to my former post:
i found a way to nicely ask the SAS software to decrypt a SAS01-SAS04 password for me. So i can decrypt any password in seconds.
So even even the SAS04 method is not secure. It may use AES internally, but the key for the encryption has to be always the same to reuse the encoded password across different SAS machines and that you can promote your metadata and SAS programs.
"PROC PWENCODE is intended to prevent casual, non-malicious viewing of passwords. You should not depend on PROC PWENCODE for all your data security needs; a determined and knowledgeable attacker can decode the encoded passwords."
So the conclusion is: using pwencode might prevent 99% of all your users from decrypting the password as clear text. But if the last 1% of users could do any damage with the clear text password or could gain access to highly sensitive data you should never rely on PROC PWENCODE!
PROC PWENCODE passwords are not save!
09-12-2014 07:51 AM
If the question is can the password be reverted? Is somebody capable doing that?
The answer is yes. Please give me the function that SAS has hidden and all passwords are capable to be reverted by me.
When I can get in the middle somewhere I could capture the uncrypted versions of passwords. The SAS code could be injected with some malicious software around that.
As there is a technical way to uncrypt it, it is a possible vulnerability.
For fun a similar story with MS-office. You can encrypt that file (AES).
Too many issue people losing password in business environments. There is a docrecrypt tool
Remove or reset file passwords in Office 2013 Using a public key with an escrow key for recovery.
09-12-2014 08:54 AM
decrypting SAS01 is very easy as it is a simple base 64 encoding.
decrypting SAS02 is not that easy, but if you know the trick it is quite easy and just takes a fraction of a second to do it. But this is not officially supported by SAS.
decrypting SAS03 and SAS04: SAS needs to have an internal algorithm to do it. It is just a matter of energy you want to invest to revert it.
Actually i would not rely on any of these methods to be considered secure.
10-04-2014 04:55 PM
Andreas, great you proved that is possible as that decrypt routine should be there (see the why in one of my previous posts)
Coding the pwencode in direct in source is an unsafe habit you can copy it and reuse that everywhere as it is code. The mental switch to make is that there is no need for decryption to do that. The only way to get that save is by storing that in safe well protected OS location.
Reviewing this discussing I do not see the argumentation why someone is asking this kind of questions.
I have seen this coming is a result of the regulations requiring a prudent IT organization and implementation. For that auditors are passing by with some list with questions. The common practiced approach is getting the auditor happy. By that may be ignoring the goal of that list.
Andreas, regulations and Germany that must be DIN ISO/IEC 27002:2008 (27005:2008?). Do you have the content details for those auditability traceability.
10-06-2014 03:11 AM
I am not sure what you mean. I never did an audit, so i don't know the regulations.
Still the key part about security depending on PROC PWENCODED passwords is:
do not think it is save and the password cannot be reverted.
Prefer operating system security (like Integrated Windows Authentication, File System user access rights, ...) or prompt the user for a password.