One issue with many common programming languages is that they appear to
offer access protections via private/protected etc, but seldom do so
securely (`private` modifiers are never, to my knowledge, intended to be a
security mechanism).
/////////////
Take for example C++:
#include <iostream>
#include <cstring>
class Secrets {
private:
const std::string password;
public:
Secrets(const char * password): password(password) {}
};
void consumer(Secrets &sec) {
auto haxor = (const char *)&sec;
for (size_t i=0; i<32; ++i) {
std::cout << haxor + i << std::endl;
}
}
int main() {
Secrets sec("5exret_Paxxw0rd");
consumer(sec);
return 0;
}
/////////////
It's fairly trivial to bypass the `private` access modified for member
variables by reading the memory directly. Even with heap-allocated
structures, this is not much harder to do.
Likewise for Java:
///////
import java.lang.reflect.Field;
import java.lang.NoSuchFieldException;
class MyClass {
private String password;
MyClass(String password) {
this.password = password;
}
}
class Test {
public static void main(String[] a) {
MyClass mc = new MyClass("5exret_Paxxw0rd");
try{
Field f = MyClass.class.getDeclaredField("password");
f.setAccessible(true);
System.out.println((String)f.get(mc));
} catch(Exception e) {
}
}
}
////
Some languages (Java) have optional security managers to try to avoid
allowing such things, but they are not always perfect at preventing
determined users.
My advice would be to design your system to avoid trying to hide
information from users who have the ability to run code from within the
same address space as the secrets you're trying to protect.
Thanks
Steve
On Wed, May 5, 2021 at 2:44 PM Shreyan Avigyan <pythonshreya...@gmail.com>
wrote:
> Private methods, functions and variables are very common in programming
> languages. But Python doesn't support private. It has conventions for
> naming so considered private but not private. Most of the time private is
> never required, what Python provides is more than enough. But the need for
> private come into place when we're dealing with passphrases and servers.
> For example consider this code,
>
> class A:
> def get():
> // code to get the password
> self.password = password
>
> Now consider this,
>
> >>> x = A(); x.get(); x.password
>
> See what just happened? Someone just got the member variable value that
> the person wasn't supposed to.
>
> I suggest to add private support for functions (module __all__ methods to
> be more clear), methods and variables (module __all__ variables or class
> variables).
>
> (I very bad at reading PEPs so I may miss out something critical that's
> been explained already (sometimes I miss out a feature in a PEP and think
> about suggesting that feature when it's already there and then I realize
> "Oh! It's already here in this PEP"). If that's the case then please
> correct me.)
>
> With Regards,
> Shreyan Avigyan
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/DD2L56GCOCWEUBBZBDKKKMPPVWB7PRFB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ESC7EJS667JKJQ2SFKO6RBPHGFM32IAY/
Code of Conduct: http://python.org/psf/codeofconduct/
