保护嵌入的密码

发布于 2024-07-05 11:39:51 字数 156 浏览 5 评论 0原文

我有一个java属性文件,其中存储了我的应用程序的所有信息,例如徽标图像文件名、数据库名称、数据库用户和数据库密码。

我可以将加密的密码存储在属性文件中。 但是,可以使用反编译器从 jar 中读取密钥或密码。

有没有办法将数据库通行证安全地存储在属性文件中?

I have a properties file in java, in which I store all information of my app, like logo image filename, database name, database user and database password.

I can store the password encrypted on the properties file. But, the key or passphrase can be read out of the jar using a decompiler.

Is there a way to store the db pass in a properties file securely?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

高跟鞋的旋律 2024-07-12 11:39:51

有多种方法可以管理这个问题。 如果您能找到一种方法,让用户在应用程序启动时为密钥库提供密码,最合适的方法是使用密钥加密所有值,并将该密钥存储在密钥库中。 密钥库的命令行界面是使用 keytool。 然而,JSE 也有 API 可以通过编程方式访问密钥库。

如果您无法让用户在启动时手动向密钥库提供密码(例如对于 Web 应用程序),一种方法是编写一个异常复杂的混淆例程,该例程可以混淆密钥并将其存储在还有一个属性文件。 需要记住的重要一点是,混淆和反混淆逻辑应该是多层的(可能涉及加扰、编码、引入虚假字符等),并且本身应该至少有一个可以隐藏在应用程序中其他类中的密钥使用不直观的名称。 这不是一种完全安全的机制,因为拥有反编译器和相当多的时间和智力的人仍然可以解决它,但这是我所知道的唯一不需要您闯入本机(即不易反编译)代码的机制。

There are multiple ways to manage this. If you can figure out a way to have a user provide a password for a keystore when the application starts up the most appropriate way would be to encrypt all the values using a key, and store this key in the keystore. The command line interface to the keystore is by using keytool. However JSE has APIs to programmatically access the keystore as well.

If you do not have an ability to have a user manually provide a password to the keystore on startup (say for a web application), one way to do it is to write an exceptionally complex obfuscation routine which can obfuscate the key and store it in a property file as well. Important things to remember is that the obfuscation and deobfuscation logic should be multi layered (could involve scrambling, encoding, introduction of spurious characters etc. etc.) and should itself have at least one key which could be hidden away in other classes in the application using non intuitive names. This is not a fully safe mechanism since someone with a decompiler and a fair amount of time and intelligence can still work around it but is the only one I know of which does not require you to break into native (ie. non easily decompilable) code.

橘亓 2024-07-12 11:39:51

您将密码的 SHA1 哈希值存储在属性文件中。 然后,当您验证用户密码时,您会对他们的登录尝试进行哈希处理并确保两个哈希值匹配。

这是将为您散列一些字节的代码。 您可以使用 getBytes() 方法轻松地从字符串中获取字节。

/**
     * Returns the hash value of the given chars
     * 
     * Uses the default hash algorithm described above
     * 
     * @param in
     *            the byte[] to hash
     * @return a byte[] of hashed values
     */
    public static byte[] getHashedBytes(byte[] in)
    {
        MessageDigest msg;
        try
        {
            msg = MessageDigest.getInstance(hashingAlgorithmUsed);
        }
        catch (NoSuchAlgorithmException e)
        {
            throw new AssertionError("Someone chose to use a hashing algorithm that doesn't exist.  Epic fail, go change it in the Util file.  SHA(1) or MD5");
        }
        msg.update(in);
        return msg.digest();
    }

You store a SHA1 hash of the password in your properties file. Then when you validate a users password, you hash their login attempt and make sure that the two hashes match.

This is the code that will hash some bytes for you. You can easily ger bytes from a String using the getBytes() method.

/**
     * Returns the hash value of the given chars
     * 
     * Uses the default hash algorithm described above
     * 
     * @param in
     *            the byte[] to hash
     * @return a byte[] of hashed values
     */
    public static byte[] getHashedBytes(byte[] in)
    {
        MessageDigest msg;
        try
        {
            msg = MessageDigest.getInstance(hashingAlgorithmUsed);
        }
        catch (NoSuchAlgorithmException e)
        {
            throw new AssertionError("Someone chose to use a hashing algorithm that doesn't exist.  Epic fail, go change it in the Util file.  SHA(1) or MD5");
        }
        msg.update(in);
        return msg.digest();
    }
汹涌人海 2024-07-12 11:39:51

除了如上所述对密码进行加密之外,还将所有密码放入单独的属性文件中,并在部署时尝试为该文件提供尽可能多的锁定权限。

例如,如果您的应用程序服务器以 root 身份在 Linux/Unix 上运行,则使用 400/-r----- 使密码属性文件归 root 所有。 --- 权限。

In addition to encrypting the passwords as described above put any passwords in separate properties file and on deployment try to give this file the most locked down permissions possible.

For example, if your Application Server runs on Linux/Unix as root then make the password properties file owned by root with 400/-r-------- permissions.

新人笑 2024-07-12 11:39:51

您可以为密码(直接数据库密码或密钥密码)创建一个单独的属性文件(在 jar 之外),并且不将该属性文件包含在发行版中。 或者您可以使服务器仅接受来自特定计算机的登录,以便需要欺骗。

You could make a separate properties file (outside the jar) for passwords (either direct DB password or or key passphrase) and not include that properties file with the distribution. Or you might be able to make the server only accept that login from a specific machine so that spoofing would be required.

旧时模样 2024-07-12 11:39:51

不,那里没有。 即使你加密了它,有人也会反编译解密它的代码。

No there is not. Even if you encrypt it, somebody will decompile the code that decrypts it.

楠木可依 2024-07-12 11:39:51

当然,在以某种方式进行身份验证后,您不能让应用程序通过 https 联系服务器并下载密码吗?

Couldn't you have the app contact a server over https and download the password, after authenticating in some way of course?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文