Python 中的字符串混淆
我有一个必须传递给方法的密码字符串。 一切正常,但我觉得以明文形式存储密码不太舒服。 有没有办法混淆字符串或真正加密它? 我知道混淆可以进行逆向工程,但我认为我至少应该尝试稍微掩盖密码。 至少它对于索引程序是不可见的,或者快速浏览我的代码的杂散眼是不可见的。
我知道 pyobfuscate 但我不希望整个程序被混淆,只是一个字符串,可能还有定义变量的整行本身。
目标平台是 GNU Linux Generic(如果这有区别的话)
I have a password string that must be passed to a method. Everything works fine but I don't feel comfortable storing the password in clear text. Is there a way to obfuscate the string or to truly encrypt it? I'm aware that obfuscation can be reverse engineered, but I think I should at least try to cover up the password a bit. At the very least it wont be visible to a indexing program, or a stray eye giving a quick look at my code.
I am aware of pyobfuscate but I don't want the whole program obfuscated, just one string and possibly the whole line itself where the variable is defined.
Target platform is GNU Linux Generic (If that makes a difference)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
如果您只是想防止随意查看密码,您可能需要考虑将密码编码/解码到 base64。 它一点也不安全,但密码不会被人类/机器人随意读取。
If you just want to prevent casually glancing at a password, you may want to consider encoding/decoding the password to/from base64. It's not secure in the least, but the password won't be casually human/robot readable.
显然,您最好的选择是将其委托给第三方。 如果您可以使用其他凭据(例如您的进程运行时使用的用户帐户)对要连接的任何内容进行身份验证,则可以将权限级别留给操作系统层。 或者,如果足够重要/可能,您可以提示用户(将密钥存储在(可以说)稍微不易破解的湿软件中)
如果您确实需要存储一些密码或密钥,我建议您将其与您的代码分开存储在您读入的文件中,并在必要时进行反混淆。 这样做的优点是:
您可以尽可能严格地设置文件的文件权限(即只能由您的程序运行的帐户读取),这与程序的其余部分可能会被更多人读取不同。
您不会意外地将其签入版本控制系统!
Python 字符串不需要限制为可打印字符(或使用尴尬的转义),因此如果可能的话,您可以使用任意密钥文件,而不是人类可读的密码。 如果不是人工输入的,就没有理由拥有密码的所有弱点。
为了进行混淆,您可以按照建议使用 base64,或者使用一些自制方案,例如异或或使用存储在其他地方的另一个密钥进行解密,需要查看两个位置。 请注意,除了机会主义的肩窥(如果有的话)之外,这并不能防止任何其他事情 - 确保也有一定程度的真实安全性(包括明显的安全性,例如对机器的物理访问!)
Obviously your best option is to delegate this to a third party. If you can authenticate with whatever you're connecting to using some other credential (eg. the user account your process is running as), you can leave the permission levels up to the OS layer. Alternatively, if sufficiently important / possible you could prompt the user (storing the key in the (arguably) slightly less hackable wetware instead)
If you do need to store some password or key, I'd recommend you store it seperate from your code, in a file you read in, and de-obfusticate if neccessary. This has the advantages that:
You can set the file permissions on the file as tight as possible (ie. only readable by the account your program runs as), unlike the rest of your program which may be read by more people.
You won't accidently check it into your version control system!
No need to be restricted to printable characters (or use awkward escaping) for a python string, so you can use an arbitrary keyfile if possible, rather than a human readable password. If it's non human-entered, there's no reason to have all the weaknesses of passwords.
To obfusticate, you can use base64 as suggested, or some home-brew scheme like XORing or decrypting with another key stored elsewhere, requiring both locations to be looked at. Be aware that this doesn't protect against anything beyond opportunistic shoulder surfing (if that) - make sure that there is some level of real security as well (including obvious ones like physical access to the machine!)
您首先应该避免明文存储密码。 这是唯一“真正”的解决方案。
现在,您可以使用哈希模块(md5 以及 python 2.5 及以下版本中的类似模块)轻松加密密码。
You should avoid storing the password in clear in the first place. That's the only "true" solution.
Now, you can encrypt the password easily with the hash module (md5 and similar modules in python 2.5 and below).
许多接受密码的协议和设施都可以指定密钥文件而不是密码。 这个策略在这里可能会奏效。 与其对密码进行硬编码,不如对文件名进行硬编码(或者更好的是,将其作为参数!)。 您甚至可以使用 SSH 并拒绝加载不 (1) 当前用户拥有 (2) 仅该用户可读的密钥文件。
Many password-accepting protocols and facilities have a way to specify a keyfile rather than a password. That strategy will probably work here; rather than hard-coding a password, hard-code a filename (or better yet, make it a parameter!). You could even go as far as SSH and refuse to load keyfiles that aren't (1) owned by the current user (2) only readable by that user.
这在很大程度上取决于您保留密码的原因以及您认为存在安全问题的地方。
如果您将来要将此密码存储或与数据库匹配:
这实际上应该不是问题,但如果您担心,请尽早使用数据库的密码加密并存储该密码( SELECT PASSWORD('mySamplePassword'); ),然后在以后的查询中直接比较加密版本。
如果您要保存它以供以后传输:
您确实无能为力。 传输本身很可能比您对密码的处理更容易被嗅探。
如果不知道你正在做的事情的更多细节,这个问题很难回答。
It depends alot on why you're keeping the password around, and where you feel there is a security issue.
If you're storing or matching this password to a database in the future:
This shouldn't really be a problem, but if you're concerned, use your database's password encryption early and store that ( SELECT PASSWORD('mySamplePassword'); ), then compare the encrypted version directly in your later query.
If you're saving it for later transmision:
There really isn't much you can do. The transmission itself is very likely to be easier to sniff than your handling of the password.
Without knowing a few more details of what you're doing, this is sortof hard to answer.
Base64 答案非常适合混淆密码,并且无需用户干预即可工作,但代价是不安全。 如果用户可以登录并访问系统密钥环服务,请查看密钥环包裹。 我用它来存储 OS X 和 Linux 系统上的密码。
The base64 answer is good for obfuscating the password and will work with no user intervention at the cost of being insecure. If the user can be logged in with access to a system keyring service, take a look at the keyring package. I used it to store passwords on both OS X and Linux systems.