Re^5: use of already eval()ed module (from string)

Replies are listed 'Best First'.
Re^6: use of already eval()ed module (from string) by bliako (Abbot) on Jan 14, 2019 at 16:50 UTC
If you are afraid that the decryption key could be read from memory, switch to a algorithm which encrypts the key. I know this is not Perl any more but can I ask you if you have handy some pointers for the above? Yes there is XOR or some other obfuscation but the parameters (e.g. XOR operand) must be saved somewhere too... and so on. Just to clarify: I do not need a digest/hash because the actual password must be decoded in order to pass it on to DB for connecting. Here is a scenario: program needs to connect to DB (many times, not just once). So the first time it runs, it asks the user to supply the password (or even user supplies it via commandline - we know the risk of that). Said program stores password in memory for whenever connecting to DB. Someone (root) does a memory dump of the running process and the password is in there (somewhere). If the password was encrypted somehow then the key will be in the memory dump too (unless it is read from a file etc. but that could prove risky AND expensive). So, the program does not contain the password but when it is run, it must store the password in program memory. How to encrypt that? What do people do in such cases? bw, bliako (newbie encrypter)	[reply]
Re^7: use of already eval()ed module (from string) by afoken (Chancellor) on Jan 15, 2019 at 07:57 UTC
Said program stores password in memory for whenever connecting to DB. Someone (root) does a memory dump of the running process and the password is in there (somewhere). If the password was encrypted somehow then the key will be in the memory dump too (unless it is read from a file etc. but that could prove risky AND expensive). So, the program does not contain the password but when it is run, it must store the password in program memory. How to encrypt that? What do people do in such cases? See also Hide DBI password in scripts. Ultimately, the password has to leave the perl process to be passed to the database. That usually happens in plaintext, and usually using network functions. So all that is needed to get the password is strace. Theoretically, databases could implement Challenge–response authentication, so that the password is never transmitted, neither in plaintext nor encrypted. I've never seen that implemented AND used. I guessed that recent versions of PostgreSQL could have some implementation, and I was right: Pg 10 and 11 have scram-sha-256, but it requires recent client libraries: `scram-sha-256` The method `scram-sha-256` performs SCRAM-SHA-256 authentication, as described in RFC 7677. It is a challenge-response scheme that prevents password sniffing on untrusted connections and supports storing passwords on the server in a cryptographically hashed form that is thought to be secure. This is the most secure of the currently provided methods, but it is not supported by older client libraries. More details in Salted Challenge Response Authentication Mechanism. Note that SCRAM-SHA-256 has to be configured at the server side, the client can't choose the authentication mechanism. For other databases, RTFM. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^8: use of already eval()ed module (from string) by bliako (Abbot) on Jan 15, 2019 at 11:23 UTC
Those links you provided are useful to know what the limits are and the margins of futility - pretty wide. thanks.	[reply]
Re^7: use of already eval()ed module (from string) by kschwab (Vicar) on Jan 14, 2019 at 20:10 UTC
There's really no magic to storing credentials. You can obfuscate them, encrypt them, and so on. But, since the end user ultimately has to use them, they are plaintext somewhere at some time. Some people use a software vault. The end user can still play games and get the password, but with a vault, you at least have a central place to control who gets the key, expiration dates, changing it, etc. Hashicorp's Vault is popular in this space.	[reply]
Re^7: use of already eval()ed module (from string) by LanX (Saint) on Jan 14, 2019 at 20:51 UTC
My idea was that you are assuming that compiled code is safe (hard to decipher) a memory dump reveals any password too easily Inside of these presumptions using code to deencrypt the key should be "safe" Simple example a loop doing XORs with values from a nested table. XORs are easily reversed. Plus some rotations if you want and gotos depending on temporary values in the middle. Sorry, no ready to use suggestions. Of course one could use B::Deparse to disassemble the Op-tree, but that's always the case. HTH! :) update You could create such an algorithm with random values. It's only important that there is no information loss that it halts For clarification the algorithm would act here as the key. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^8: use of already eval()ed module (from string) by bliako (Abbot) on Jan 15, 2019 at 11:30 UTC
At this point i will set my goal as to be able to protect a password from a memory dump of a running script (re: password is specified by user at runtime, it is not stored in script but in script's runtime memory) by obfuscating it along your suggestions. I searched on CPAN for something similar to C#'s SecureString but couldn't find any.	[reply]
Re^9: use of already eval()ed module (from string) by LanX (Saint) on Jan 15, 2019 at 11:34 UTC
Re^10: use of already eval()ed module (from string) by bliako (Abbot) on Jan 15, 2019 at 12:08 UTC
Some notes below your chosen depth have not been shown here

update