标签: salt

像大多数程序员一样,我不是密码学方面的专家,但我理解基础知识.然而,正如Jeff的博客文章所述,一点点知识可能是一件危险的事情.考虑到这一点,我理解盐值的目的但我需要一些帮助来理解如何使用盐值.

我已经阅读过关于这个主题的其他帖子,最好使用随机盐值来加密每个密码.如果是这种情况,当我尝试对用户进行身份验证时,如何重现该随机盐值？在这种情况下,我会加密用户提供的明文密码,对其进行加密,并将其与存储在数据库中的密码进行比较.在创建密码时,是否将随机盐值与加密密码一起存储在用户记录中？如果黑客拥有完整的用户记录,这会使盐值无用吗？

我可以潜入Kohana_Cookie课程并设置

public static $salt = 'blah';

但这似乎不是一个非常优雅的解决方案......是否有一种方法可以在配置中设置它？尝试谷歌搜索,但没有运气......

前几天我在课堂上，我们正在谈论 Unix SALT 以及它如何使密码更难猜测。我的问题是 SALT 以明文形式存储在散列密码旁边，那么如何使其更安全？我的意思是如果 SALT 就在那里，那么你附加它然后散列你的猜测。此外，关于在彩虹表中预先计算猜测的问题对我来说也没有意义。您只需查看 SALT 并首先使用给定的 SALT 预先计算它。我能想到的唯一论点是恶意用户无法访问 /etc/password 文件，但黑客如何知道密码的哈希值。如果有人能指出我正确的方向，我将不胜感激。谢谢！

我一直在做一些关于在数据库中安全存储密码的研究。通常建议您使用盐。正如Secure hash and salt for PHP passwords中的一个答案所解释的那样，这会更改哈希值，使密码更难以破解。

作为验证机制的一部分，用户输入的密码与盐结合并根据需要进行散列。鉴于盐对用户是透明的，使用盐如何提供任何额外的好处？

在我看来，无论有没有散列，相同的密码都将成功验证您的身份，因为使其与众不同的管道将在幕后进行。这就是为什么到目前为止我读过的文章都没有澄清事情的原因。

我一直在寻找加密密码以供我的面板使用的最佳方法，我决定继续使用 BCRYPT，这仅仅是因为每次加密的成本以及它通常被认为是目前最好的加密方法之一。当前时间。

我使用的是双向盐，因此每个用户都有一个独特的盐，然后显然是存储在我的应用程序中的盐，我注意到一些相当奇怪的行为..根据 PHP 文档，这种行为是否正常？

无论如何，这是我使用的代码：

$Crypto = new Crypto;
echo $Crypto->encrypt( "123456789abcdefghijklm", "StackOverflow_Is_Awesome!" ); // First parameter being the "User Salt", second being the password.

// Above outputs $2y$13$123456789abcdefghijkleepFY8JLvsf2YbnWolqQyO3DIzrCeNIu

现在，加密类：

<?php
// ASSUMING $this->hashingSalt = HBSNi3y7ruhbVGkhdg83ijdbvghiojkgudL;JP
class Crypto {

private $hashingSalt, $database;

public function __construct( $salt )
{
    $this->hashingSalt = $salt;
    $this->database = new DatabaseFunctions();
}

public function encrypt( $salt, $password )
{
    $options = array(
        'cost' => 13,
        'salt' => $salt //22 chars
    );

    return password_hash( $password . …

我有一段时间没有写加密了，忘记了一些东西。

我记得为了让使用相同密钥的相同数据的输出不同，我想在字节数组的一端对数据加盐，然后使用 CBC 模式，以便盐可以发挥作用。

但是我不记得加密的方向。盐应该放在位置0，然后要加密的数据放在它后面，还是盐放在最后？我知道当盐是链中的第一个块时，CBC 模式效果最好。

另外，AES 256 的块大小是多少？wiki 文章说所有 AES 都使用 128 位块大小，并且 256 部分仅与密钥长度相关。那么 AES 256 的盐应该是 16 字节还是 32 字节？

我使用的是 AesCryptoServiceProvider，而不是 RijndaelManaged。

我需要加密双向（对称）不同的令牌。这些令牌预计会重复（例如，它们是人的名字），但我不希望攻击者断定哪些加密令牌来自相同的原始令牌。Salt 是单向加密（散列）的一种方法。

是否有一种可以在对称加密中工作的方法、解决方法或替代方案？

我目前正在开发一个PHP项目,我想知道如何使我的系统尽可能安全.我目前正在使用password_hash哈希密码,然后将它们存储在我的数据库中.我想知道的是:将新的盐渍哈希重新保存并重新保存到数据库会增加安全性,还是仅仅是一种错觉？

我正在为带有 Spring Boot 的在线商店在 Java 中创建 REST API，我想将用户密码安全地存储在数据库中，为此我使用 Spring Security 附带的 BCrypt，我使用 MySQL 和 JPA-Hibernate 进行持久化.

我正在按如下方式实施它：

这是用户实体：

@Entity
@SelectBeforeUpdate
@DynamicUpdate
@Table (name = "USER")
public class User {

    @Id
    @GeneratedValue
    @Column(name = "USER_ID")
    private Long userId;

    @Column(name = "ALIAS")
    private String alias;

    @Column(name = "NAME")
    private String name;

    @Column(name = "LAST_NAME")
    private String lastName;

    @Column(name = "TYPE")
    private String type;

    @Column(name = "PASSWORD")
    private String password;

    public String getPassword() {
        return password;
    }

    /**
    * When adding the password …

我希望我没有创建重复的问题。我试图寻找已经存在的问题，但我什么也没找到。

我已经成功地设置了一个数据库，其中包含用于登录的用户名、盐和散列密码。为了检查密码，我将生成的散列与数据库之一进行了比较，请参阅下面的代码。

password_hashed_from_user = res[0][0]
salt = res[0][1]

key_generated = hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), base64.b64decode(salt.encode('utf-8')), 100000, dklen=128)
key_encoded = base64.b64encode(key_generated).decode('utf-8')

if key_encoded != password_hashed_from_user:
    logging.debug("Password was wrong:\n{}\n{}".format(key_encoded, password_hashed_from_user))
    return "Username and/or password incorrect", False

现在的问题是，我希望用户能够完全匿名地进行操作，这意味着我希望用户能够使用生成的令牌进行识别，而该令牌无法追溯到他的帐户。

因此，我需要将令牌存储在一个单独的表中，而不是与具有凭据的表相关联。为了让用户不能作弊并且每次登录时都向服务器询问新令牌（因此充当新用户），我想根据凭据计算令牌。

所以我想，我可以有一个单独的盐并根据密码创建一个新的哈希（使用与代码示例中相同的方法）。由于密码本身并未存储在服务器上，因此如果没有用户本身的密码，就无法生成此散列。

这样，生成的令牌总是相同的，只要盐不改变。因此，我可以确保始终将特定用户标识为同一用户，而用户可以确保我无法追溯他的操作。

背景

背景是我需要创建一个投票环境，人们必须在这个环境中进行注册和身份验证，以防止重复投票，但投票结果，以及参与等不应追溯到特定用户。由于这是我研究中的一个项目，我不能只使用现有的框架/库。

现在我的问题：

在同一服务器上存储具有不同盐的相同密码的两个单独哈希值是否安全，或者重复是否可以重新创建实际密码？两种盐将与其中一个散列一起存储在一起。另一个散列将在一个单独的、不相关的表中。

在那个级别上，我总是在加密方面遇到一些困难。