phpass 是安全密码存储的最佳解决方案?

发布于 2024-11-19 19:47:35 字数 713 浏览 1 评论 0原文

我正在创建一项处理大量个人数据的服务,因此让密码简单地泄​​露出去是不合适的。我一直在寻找任何可能的解决方案,其中引起我注意的是 phpass 。我确实在 StackOverflow 上此处读到了相关内容。

我知道关于这个主题有很多问题,但我想澄清一下,phpass 是一种安全的存储密码的方式。我怀疑的原因是它不使用任何盐(至少似乎没有使用),而据我所知,这是安全存储的关键。

我当前的方法只是一个 sha512 哈希,其中包含一个特定于用户的盐和另一个特定于站点的哈希。这是我的 PHP 代码片段:

hash_hmac('sha512', $password.$account_specific, $site_specific);

很高兴听到一些关于此事的专家意见。我很抱歉为这个已经并将永远被问到的主题创建另一个线程。提前致谢。

编辑:
我还听说对密码进行哈希处理(比如说 1000 次)也是存储密码的好方法。这种方式散列只需要几秒钟(最多),但破解散列密码实际上需要很长时间?

I'm creating a service which handles a lot of personal data, and therefor it's not appropriate to let the passwords simply fly out. I've been diggin' around to find any possible solutions, and one that caught my attention is phpass. I did read about it on StackOverflow over here.

I'm aware that there are a lot of questions about this subject, but I'd just like to clarify, that phpass is a secure way of storing passwords. The reason to my suspiciousness is that it doesn't use any salts (at least doesn't seem to use), which are, I've been told, the key to secure storing.

My current method is simply a sha512-hash with one user-specific salt, and another site-specific hash. Here's a clip of my PHP-code:

hash_hmac('sha512', $password.$account_specific, $site_specific);

It would be great to hear some expert-ish opinions on this matter. I apologize for creating another thread for the subject that's been and will always be asked about. Thanks in advance.

EDIT:
I've also heard that hashing a password, let's say, 1000 times is also a good way to store passwords. This way hashing only takes a few seconds (at max), but breaking the hashed password takes literally ages?

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

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

发布评论

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

评论(3

白馒头 2024-11-26 19:47:35

在处理网络安全主题时,不存在“真正的”安全方法。 Web 安全本质上是一场猫捉老鼠的游戏;日常用户是老鼠,黑客是猫。 Web 安全主要是反应性的,这意味着只有在发生安全漏洞时才会考虑新的安全实现。因此,黑客通常比安全实施领先一步。

话虽这么说,您可以采取多种措施来使您的网站更加安全:

1) 使用盐值。

我知道您已经在这样做了,这是一个很好的做法。说使用盐可以使您的应用程序安全是错误的,因为事实并非如此。是的,这使得黑客攻击变得更加困难,但是如果您将盐值存储在数据库中并且最终将整个数据库注入/转储,那么黑客就拥有了使用彩虹表所需的所有信息。使用特定于应用程序的盐是一种额外的安全措施,但同样,如果您的应用程序被黑客攻击并且源代码被获取/反编译,那么黑客就拥有了他们所需的一切。

2) 使用 SSL 证书

确保数据在传入/传出应用程序所在服务器时进行加密是防止数据包嗅探和会话侧劫持的好方法。

3) 使用 SHA2 哈希值

SHA2 哈希值得到广泛实施,并且比其前身 SHA1 安全许多倍。

4) 让您的数据库和应用程序驻留在不同的服务器上。

如果您的数据库位于单独的服务器上(或至少具有单独 IP 的某个位置),那么您可以将对数据库的访问限制为给定的调用 IP 地址/端口。这样做可以确保只能对数据库进行的调用来自您的应用程序。

5) 使用存储过程而不是动态创建查询。

如果您的应用程序中包含逐行构建 SQL 查询的代码,那么攻击者可以使用此信息来绘制数据库的结构,然后有效地注入它。如果您使用存储过程,那么该逻辑将从源代码的角度抽象出来,攻击者无法通过查看它们来深入了解您的数据库结构。

6) 检查所有可能的注入点

尝试破解您自己的应用程序。你最了解它,所以你应该知道它的弱点。虽然开发人员可能会做出一些最差的 QA 人员,但弄清楚您是否留下了可注入的漏洞应该是可能的。您是否在某些地方使用用户输入来格式化查询?如果是这样,请修改输入并看看可以做什么。

