You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is another way to completely deactivate the administrators ability to recreate whatever happened during the session.
Using encryption surely means using a custom, complex shell. Crypto in PHP < 7 sucks hard, but could it be enough? Ideal would be the use of libsodium and maybe Halite, but impossible to do all that in the remote server... So it would have to be a small, simple, native implementation of crypto and authentication. Maybe ShellComm should ask the user if it wants to use crypto, and spit a shell code for him/her to use.
Another point is: if the encryption key remains in the PHP code, then encrypting would just become simply obscurity. Deleting the shell after the session is over is a possibility. If not, perhaps there could be a way to make the shell negotiate the encryption key for the session and store it in-memory only. Then again, this isn't 100% failsafe because there exists many mechanisms through which read the memory, and PHP can't truly wipe it, but it's far better than writing the key in the code.
I wouldn't want to make ShellComm horribly complex, though.
I'm open to ideas in this regard.
The text was updated successfully, but these errors were encountered:
This is another way to completely deactivate the administrators ability to recreate whatever happened during the session.
Using encryption surely means using a custom, complex shell. Crypto in PHP < 7 sucks hard, but could it be enough? Ideal would be the use of libsodium and maybe Halite, but impossible to do all that in the remote server... So it would have to be a small, simple, native implementation of crypto and authentication. Maybe ShellComm should ask the user if it wants to use crypto, and spit a shell code for him/her to use.
Another point is: if the encryption key remains in the PHP code, then encrypting would just become simply obscurity. Deleting the shell after the session is over is a possibility. If not, perhaps there could be a way to make the shell negotiate the encryption key for the session and store it in-memory only. Then again, this isn't 100% failsafe because there exists many mechanisms through which read the memory, and PHP can't truly wipe it, but it's far better than writing the key in the code.
I wouldn't want to make ShellComm horribly complex, though.
I'm open to ideas in this regard.
The text was updated successfully, but these errors were encountered: