安全登录......

本文介绍了安全登录......的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

您好。我认为这可能被认为是偏离主题的，但我想选择尽可能多的专家大脑。提前道歉.... 我有一个表格，我有一个用户名和密码框。然后在表格''onsubmit事件调用的 验证函数中，我正在使用 用户名和密码，并从中生成MD5哈希（使用javascript） 他们，禁用密码框并将MD5哈希值写入表单上的隐藏字段 ，然后允许提交表单。这样，就没有明文密码通过网络发送，只有用户名和MD5 哈希的用户名/密码。 然而......我开始认为它并不重要...... MD5哈希 无论如何都是以明文形式发送的。任何窥探者都可以抓住明确的 文本用户名和MD5，他们就像在那里一样好。然后我开始思考 关于优惠券系统，我将让服务器生成一个随机的MD5 哈希值，它将放置在表单中的隐藏字段中。然后，在尝试登录 时，服务器只接受来自优惠券的登录尝试 它已发出的数字......我以为这会绕过任何一个 可能的CSS黑客攻击。但它不会真的...或者它会吗？我是否正确 认为如果有人已经拦截了之前发送的明文解决方案

&Plankmeister < PL ****************** @ hotmail>写在 新闻：3f *********************** @ dread12.news.tele.dk：

那么什么是处理非跨站点可编写脚本的登录的安全方法？

https？ 并配置您的服务器（或脚本）以强制重定向到https 登录页面在http

" Sean Jorden" < S _ *********** @ no.spam.n_o_r_a.d.a>在消息中写道 news：Xn ********************* @ 198.161.157.145 ...

The Plankmeister < PL ****************** @ hotmail>在新闻中写道：3f *********************** @ dread12.news.tele.dk： 那么什么是处理非跨站点脚本化登录的安全方法？

https？ 并配置您的服务器（或脚本）以强制重定向到https 登录页面，如果他们曾在http

IIRC，涉及在该服务器上拥有证书，对吗？ - Karl Core Charles Sweeney说我的信号很好。

>但是......我开始认为它并不重要......无论如何，MD5 哈希

以明文形式发送。任何窥探者都可以抓住明确的文本用户名和MD5，他们就像在那里一样好。然后我开始思考关于'优惠券''系统，我会让服务器生成一个随机 MD5哈希它将放置在表单中的隐藏字段中。然后，在尝试登录时，服务器只接受来自它发出的优惠券号码的登录尝试...我认为这可以绕过任何可能的CSS黑客攻击。但它不会真的...或者它会吗？我是否正确认为如果有人已经截获了之前发送的明文用户名/ MD5哈希，他们只需要访问登录页面即可获得新的优惠券，然后他们可以与用户名/ MD5和CSS一起使用来获取访问权限？

你需要做什么，产生一个随机的''挑战' '每次登录框 都要显示。然后将此挑战存储在会话和/或数据库中。当用户输入用户名和密码时，你会创建一个包含用户名，密码和质询的 md5-hash - 每次都会给出一个 的新md5字符串.. 你可能想看看这个： http： //phplib.sourceforge/ 它有一些基于挑战的身份验证功能（自己没有尝试过 但是） 。 马丁

Hi. I reaslise this is possibly considered off-topic, but I want to pick as many expert brains as possible. Apologies in advance.... I have a form on which I have a username and password box. Then in the validation function called by the form''s onsubmit event, I''m taking the username and password and generating an MD5 hash (using javascript) from them, disabling the password box and writing the MD5 hash to a hidden field on the form and then allowing the form to be submitted. This way, there is no clear-text password sent across the net, only the username and the MD5 hash of the username/password. However... I started thinking that it doesn''t really matter... The MD5 hash is sent as clear text anyway. Anyone snooping could just catch the clear text username and MD5 and they''re as good as in. Then I started thinking about a ''coupon'' system, where I would have the server generate a random MD5 hash which it would place in a hidden field in the form. Then, upon attempting to login, the server would only accept login attempts from coupon numbers that it''s issued... I was thinking this would get around any possible CSS hacks. But it wouldn''t really... Or would it? Am I right in thinking that if someone were to have already intercepted the clear text username/MD5 hash sent previously, they would only have to visit the login page to be issued with a new coupon, which they could then use in conjunction with the username/MD5 and CSS to get access? And I''ve heard that just checking http_referer is pointless because it''s easily forgeable. So what is a secure method of dealing with non-cross-site scriptable logins?

解决方案

"The Plankmeister" <pl******************@hotmail> wrote in news:3f***********************@dread12.news.tele.d k:

So what is a secure method of dealing with non-cross-site scriptable logins?

https? and configure your server (or script) to force a redirect to the https login page if they ever hit it in http

"Sean Jorden" <s_***********@no.spam.n_o_r_a.d.a> wrote in message news:Xn*********************@198.161.157.145...

"The Plankmeister" <pl******************@hotmail> wrote in news:3f***********************@dread12.news.tele.d k:

So what is a secure method of dealing with non-cross-site scriptable logins?

https? and configure your server (or script) to force a redirect to the https login page if they ever hit it in http

IIRC, that involves having a certificate on that server, right? -- Karl Core Charles Sweeney says my sig is fine as it is.

> However... I started thinking that it doesn''t really matter... The MD5 hash

is sent as clear text anyway. Anyone snooping could just catch the clear text username and MD5 and they''re as good as in. Then I started thinking about a ''coupon'' system, where I would have the server generate a random MD5 hash which it would place in a hidden field in the form. Then, upon attempting to login, the server would only accept login attempts from coupon numbers that it''s issued... I was thinking this would get around any possible CSS hacks. But it wouldn''t really... Or would it? Am I right in thinking that if someone were to have already intercepted the clear text username/MD5 hash sent previously, they would only have to visit the login page to be issued with a new coupon, which they could then use in conjunction with the username/MD5 and CSS to get access?

What you need to do, is generate a random ''challenge'' every time a login-box is to be shown. This challenge is then stored in the session and/or database. When the user has entered username and password you create a md5-hash incorporating username, password and challenge - this will give a new md5 string every time.. You might wanna check this out: phplib.sourceforge/ It has some challenge-based authentication features (haven''t tried it myself though). Martin