根据我的经验,如果你做到了上述所有,那么你就会得到很好的保护。没有什么是 100% 安全的,但除非你持有数十亿美元免费现金捐赠的秘密代码,否则这些障碍将阻止绝大多数黑客(如果不是全部)。曾在一些大公司的网站上工作过,其中一些网站缺乏安全性是荒谬的(咳嗽*咳嗽*索尼咳嗽*咳嗽*)。

还要记住,许多用户喜欢在不同的平台上使用相同的密码。如果用户 A 对所有内容都使用相同的密码,并注册您的网站(一个安全的网站),然后注册另一个网站(不安全且不会散列密码的网站),那么攻击者所要做的就是找到其中最薄弱的链接用户的浏览习惯并从中获取明文密码。

此致,

When dealing with topics of security on the web there is no "true" secure way to do things. Web security is inherently a cat and mouse game; the everyday users are the mice and the hackers are the cats. Web security is primarily reactive, meaning that a new security implementation is only thought of when a breach of security occurs. Because of this hackers are generally one step ahead of security implementation.

That being said, there are a number of things that you can do to make your site more secure:

1) Use salt values.

I know that you are already doing this, and it is good practice. It is wrong to say that using salts makes your application secure, as it doesn't. It makes it much more difficult to hack, yes, but if you're storing salt values in the DB and you end up getting your whole DB injected / dumped then the hacker has all the information they need to use a rainbow table. Using an application-specific salt is an additional measure of security but, again, if your application is hacked and the source code is obtained / decompiled then the hacker has all that they need.

2) Use SSL certificates

Making sure that data is encrypted when going to / coming from the server where your application resides is a good way to protect from packet-sniffing and session side-jacking.

3) Use SHA2 hashes

SHA2 hash values are widely implemented and are many times more secure than their predecessor, SHA1.

4) Have your DB and your application reside on separate servers.

If you have your DB on a separate server (or at least somewhere with a separate IP) then you can restrict access to the DB to a given calling IP address / port. In doing so you can make sure that the ONLY calls that can be made to your database are coming from your application.

5) Use stored procedures instead of dynamically creating queries.

If your application has code in it that structures SQL queries line by line then this information can be used by an attacker to map out the structure of your DB and subsequently effectively inject it. If you use stored procedures then this logic will be abstracted from the source code's perspective and attackers gain no insight into your DB structure by viewing them.

6) Check against all possible injecting points

Try to hack your own application. You know it best, so you should know its weakest points. While developers may make some of the worst QAers out there, figuring out whether or not you left an injectable hole open should be possible. Are there any places in which you're using user input to format queries? If so, mess around with the input and see what you can do.

From my experience if you do all of the above then you are very well protected. Nothing is 100% secure, but unless you are holding secret codes to the billion-dollar-free-cash-give-a-way then these obstacles will deter the vast majority of hackers (if not all of them). Having worked on a handful of large corporations' sites, it is ridiculous the lack of security some of these sites utilize (cough *cough* SONY cough *cough*).

Keep in mind, too, that a lot of users like to use the same password across separate platforms. If user A uses the same password for everything and registers for your site (a secure one) and then another site (one that isn't secure and doesn't hash passwords) then all it takes is the attacker to find the weakest link in a user's browsing habits and get the plain-text password from there.

Best regards,

谁与争疯 2024-11-26 19:47:35

需要注意的是,盐对于防止字典攻击或暴力攻击是没有用的。

如何安全存储密码

It's important to note that salts are useless for preventing dictionary attacks or brute force attacks.

How to safely store a password

紫瑟鸿黎 2024-11-26 19:47:35

我使用这个:

function super_hash($string,$key,$times=2) {
    $hashed_string = SITE_KEY . $string . $key;
    for($i=1;$i<=$times;$i++) {
        $hashed_string = hash_hmac('sha512',$hashed_string,SITE_KEY . $key . 'hardcoded_key');
    }
    return $hashed_string;
}

为了提高安全性(处理速度较慢),只需添加更多迭代($times 参数)。
请注意,仅当您的数据库和代码都受到损害时才需要额外的迭代。

I use this:

function super_hash($string,$key,$times=2) {
    $hashed_string = SITE_KEY . $string . $key;
    for($i=1;$i<=$times;$i++) {
        $hashed_string = hash_hmac('sha512',$hashed_string,SITE_KEY . $key . 'hardcoded_key');
    }
    return $hashed_string;
}

For more security (slower processing), just add more iterations ($times parameter).
Please note that extra iterations are only needed if both your database and your code are compromised.

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