没有SSL的登录表单的Lite加密建议 [英] Proposal for Lite Encryption for Login Form without SSL
问题描述
此处有另外的评论请求。
我想完成类似本页概述的方案
这里：
http://tinyurl.com/3dtcdr
简而言之，表单使用javascript来哈希（md5）密码
字段使用随机一次性盐（nonce） - 由php生成和
粘贴在表单中 - 然后使用哈希密码
发回服务器。这样，密码就不会以明文的形式发送到服务器
。
但是，在上面引用的例子中，密码是无人值守的存储
回到服务器上（即在数据库中）这就是这个问题
今天晚上我一直在打结。
在我看来，最明显的方法是通过结局来复制用于散列pw的服务器端盐（sss）
数据库 - 盐是常量 - 在
的javascript部分内，以便该客户端：
1. ssspw = md5（ sss + pw）
2. nssspw = md5（nonce + ssspw）
3. post（1）nssspw，（2）nonce，（3）username（in plaintext ）
然后在服务器端，php将：
1. db_ssspw =从db获取哈希密码（应该== ssspw）
使用用户名
2. db_nssspw = md5（POST [nonce] + db_ssspw）
3.比较POST [nssspw] a nd db_nssspw
虽然这不会在数据库中公开明文密码或散列的
密码，但它确实公开了服务器端的密码
用于通过在
javascript中以明文方式粘贴来生成哈希密码 - 尽管它不会将其从表单发布回
服务器。
所以问题：
1）在这个计划中暴露服务器端盐是一个终端缺陷吗？
这相当于公钥加密中的公钥
系统，没有？
2）暴露服务器端的盐渲染散列
中的密码数据库没什么用？
3）如果这有缺陷，它还是比没有好，接受为
鉴于SSL已被排除？ （上面的文章指出，
雅虎使用这样的系统。）
4）有什么更好的想法来实现这里概述的概念？
在我将它运行到密码学新闻组之前，我想我会在这里播放
。
谢谢，
Tom
Another request for comments here.
I''d like to accomplish something like the scheme outlined at this page
here:
http://tinyurl.com/3dtcdr
In a nutshell, the form uses javascript to hash (md5) the password
field using a random one-time salt (nonce) -- generated by php and
pasted in the form -- that is then posted with the hashed password
back to the server. This way the password is not sent to the server
in plaintext.
In the example cited above, however, the password is stored unhashed
back at the server (i.e., in the database) and it''s this problem
that''s been tying me in knots this evening.
The most obvious way it seems to me to cut through the knot is to
simply copy the server-side salt (sss) used to hash the pw in the
database -- the salt is constant -- within the javascript portion of
the form so that that client would:
1. ssspw = md5(sss + pw)
2. nssspw = md5(nonce + ssspw)
3. post (1) nssspw, (2) nonce, (3) username (in plaintext)
Then on the server side, php would:
1. db_ssspw = fetch hashed password from db (which should == ssspw)
using username
2. db_nssspw = md5(POST[nonce] + db_ssspw)
3. compare POST[nssspw] and db_nssspw
While this does not expose the plaintext password or the hashed
password in the database, it does make public the server-side salt
used to generate the hash password by pasting it in plaintext in the
javascript -- though it does not post it from the form back to the
server.
So questions:
1) Is exposing the server-side salt a terminal flaw in this plan?
This would be the equivalent to a public key in public key encryption
systems, no?
2) Does exposing the server-side salt render hashing the password in
the database moot?
3) If this is flawed, is it still better than nothing, accepting as
given that SSL has been ruled out? (The article above notes that
Yahoo uses a system like this.)
4) Any better ideas for accomplishing the concept outlined here?
Before I run this over to the cryptology newsgroup, I thought I''d give
it an airing here.
Thanks,
Tom
推荐答案
klenwell写道：
klenwell wrote:
这里有另外的评论请求。
我想完成类似本页概述的方案
这里：
http://tinyurl.com/3dtcdr
简而言之，表单使用javascript来哈希（md5）密码
字段使用随机一次性盐（nonce） - 由php和
粘贴在表单中 - 然后使用哈希密码
发回服务器。这样，密码就不会以明文的形式发送到服务器
。
但是，在上面引用的例子中，密码是无人值守的存储
回到服务器上（即在数据库中）这就是这个问题
今天晚上我一直在打结。
在我看来，最明显的方法是通过结局来复制用于散列pw的服务器端盐（sss）
数据库 - 盐是常量 - 在
的javascript部分内，以便该客户端：
1. ssspw = md5（ sss + pw）
2. nssspw = md5（nonce + ssspw）
3. post（1）nssspw，（2）nonce，（3）username（in plaintext ）
然后在服务器端，php将：
1. db_ssspw =从db获取哈希密码（应该== ssspw）
使用用户名
2. db_nssspw = md5（POST [nonce] + db_ssspw）
3.比较POST [nssspw]和db _nssspw
虽然这不会在数据库中公开明文密码或散列的
密码，但它确实公开了服务器端的盐
用于通过在
javascript中以纯文本粘贴来生成哈希密码 - 尽管它不会将其从表单发布回
服务器。
所以问题：
1）在这个计划中暴露服务器端盐是一个终端缺陷吗？
这相当于公钥加密中的公钥
系统，没有？
2）暴露服务器端的盐渲染哈希密码在
数据库没什么用？
3）如果这有缺陷，它还是比没有好，接受为
鉴于SSL已被排除？ （上面的文章指出，
雅虎使用这样的系统。）
4）有什么更好的想法来实现这里概述的概念？
在我将它运行到密码学新闻组之前，我想我会在这里播放
。
谢谢，
Tom
Another request for comments here.
I''d like to accomplish something like the scheme outlined at this page
here:
http://tinyurl.com/3dtcdr
In a nutshell, the form uses javascript to hash (md5) the password
field using a random one-time salt (nonce) -- generated by php and
pasted in the form -- that is then posted with the hashed password
back to the server. This way the password is not sent to the server
in plaintext.
In the example cited above, however, the password is stored unhashed
back at the server (i.e., in the database) and it''s this problem
that''s been tying me in knots this evening.
The most obvious way it seems to me to cut through the knot is to
simply copy the server-side salt (sss) used to hash the pw in the
database -- the salt is constant -- within the javascript portion of
the form so that that client would:
1. ssspw = md5(sss + pw)
2. nssspw = md5(nonce + ssspw)
3. post (1) nssspw, (2) nonce, (3) username (in plaintext)
Then on the server side, php would:
1. db_ssspw = fetch hashed password from db (which should == ssspw)
using username
2. db_nssspw = md5(POST[nonce] + db_ssspw)
3. compare POST[nssspw] and db_nssspw
While this does not expose the plaintext password or the hashed
password in the database, it does make public the server-side salt
used to generate the hash password by pasting it in plaintext in the
javascript -- though it does not post it from the form back to the
server.
So questions:
1) Is exposing the server-side salt a terminal flaw in this plan?
This would be the equivalent to a public key in public key encryption
systems, no?
2) Does exposing the server-side salt render hashing the password in
the database moot?
3) If this is flawed, is it still better than nothing, accepting as
given that SSL has been ruled out? (The article above notes that
Yahoo uses a system like this.)
4) Any better ideas for accomplishing the concept outlined here?
Before I run this over to the cryptology newsgroup, I thought I''d give
it an airing here.
Thanks,
Tom
为什么你需要使用相同的盐（甚至相同的加密
方法）数据库？
另外，通过未加密的链接发送密码（即使
密码本身没有加密）也不会真的给你任何东西。如果我想要破解你的系统，那么我需要做的就是看看
的链接加密密码，并创建我自己的表格（sans
javascript）加密我的密码并发送它。
-
============ ======
删除x来自我的电子邮件地址
Jerry Stuckle
JDS计算机培训公司
js ******* @ attglobal.net
==================
Why do you need to use the same salt (or even the same encryption
method) for the database?
Also, sending the password over an unencrypted link (even if the
password itself isn''t encrypted) doesn''t really give you anything. If I
want to hack into your system, all I need to do is watch the link for
the encrypted password coming over it, and create my own form (sans
javascript) to encrypt the password on my end and send it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
9月30日9:08 pm，Jerry Stuckle< jstuck ... @ attglobal.netwrote：
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
klenwell写道：
klenwell wrote:
此处有另外的评论请求。
Another request for comments here.
我想完成类似本页概述的方案
这里：
I''d like to accomplish something like the scheme outlined at this page
here:
http://tinyurl.com/3dtcdr
简而言之，表单使用javascript来哈希（md5）密码
字段使用随机一次性盐（nonce） - 由php生成，
粘贴在表单中 - 然后用散列密码
发回服务器。这样，密码就不会以明文形式发送到服务器
。
In a nutshell, the form uses javascript to hash (md5) the password
field using a random one-time salt (nonce) -- generated by php and
pasted in the form -- that is then posted with the hashed password
back to the server. This way the password is not sent to the server
in plaintext.
但是，在上面引用的例子中，密码在服务器上没有存在（或者在
中）数据库）这就是这个问题
今天晚上我一直在打结。
In the example cited above, however, the password is stored unhashed
back at the server (i.e., in the database) and it''s this problem
that''s been tying me in knots this evening.
在我看来，最明显的方法就是将b / b
复制服务器端盐（sss）用于在
数据库中对pw进行哈希 - 盐是常量 - 在表单的javascript部分内，以便该客户端：
The most obvious way it seems to me to cut through the knot is to
simply copy the server-side salt (sss) used to hash the pw in the
database -- the salt is constant -- within the javascript portion of
the form so that that client would:
1. ssspw = md5（sss + pw）
2. nssspw = md5（nonce + ssspw）
3. post（1）nssspw，（2）nonce，（3）用户名（明文）
1. ssspw = md5(sss + pw)
2. nssspw = md5(nonce + ssspw)
3. post (1) nssspw, (2) nonce, (3) username (in plaintext)
然后在服务器端，php会：
Then on the server side, php would:
1. db_ssspw =从db获取哈希密码（应该== ssspw）
使用用户名
2. db_nssspw = md5（POST [nonce] + db_ssspw）
3.比较POST [nssspw]和db_nssspw
1. db_ssspw = fetch hashed password from db (which should == ssspw)
using username
2. db_nssspw = md5(POST[nonce] + db_ssspw)
3. compare POST[nssspw] and db_nssspw
虽然这不会暴露plaint在数据库中使用ext密码或散列
密码，它确实公开服务器端的盐
用于通过在明文中以明文方式粘贴哈希密码来生成哈希密码/>
javascript - 虽然它没有从表单发布回
服务器。
While this does not expose the plaintext password or the hashed
password in the database, it does make public the server-side salt
used to generate the hash password by pasting it in plaintext in the
javascript -- though it does not post it from the form back to the
server.
所以问题：
So questions:
1）暴露服务器 - 副盐是这个计划中的一个终端缺陷吗？
这相当于公钥加密的公钥
系统，不是吗？
1) Is exposing the server-side salt a terminal flaw in this plan?
This would be the equivalent to a public key in public key encryption
systems, no?
2）暴露服务器端的盐渲染是否在数据库中记录了密码？b $ b数据库没什么用？
2) Does exposing the server-side salt render hashing the password in
the database moot?
3）如果这是有缺陷的，它是否仍然比没有好，因为SSL已被裁定，接受为
出来吗？ （上面的文章指出，
雅虎使用这样的系统。）
3) If this is flawed, is it still better than nothing, accepting as
given that SSL has been ruled out? (The article above notes that
Yahoo uses a system like this.)
4）任何更好的想法来完成概述在这里概述？
4) Any better ideas for accomplishing the concept outlined here?
在我将它运行到密码学新闻组之前，我想我会在这里播放
。
Before I run this over to the cryptology newsgroup, I thought I''d give
it an airing here.
谢谢，
Tom
Thanks,
Tom
为什么你需要为数据库使用相同的盐（甚至是相同的加密方式
方法）？
此外，通过未加密的链接发送密码（即使
密码本身没有加密）并没有真正给你任何东西。如果我想要破解你的系统，那么我需要做的就是看看
的链接加密密码，并创建我自己的表格（sans
javascript）加密我的密码并发送它。
-
======== ==========
删除x来自我的电子邮件地址
Jerry Stuckle
JDS计算机培训公司
jstuck ... @ attglobal.net
==================
Why do you need to use the same salt (or even the same encryption
method) for the database?
Also, sending the password over an unencrypted link (even if the
password itself isn''t encrypted) doesn''t really give you anything. If I
want to hack into your system, all I need to do is watch the link for
the encrypted password coming over it, and create my own form (sans
javascript) to encrypt the password on my end and send it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
优点：
Good points:
为什么你需要为数据库使用相同的盐（甚至相同的加密
方法）？
Why do you need to use the same salt (or even the same encryption
method) for the database?
这是一个单向散列，因此输入字符串必须匹配。而且我没有b $ b认为没有与客户端共享数据库盐就可以了。
双向加密/解密可以解决这个问题，但我不知道不知道一个
库或函数，它们可以随时用于js和php。
It''s a one-way hash, so the input strings have to match. And I don''t
think that''s possible without sharing the db salt with the client.
Two-way encrypt/decrypt might solve this, but I don''t know offhand a
library or function that''s readily available for both js and php.
另外，发送密码通过未加密的链接（即使
密码本身没有加密）也没有给你任何东西。如果我想要破解你的系统，那么我需要做的就是看看
的链接加密密码，并创建我自己的表格（sans
javascript）加密我的密码并发送它。
Also, sending the password over an unencrypted link (even if the
password itself isn''t encrypted) doesn''t really give you anything. If I
want to hack into your system, all I need to do is watch the link for
the encrypted password coming over it, and create my own form (sans
javascript) to encrypt the password on my end and send it.
是的，是的，我误用了这个。我不认为你甚至不得不使用
哈希密码。只需发送这三个值：（1）nssspw，（2）
nonce，（3）用户名，他们每次都会工作。
再看一下引用的网站，首先应该发生的是：
1.服务器（PHP）生成挑战值（nonce）并将其作为隐藏值包含在
表格中并*将其保存为会话值*因此未通过
返回打开表单（即SESSION [nonce]）。
2.用户提交表单：（1 ）用户名（明文）（2）密码
（明文）（3）nonce [这仍然是私有的，它还没有发布
]
3.服务器端的盐（sss）发布在表单的js部分中，以便与数据库中的
哈希密码匹配。
然后在发回服务器之前，javascript在客户端踢：
1. ssspw = md5（sss + pw）
2. nssspw = md5 （nonce + ssspw）
3. POST（1）nssspw，（2）用户名（以纯文本格式）
然后在服务器端，php wo uld：
1. db_ssspw =从db获取哈希密码（应该== ssspw）
使用用户名
2。 db_nssspw = md5（SESSION [nonce] + db_ssspw）
3.比较POST [nssspw]和db_nssspw
4.取消设置SESSION [nonce]
那么，如果窃听者发回（1）nssspw，（2）用户名，
请求失败，因为不再有SESSION [nonce]值。
感谢您注意我的错误，Jerry。这仍然留下
打开问题：
1）暴露服务器端盐是一个严重的问题吗？
2）暴露服务器端的盐渲染哈希密码在数据库中是不是很有用？
3）任何更好的想法来实现概述的概念这里？
这篇文章也明确指出javascript并不总是启用了b $ b。我想这可以通过包含一个注释来解决，
建议打开javascript。我认为这是公平的假设
任何精明到足以将其关闭的人都可以将其打开足够长时间来记录
in。如果没有，信息可能只是以明文提交（假设如果有人确实碰到了b / b
，那么国家的安全性没有风险。）
Tom
Yes, true, I''ve misapplied this. I don''t think you would even have to
hash the password. Just send those three values: (1) nssspw, (2)
nonce, (3) username and they would work every time.
Looking again at the website cited, what should happen first is:
1. Server (PHP) generates challenge value (nonce) and includes it in
form as hidden value and *saves it as a session value* so not passed
back in open via form (i.e. SESSION[nonce]).
2. User submits form with : (1) username (in plaintext) (2) password
(in plaintext) (3) nonce [this is all still private and it has not
been posted yet]
3. The server-side salt (sss) is posted in the js section of form to
hash password to match db.
Then before posting back to server, javascript kicks in client-side:
1. ssspw = md5(sss + pw)
2. nssspw = md5(nonce + ssspw)
3. POST (1) nssspw, (2) username (in plaintext)
Then on the server side, php would:
1. db_ssspw = fetch hashed password from db (which should == ssspw)
using username
2. db_nssspw = md5(SESSION[nonce] + db_ssspw)
3. compare POST[nssspw] and db_nssspw
4. unset SESSION[nonce]
So then, if an eavesdropper sends back (1) nssspw, (2) username,
request fails because there''s no SESSION[nonce] value anymore.
Thanks for drawing attention to my error, Jerry. This still leaves
open the questions:
1) Is exposing the server-side salt a serious issue?
2) Does exposing the server-side salt render hashing the password in
the database moot?
3) Any better ideas for accomplishing the concept outlined here?
The article also makes the obvious point that javascript is not always
enabled. I figure this could be addressed by including a note that
recommends turning on javascript. I think it''s fair to assume that
anyone savvy enough to turn it off can turn it on long enough to log
in. If not, info could just be submitted in plaintext (assuming the
safety of the nation is not at risk if someone does happen to be
eavesdropping.)
Tom
另外，通过未加密的链接发送密码（即使
Also, sending the password over an unencrypted link (even if the
密码本身没有加密）并没有真正给你任何东西。如果我想要破解你的系统，那么我需要做的就是看看
的链接加密密码，并创建我自己的表格（sans
javascript）加密我的密码并发送它。
password itself isn''t encrypted) doesn''t really give you anything. If I
want to hack into your system, all I need to do is watch the link for
the encrypted password coming over it, and create my own form (sans
javascript) to encrypt the password on my end and send it.
我相信SSL完全是愚蠢的。看看数字
（如果有的话）。如果您丢失了密码并且您的个人数据是
，那么您将获得键盘记录/特洛伊木马，这意味着没有SSL可以确保您获得
。我从个人经验中知道。
为什么不执行以下操作：
1.密码以MD5（密码）发送。 />
3. PHP检查密码是否显示为有效的md5字符串
（告诉它md5已经发生）或不是。如果没有，它MD5的
密码，从而避免任何绕过。
4. PHP MD5s MD5和RANDOM盐。
注册时：
PHP存储MD5密码加盐。
登录时：
PHP收到来自用户的MD5密码（如果js已打开，否则PHP自带
md5s）然后再次使用MD5s，应用盐。然后它
验证这两个哈希值是否完全相同并且poof;）。
在这些情况下使用盐来获取Javascript将是无用的，因为：
a）用户会知道它是哪种盐，因此如果他想破解md5的b $ b，他将处于相同状态，就像没有使用盐一样。 />
b）如果它是一个随机盐，登录时，Javascript就不会知道
之前使用过的盐，所以他不能重复这个动作;）。
I believe that SSL is just completely silly. Take a look at numbers
(if any). Where you lose your password and your personal data is when
you get keylogged / trojaned, which means no SSL is going to secure
you. I know that from personal experience.
Why not do the following:
1. Password is sent in MD5 (password).
3. PHP checks if the password appears to be a valid md5 string
(telling it that md5 has already happened) or not. If not, it MD5s the
password, thus avoiding any bypassing.
4. PHP MD5s the MD5 along with a RANDOM salt.
When Registering:
PHP stores the MD5 Password plus the salt.
When Logging In:
PHP receives the MD5 password from the user (if js was on, else PHP
md5s on his own) and then MD5s again, applying the salt. Then it
verifies if the two hashes are exactly the same and poof ;).
Using a salt in these cases for Javascript would be useless because:
a) The user would know which salt it was, thus if he wanted to crack
the md5, he would be in the same status as if no salt was applied.
b) If it was a random salt, when logging in, Javascript wouldn''t know
which salt was used before so he couldn''t repeat the action ;).
这篇关于没有SSL的登录表单的Lite加密建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
