安全登录...... [英] Secure logins...
问题描述
您好。我认为这可能被认为是偏离主题的，但我想选择尽可能多的专家大脑。提前道歉....
我有一个表格，我有一个用户名和密码框。然后在表格''onsubmit事件调用的
验证函数中，我正在使用
用户名和密码，并从中生成MD5哈希（使用javascript）
他们，禁用密码框并将MD5哈希值写入表单上的隐藏字段
，然后允许提交表单。这样，就没有明文密码通过网络发送，只有用户名和MD5
哈希的用户名/密码。
然而......我开始认为它并不重要...... MD5哈希
无论如何都是以明文形式发送的。任何窥探者都可以抓住明确的
文本用户名和MD5，他们就像在那里一样好。然后我开始思考
关于优惠券系统，我将让服务器生成一个随机的MD5
哈希值，它将放置在表单中的隐藏字段中。然后，在尝试登录
时，服务器只接受来自优惠券的登录尝试
它已发出的数字......我以为这会绕过任何一个
可能的CSS黑客攻击。但它不会真的...或者它会吗？我是否正确
认为如果有人已经拦截了之前发送的明文用户名/ MD5哈希，他们只需要访问登录
页面将发行新优惠券，然后他们可以在
中使用用户名/ MD5和CSS来获取访问权限？
我听说只检查http_referer是没有意义的，因为它很容易被伪造。
那么什么是安全的交易方法使用非跨站点脚本登录？
&Plankmeister < PL ****************** @ hotmail.com>写在
新闻：3f *********************** @ dread12.news.tele.dk：
那么什么是处理非跨站点可编写脚本的登录的安全方法？
https？
并配置您的服务器（或脚本）以强制重定向到https
登录页面在http
" Sean Jorden" < S _ *********** @ no.spam.n_o_r_a.d.a.com>在消息中写道
news：Xn ********************* @ 198.161.157.145 ...The Plankmeister < PL ****************** @ hotmail.com>在
新闻中写道：3f *********************** @ dread12.news.tele.dk：
< blockquote class =post_quotes>
那么什么是处理非跨站点脚本化登录的安全方法？
https？
并配置您的服务器（或脚本）以强制重定向到https
登录页面，如果他们曾在http
IIRC，涉及在该服务器上拥有证书，对吗？
-
Karl Core
Charles Sweeney说我的信号很好。
>但是......我开始认为它并不重要......无论如何，MD5
哈希以明文形式发送。任何窥探者都可以抓住明确的文本用户名和MD5，他们就像在那里一样好。然后我开始思考
关于'优惠券''系统，我会让服务器生成一个随机
MD5哈希它将放置在表单中的隐藏字段中。然后，在尝试登录时，服务器只接受来自它发出的
优惠券号码的登录尝试...我认为这可以绕过任何可能的CSS黑客攻击。但它不会真的...或者它会吗？我是否正确认为如果有人已经截获了之前发送的明文用户名/ MD5哈希，他们只需要访问登录页面即可获得新的优惠券，然后他们可以与用户名/ MD5和CSS一起使用来获取访问权限？
你需要做什么，产生一个随机的''挑战' '每次登录框
都要显示。然后将此挑战存储在会话和/或
数据库中。当用户输入用户名和密码时，你会创建一个包含用户名，密码和质询的
md5-hash - 每次都会给出一个
的新md5字符串..
你可能想看看这个：
http： //phplib.sourceforge.net/
它有一些基于挑战的身份验证功能（自己没有尝试过
但是） 。
马丁
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.com> 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.com> wrote in message
news:Xn*********************@198.161.157.145..."The Plankmeister" <pl******************@hotmail.com> 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
hashis 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:
http://phplib.sourceforge.net/
It has some challenge-based authentication features (haven''t tried it myself
though).
Martin
这篇关于安全登录......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
