PHP 登录脚本(安全但不像银行金库)

发布于 2024-09-27 21:22:32 字数 225 浏览 0 评论 0原文

正在寻找 php 登录脚本。我搜索了 stackoverflow 并看到了很多帖子,但是有人可以推荐最好的方法吗?另外,如果我想使用散列,检索时如何解码密码?我的 iPhone 应用程序使用相同的数据库,目前密码以普通文本存储(我知道不是很安全)。

另外,如果我实现一个重定向到info.php的登录页面,如何阻止用户在不登录的情况下直接进入info.php页面,会话控制?

期待听到您的意见。非常感谢。

Looking for a php login script. I've searched stackoverflow and have seen a lot of posts, but can anyone recommend the best method? Also, If I want to use hashing, how do you decode the password when retrieving? My iPhone app uses the same database and currently the passwords are stored in normal text (not very secure, I know).

Also, if I implement a login page that redirects to info.php, how do you stop the user from going directly to the info.php page without logging in, Session control?

Look forward to hearing your input. Thanks very much.

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

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

发布评论

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

评论(7

岁吢 2024-10-04 21:22:32

我的回答有点晚了,但无论如何我都会发布,我知道这并不能直接回答问题,但它仍然相关。以下是有关登录安全的几点。

记住我

您最好重新散列散列密码,并将重新散列存储在用于自动登录用户的 cookie 中。重新散列密码时,使用特定于浏览器的内容作为种子例如浏览器类型。这将有助于防止 cookie 被窃取(通过人们窥探网络流量)。这有助于防止任何使用彩虹表的机会。

会话

注意会话劫持:http://en.wikipedia.org/wiki /Session_hijacking

CSRF

跨站请求伪造 - 登录后实施,但需要注意的是,它只影响登录的成员:http://en.wikipedia.org/wiki/Cross-site_request_forgery

HTTPS

页面上应使用 HTTPS登录请求正在发送至 - 它不必位于您正在输入登录详细信息的页面上!

散列

您可以使用 javascript 对密码客户端进行散列,这只会在不使用 HTTPS 时通过网络传输密码时保护成员的密码免遭窃取。这很好,因为许多人经常在许多网站上使用相同的密码。缺点是:无法在服务器端检查密码长度&如果禁用 javascript,他们将无法登录(尽管您可以在一定程度上围绕该问题进行编程)。雅虎几年前曾经(可能仍然这样做)这样做。

当您在服务器上收到密码时,通常会使用种子对其进行重新哈希并存储在数据库中。这更安全,因为即使人们知道哈希值,他们仍然无法登录!只有原始密码才会重新哈希为允许用户登录的相同哈希值。

键盘记录器

如果您想绕过键盘记录器(或大多数键盘记录器),您可以通过添加 JavaScript 小键盘/键盘来实现。然后,用户使用鼠标而不是键盘单击字母和数字来输入密码,这意味着键盘记录器很难记录密码。

知道某事、拥有某事、是某事

三个安全级别。某人知道的东西,例如密码,某人拥有的东西,例如电话(谷歌使用两步验证完成前两个),以及某人拥有的东西,例如指纹。您满足的这些要求越多,您的安全凭证就越高 - 绝对是好的!!!

机器人

计算机有时会尝试暴力破解快速登录页面(必须快得就像密码不正确并且脚本暂停哪怕只是 1 秒一样,这大大减少了机器人可以进行的总登录尝试次数。 让机器人在 X 次错误登录后很难解决(就像谷歌那样)。

为了帮助阻止这种情况,你可以暂停错误登录 1 或 2 秒(就像 Linux 那样),或者你可以生成一个捕获, 我确信还有其他人。

Bit late for my answer, but i'll post anyway and i know this doesn't directly answer the question but it is related non the less. Here are a few points about login security.

Remember Me

You are best to re-hash the hashed password, and store the rehash in the cookie used to automatically log the user in. When you rehash the password, use something specific to the browser as a seed such as the browser type. This will help prevent the cookie being stolen (via people snooping on the network traffic). This helps prevent any chance of using rainbow tables.

Sessions

Be aware of session hijacking: http://en.wikipedia.org/wiki/Session_hijacking

CSRF

Cross Site Request Forgery - Implemented after you login, but something to be aware of since it only affects logged in members: http://en.wikipedia.org/wiki/Cross-site_request_forgery

HTTPS

HTTPS should be used on the page the login request is being sent to - it does NOT have to be on the page you are typing your login details on!

Hashing

You can hash a password client side using javascript which would only server to protect members from having their passwords stolen while transfering them over the network when not using HTTPS. This is good because many people often use the same password for many sites. The disadvantages are: you can't check password length server side & they can't loggin if javascript is disabled (though you can program around that to a degree). Yahoo used to (might still do) do this years ago.

When you recieve the password on the server it is often rehashed using a seed and stored in the database. This is more secure as even if people know the hash, they still can't login! Only the original password will rehash to the same hash letting the user login.

Keyloggers

If you want to get around keyloggers (or most of them) you can do so by adding a JavaScript keypad / keyboard. The user then clicks the letters and numbers to enter their password using the mouse instead of the keyboard meaning the keylogger has a hard time logging the password.

Know Something, Has Something, Is Something

The three levels of security. Something someone knows such as a password, something someone has such as a phone (google completes these first 2 using 2 step verification), and something someone is such as a finger print. The more of these you fullfill the greater your security credentials are - by a long shot!!!

Bots

Computers sometimes try to brute force a fast login page (must be fast as if the password is incorrect and the script pauses for even just 1 second, that greatly reduces the total login attempts a bot can make. To help stop this you can either pause an incorrect login for 1 or 2 seconds (like linux does) or you can produce a capture that bots have a hard time solving after X incorrect logins (like google does).

There the main points, but i'm sure there are others.

巷子口的你 2024-10-04 21:22:32

这是一个很棒的教程< /a> 关于登录系统设计。它以面向对象的方式涵盖了所有主要主题,非常适合了解不同的注意事项。

可解码的密码并不那么安全,但我的客户坚持认为他们能够随意检索和更改密码,无一例外。因此,在某些情况下,我选择对 Base64 编码的字符串进行加盐处理以存储在数据库中,这似乎效果很好。存在一个功能可以根据管理员用户的需要进行编码/解码。

事实上,会话控制(和/或cookie)是控制访问的方法。使用面向对象的模式构建它将使您只需每页一两行代码(或者标题中的一行代码,如果常见的话)即可做到这一点。

我的一个警告是考虑您是否具有通用登录级别或需要用户级权限。构建网站后,要确定基于权限的登录是否重要,需要做更多的工作。如果一开始没有计划,它可能会成为真正的怪物。

This is a great tutorial on login system design. It covers all the major topics in an object oriented manner and is great for learning about the different considerations.

Decodable passwords are not as secure as they could be, but I've had clients insist that they be able to retrieve and change the password at will, no exceptions. So in some cases I opted to salt a base64 encoded string to store in the database, and that seems to work pretty well. A function exists to encode/decode as needed for the admin user.

Indeed, session control (and/or cookies) are the method to control access. Building it with an object oriented pattern would allow you to do that with just a line or two of code per page (or a line in a header if it's common).

My one warning is to consider if you have a common login level or need user-level permissions. It's significantly more work to decide after you've built the site that permissions-based logins are important. It can become a real monster if not planned for in the beginning.

芸娘子的小脾气 2024-10-04 21:22:32

POST 到 HTTPS URL。

您永远不会解码哈希密码。丢失的密码需要另一种机制来处理。

是的,会话控制。在登录时在会话中设置一个标志,并在其他页面上检查它。

POST to a HTTPS URL.

You never decode the hashed password. Lost passwords need another mechanism to handle.

Yes, session control. Set a flag in the session on login and check for it on the other pages.

最好是你 2024-10-04 21:22:32

仍在开发中,但安全、快速、干净、良好且最新:

[最新版本] https://github.com/Panique/PHP-Login

[旧版本网站] http://www .php-login.net

我和一些设计师一起创建了这个编码器帮助。它已在多个论坛上进行了讨论并得到了非常积极的答复。所有当前问题都可以在 github 问题页面上查看。所有代码都是公开、免费且可分叉的。

Still under development, but secure, fast, clean, good and up-to-date:

[up to date version] https://github.com/Panique/PHP-Login

[old version's website] http://www.php-login.net

I've created this with some designer & coder help. It has been discussed in several forums and got very positive replies. All current issues can be seen on the github issue page. All code is public, free and forkable.

帥小哥 2024-10-04 21:22:32

您不需要解码密码,您必须将散列密码存储在数据库中,并且当用户尝试登录时,您将存储的密码与输入密码的散列进行比较。

关于info.php,是的,如果登录成功,您可以在会话中分配一个变量,并且要测试用户是否已登录,您只需测试该变量是否已分配。

You don't need to decode the password, you will have to store the hashed password in your database, and when the user tries to login, you compare the stored password with the hash of the entered password.

About info.php, yes, if login succeeds you assign a variable in your session, and to test if the user is logged, you just test if that variable is assigned or not.

西瑶 2024-10-04 21:22:32

基本上,您对密码进行哈希处理,以便无法出于恶意目的检索密码,哈希值而不是明文密码存储在数据库中,您只需比较 2 个哈希值。

您的客户端可以根据需要存储密码,但 Web 应用程序应在每一步控制会话有效性(在会话变量中存储一些已登录的标识符,并具有适当的过期时间或类似的内容),
所以基本上你在每个“受保护”页面中 require("session_control.inc") ,这样你就可以检查会话有效性。

最好的方法是使用 MVC 框架,它可以帮助定义这种情况下的逻辑。

basically you hash your password so it cannot be retrieved for malicious purpose, the hash is stored in the database instead of the password in clear text, you only compare the 2 hash values.

your client can store the password as they want, but the web application should control at each step the session validity (store some logged in identifier in the session variables with proper expiration or something like that),
so basically you require("session_control.inc") in every "protected" page so you could check for the session validity.

The best course would be to use an MVC framework which could help in defining the logic in that case.

2024-10-04 21:22:32

您可以使用密码散列,但也有 php 的 crypt() 函数 http://php.net /manual/en/function.crypt.php

它们本质上做同样的事情,但在我看来 crypt 更简洁一些。确保您还获得了一个好的盐生成脚本,因此当您将密码保存在数据库中时,这是我的密码加密函数,请注意,如果没有盐函数,这并不安全

function crypt_password($password)
{
    if($password){
        //blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 base 64
        $blowfish = '$2a$10

,然后当您想要验证此密码时,您只需查询登录电子邮件或用户 ID 的数据库,然后验证其简单如下

if (crypt($input_pass, $stored_pass) == $stored_pass) {
    return true;
}
; //get the random bytes and makes a salt $salt = $this->get_salt(); //append salt2 data to the password, and crypt using salt, results in a 60 char output $crypt_pass = crypt($password,$blowfish . $salt); //blowfish comes out as 60, check $len = strlen($crypt_pass); if($len == 60) { return $crypt_pass; } else { throw new Exception('encryption failed'); return false; } } else { throw new Exception('encryption failed, missing password'); return false; } }

,然后当您想要验证此密码时,您只需查询登录电子邮件或用户 ID 的数据库,然后验证其简单如下

You can use password hashing but there is also php's crypt() function http://php.net/manual/en/function.crypt.php

They essentially do the same thing but crypt is a little neater IMO. Make sure you also get a good salt generation script so when you save the password in the database here is my password encryption function, notice this isn't that secure without the salt function

function crypt_password($password)
{
    if($password){
        //blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 base 64
        $blowfish = '$2a$10

and then when you want to verify this password you simply query the database for the login email or user id then to verify its as simple as

if (crypt($input_pass, $stored_pass) == $stored_pass) {
    return true;
}
; //get the random bytes and makes a salt $salt = $this->get_salt(); //append salt2 data to the password, and crypt using salt, results in a 60 char output $crypt_pass = crypt($password,$blowfish . $salt); //blowfish comes out as 60, check $len = strlen($crypt_pass); if($len == 60) { return $crypt_pass; } else { throw new Exception('encryption failed'); return false; } } else { throw new Exception('encryption failed, missing password'); return false; } }

and then when you want to verify this password you simply query the database for the login email or user id then to verify its as simple as

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