保护嵌入的密码

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

如果您没有能力让用户在启动时手动为密钥库提供密码(例如,对于Web应用程序),那么一种方法是编写一个异常复杂的模糊处理例程,该例程可以模糊密钥并将其存储在属性文件中。要记住的重要一点是,模糊和去模糊逻辑应该是多层的(可能涉及到置乱、编码、引入伪字符等),并且它本身应该至少有一个键,可以使用非直观名称隐藏在应用程序的其他类中。这不是一个完全安全的机制,因为有一个拥有反编译器和大量时间和智能的人仍然可以解决这个问题,但这是我所知道的唯一一个不需要你破解本机(即不容易反编译)代码的机制。

您将密码的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();
    }

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

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

除了如上所述对密码进行加密之外,请将任何密码放在单独的属性文件中,并在部署时尝试授予此文件尽可能多的锁定权限。

例如,如果您的应用服务器在Linux/Unix上以 root 然后使密码属性文件归 根 用400 -r-------- 权限。

在以某种方式进行身份验证之后,难道你不能让应用通过https与服务器联系并下载密码吗?