☆─────────────────────────────────────☆
SlANmASTer (渴望美女青睐 之 我爱工科女) 于 (Mon Apr 29 11:32:47 2013) 提到:
有啥纯javascript，速度快点的呢？thx
哪位大佬有手头在用的，给传个吧 ：）
如果cookie里面存加密id，将来取出来，是不是再和数据库里面的id比较啊？
那样的话，用户数据库里面是不是得增设一个字段，存着明文id对应的加密id，要不然将来拿着加密id读数据库的话，每次都临时转换，会很慢啊
☆─────────────────────────────────────☆
ottffsse (nothing) 于 (Mon Apr 29 12:28:16 2013) 提到:
一个奇怪的需求。你为什么要在cookie里存ID?
【 在 SlANmASTer (渴望美女青睐 之 我爱工科女) 的大作中提到: 】
: 有啥纯javascript，速度快点的呢？thx
: 哪位大佬有手头在用的，给传个吧 ：）
: 如果cookie里面存加密id，将来取出来，是不是再和数据库里面的id比较啊？
: ...................
☆─────────────────────────────────────☆
SlANmASTer (渴望美女青睐 之 我爱工科女) 于 (Mon Apr 29 13:35:31 2013) 提到:
汗，好多帖子里不是说，自动登录需要存id的吗？
【 在 ottffsse (nothing) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Mon Apr 29 12:28:16 2013), 站内
:
: 一个奇怪的需求。你为什么要在cookie里存ID?
:
: 【 在 SlANmASTer (渴望美女青睐 之 我爱工科女) 的大作中提到: 】
: : 有啥纯javascript，速度快点的呢？thx
: : 哪位大佬有手头在用的，给传个吧 ：）
: : 如果cookie里面存加密id，将来取出来，是不是再和数据库里面的id比较啊？
: : ...................
:
: --
:
: ※ 来源:·水木社区
http://newsmth.net·[FROM: 59.175.226.*]
☆─────────────────────────────────────☆
ottffsse (nothing) 于 (Mon Apr 29 13:44:01 2013) 提到:
不如存密码
【 在 SlANmASTer (渴望美女青睐 之 我爱工科女) 的大作中提到: 】
: 汗，好多帖子里不是说，自动登录需要存id的吗？
☆─────────────────────────────────────☆
Orpherus (奥路菲) 于 (Mon Apr 29 14:00:40 2013) 提到:
这是馊主意
【 在 SlANmASTer (渴望美女青睐 之 我爱工科女) 的大作中提到: 】
: 有啥纯javascript，速度快点的呢？thx
: 哪位大佬有手头在用的，给传个吧 ：）
: 如果cookie里面存加密id，将来取出来，是不是再和数据库里面的id比较啊？
: ...................
☆─────────────────────────────────────☆
SlANmASTer (渴望美女青睐 之 我爱工科女) 于 (Mon Apr 29 15:50:14 2013) 提到:
存明码的id？
我也看了下，ie缓存里各大站点留下的饼干，打开cookie里面的字符明显不是明码，没法直接读出含义
【 在 ottffsse (nothing) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Mon Apr 29 13:44:01 2013), 站内
:
: 不如存密码
:
: 【 在 SlANmASTer (渴望美女青睐 之 我爱工科女) 的大作中提到: 】
: : 汗，好多帖子里不是说，自动登录需要存id的吗？
:
: --
:
: ※ 来源:·水木社区
http://newsmth.net·[FROM: 59.175.226.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Mon Apr 29 20:55:04 2013) 提到:
你要做什么？如果你要取出来在网页显示也就罢了，你Cookie里面放的数据绝对不能和后端数据有你说的交互匹配操作，SessionID可以那样干，是因为那东西是高度随机的字符串，很难猜，你放ID之类的加密信息，肯定有人可以Crack出来。
自动登录这个东西，是在后端对session的UserID的这样的数据做Session数据(最简单比如SessionID:UserID键值对)持久化操作，前台把SessionId的或类似数据的有效时间延长。SessionID这一类东西是每次随机生成的，你的UserID是固定的，不论你怎么做单向加密，都有人可以给你慢慢Crack出来。
Session持久化操作，有些容器环境自己就支持。
【 在 SlANmASTer 的大作中提到: 】
: 有啥纯javascript，速度快点的呢？thx
: 哪位大佬有手头在用的，给传个吧 ：）
:
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Mon Apr 29 21:00:12 2013) 提到:
不要这样戏弄人家。
【 在 ottffsse 的大作中提到: 】
: 不如存密码
:
☆─────────────────────────────────────☆
SlANmASTer (渴望美女青睐 之 我爱工科女) 于 (Mon Apr 29 21:17:19 2013) 提到:
好吧，一来是显示，就像现在登录各大bbs，看得到自己的用户名，比如水木，再就是区分用户上传的文件，不至于分不清哪个文件是谁传的搞不清楚，
还有，sessionid临时分配的话，服务器怎么和userid对应起来？再开一张表吗？
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Mon Apr 29 20:55:04 2013), 站内
:
: 你要做什么？如果你要取出来在网页显示也就罢了，你Cookie里面放的数据绝对不能和后端数据有你说的交互匹配操作，SessionID可以那样干，是因为那东西是高度随机的字符串，很难猜，你放ID之类的加密信息，肯定有人可以Crack出来。
: 自动登录这个东西，是在后端对session的UserID的这样的数据做Session数据(最简单比如SessionID:UserID键值对)持久化操作，前台把SessionId的或类似数据的有效时间延长。SessionID这一类东西是每次随机生成的，你的UserID是固定的，不论你怎么做单向加密，都有人可以给你慢慢Crack出来。
: Session持久化操作，有些容器环境自己就支持。
: 【 在 SlANmASTer 的大作中提到: 】
: : 有啥纯javascript，速度快点的呢？thx
: : 哪位大佬有手头在用的，给传个吧 ：）
: :
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
: ※ 修改:·dhcn 于 Apr 29 21:12:00 2013 修改本文·[FROM: 110.232.55.*]
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
SlANmASTer (渴望美女青睐 之 我爱工科女) 于 (Mon Apr 29 21:17:27 2013) 提到:
。。。。。。
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Mon Apr 29 21:00:12 2013), 站内
:
: 不要这样戏弄人家。
: 【 在 ottffsse 的大作中提到: 】
: : 不如存密码
: :
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
: ※ 修改:·dhcn 于 Apr 29 21:11:10 2013 修改本文·[FROM: 110.232.55.*]
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Mon Apr 29 22:41:21 2013) 提到:
1、先说Session，Session是对话，Session怎么实现，在Cookie里面放一个SessionID(放URL那种现在基本没人敢用)，然后在服务器端以SessionID为键，然后所有你往Session里面放的数据就在后面的Value值里面，说白了就是Hash表。JSP容器、PHP都可以设置或扩充这个Hash表的存储方式。内存、NoSQL、文件、关系数据库随便。request的过程中会发送Cookie数据，所以每次请求处理都可以根据某个有效的SessionID来当对后面的Value值做存取处理的键。所以你把Cookie里面的SessionID，或者另外做一个原理类似专门用于自动登录的LoginID这样的数据的Cookie有效期延长，然后后端的那个Hash表持久化存起来，等于延长了会话有效期的时间，不知道我说明白了没？多说一句：安全的应用对SessionID这个Cookie是要做一些加固操作的。
2、用户上传文件的区分，首先这个完全在服务器端，和前端基本没关系，粗糙来一下：分目录或者做前缀，无非就是给把userID这样的专属数据作为Path里面的某段字符串来对读取做限定。真文件名或者后缀放什么，要根据你对安全的要求，自己处理一下。
【 在 SlANmASTer 的大作中提到: 】
: 好吧，一来是显示，就像现在登录各大bbs，看得到自己的用户名，比如水木，再就是区分用户上传的文件，不至于分不清哪个文件是谁传的搞不清楚，
: 还有，sessionid临时分配的话，服务器怎么和userid对应起来？再开一张表吗？
: ※ 修改:·dhcn 于 Apr 29 21:12:00 2013 修改本文·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
SlANmASTer (渴望美女青睐 之 我爱工科女) 于 (Mon Apr 29 23:09:41 2013) 提到:
长贴啊，谢啦
1。大概意思是服务器端建表，以sessionid为键，存放客户端饼干的内容，等于客户端饼干在服务器侧也存了一份，自动登录在于维持饼干保存期。
2.把文件往服务器保存时，用文件保存路径或文件名中的特殊字符串区别各个文件，特殊字符串考虑用userid承担
理解就到这程度了，嘿嘿
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Mon Apr 29 22:41:21 2013), 站内
:
: 1、先说Session，Session是对话，Session怎么实现，在Cookie里面放一个SessionID(放URL那种现在基本没人敢用)，然后在服务器端以SessionID为键，然后所有你往Session里面放的数据就在后面的Value值里面，说白了就是Hash表。JSP容器、PHP都可以设置或扩充这个Hash表的存储方式。内存、NoSQL、文件、关系数据库随便。request的过程中会发送Cookie数据，所以每次请求处理都可以根据某个有效的SessionID来当对后面的Value值做存取处理的键。所以你把Cookie里面的SessionID，或者另外做一个原理类似专门用于自动登录的LoginID这样的数据的Cookie有效期延长，然后后端的那个Hash表持久化存起来，等于延长了会话有效期的时间，不知道我说明白了没？多说一句：安全的应用对SessionID这个Cookie是要做一些加固操作的。
: 2、用户上传文件的区分，首先这个完全在服务器端，和前端基本没关系，粗糙来一下：分目录或者做前缀，无非就是给把userID这样的专属数据作为Path里面的某段字符串来对读取做限定。真文件名或者后缀放什么，要根据你对安全的要求，自己处理一下。
: 【 在 SlANmASTer 的大作中提到: 】
: : 好吧，一来是显示，就像现在登录各大bbs，看得到自己的用户名，比如水木，再就是区分用户上传的文件，不至于分不清哪个文件是谁传的搞不清楚，
: : 还有，sessionid临时分配的话，服务器怎么和userid对应起来？再开一张表吗？
: : ※ 修改:·dhcn 于 Apr 29 21:12:00 2013 修改本文·[FROM: 110.232.55.*]
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
: ※ 修改:·dhcn 于 Apr 29 22:45:37 2013 修改本文·[FROM: 110.232.55.*]
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Tue Apr 30 09:51:55 2013) 提到:
存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，在服务器端有一份。很多人说基于Cookie的Session，就以为所有的Session数据都在Cookie里，其实不是这样的，Cookie只放那个SessionID。
【 在 SlANmASTer 的大作中提到: 】
: 长贴啊，谢啦
: 1。大概意思是服务器端建表，以sessionid为键，存放客户端饼干的内容，等于客户端饼干在服务器侧也存了一份，自动登录在于维持饼干保存期。
: 2.把文件往服务器保存时，用文件保存路径或文件名中的特殊字符串区别各个文件，特殊字符串考虑用userid承担
: ...................
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 03:22:52 2013) 提到:
基于cookie的session指的确实是所有数据放cookie吧？然后服务器端放sessionid和所
有数据的md5。
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Tue Apr 30 09:51:55 2013), 站内
:
: 存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，在服务器端有一份。很多人说基于Cookie的Session，就以为所有的Session数据都在Cookie里，其实不是这样的，Cookie只放那个SessionID。
: 【 在 SlANmASTer 的大作中提到: 】
: : 长贴啊，谢啦
: : 1。大概意思是服务器端建表，以sessionid为键，存放客户端饼干的内容，等于客户端饼干在服务器侧也存了一份，自动登录在于维持饼干保存期。
: : 2.把文件往服务器保存时，用文件保存路径或文件名中的特殊字符串区别各个文件，特殊字符串考虑用userid承担
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
readme916 (wokaonet) 于 (Wed May 1 04:13:53 2013) 提到:
对于要存储的数据量大的，的确是个办法，节省服务器空间，不过多了md5开销，且网络开销增加了吧，貌似得不偿失啊
硬盘啊，内存啊，不值钱
【 在 Knightmare (梦醒时分) 的大作中提到: 】
基于cookie的session指的确实是所有数据放cookie吧？然后服务器端放sessionid和所
有数据的md5。
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Tue Apr 30 09:51:55 2013), 站内
:
: 存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，在服务器端有一份。很多人说基于Cookie的Session，就以为所有的Session数据都在Cookie里，其实不是这样的，Cookie只放那个SessionID。
: 【 在 SlANmASTer 的大作中提到: 】
: : 长贴啊，谢啦
: : 1。大概意思是服务器端建表，以sessionid为键，存放客户端饼干的内容，等于客户端饼干在服务器侧也存了一份，自动登录在于维持饼干保存期。
: : 2.把文件往服务器保存时，用文件保存路径或文件名中的特殊字符串区别各个文件，特殊字符串考虑用userid承担
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 07:45:45 2013) 提到:
嗯，有很多这么做的。因为并发量大了的话，server上存储只是一个sessionid的话，比
较容易设计，可以做成分布式的。
不过我主要的目的是纠正他的说法，基于cookie的session是我说的这样，基于db的ses
sion是把session数据放db里，基于文件的session是把session放服务器文件里......【 在 readme916 (wokaonet) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 04:13:53 2013), 站内
:
: 对于要存储的数据量大的，的确是个办法，节省服务器空间，不过多了md5开销，且网络开销增加了吧，貌似得不偿失啊
: 硬盘啊，内存啊，不值钱
:
:
: 【 在 Knightmare (梦醒时分) 的大作中提到: 】
: 基于cookie的session指的确实是所有数据放cookie吧？然后服务器端放sessionid和所
: 有数据的md5。
:
:
: 【 在 dhcn (小石) 的大作中提到: 】
: : 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: : 发信站: 水木社区 (Tue Apr 30 09:51:55 2013), 站内
: :
: : 存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，在服务器端有一份。很多人说基于Cookie的Session，就以为所有的Session数据都在Cookie里，其实不是这样的，Cookie只放那个SessionID。
: : 【 在 SlANmASTer 的大作中提到: 】
: : : 长贴啊，谢啦
: : : 1。大概意思是服务器端建表，以sessionid为键，存放客户端饼干的内容，等于客户端饼干在服务器侧也存了一份，自动登录在于维持饼干保存期。
: : : 2.把文件往服务器保存时，用文件保存路径或文件名中的特殊字符串区别各个文件，特殊字符串考虑用userid承担
: : : ...................
: :
: : --
: : 玉不琢，不成器。
: : 读千卷书，行千万里路：这个标准比较符合这个时代。
: :
:
:
: --
: 不明觉利
:
:
:
:
: --
: 关于SEO，关于网赚的入门知识的一个小站，
http://www.fengbei.net 如果仔细阅读你会发现收获很大
:
:
: ※ 来源:·水木社区 newsmth.net·[FROM: 115.193.183.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 09:29:45 2013) 提到:
这个是一个客观现实问题，我就不做争论了，我说，也肯定有人坚持己见，有兴趣的同学可以找书，我也可以说我的启蒙书籍《Servket与JSP核心编程》第二版，该书9.1.1小节这个问题说得和清楚。
多说一句：Cookie里面放什么不放什么是个严谨的安全问题。搞不清楚这个，你Web应用就是前门和后门都是一个公共敞开的门。
【 在 Knightmare 的大作中提到: 】
: 基于cookie的session指的确实是所有数据放cookie吧？然后服务器端放sessionid和所
: 有数据的md5。
:
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 09:34:10 2013) 提到:
回去好好找本书看看，知道什么叫基于Cookie的session和基于URL重写的Session(这两个才是对应的)，概念都没搞清楚，就在这儿偷换概念、混淆视听，有意思吗？
你说的那种基于DB的和基于文件，我明确的告诉你，在那个概念簇里面，没有谁敢把那些东西里面的数据完全往Cookie里面放，为什么？首要因素还是安全问题。
【 在 Knightmare 的大作中提到: 】
: 嗯，有很多这么做的。因为并发量大了的话，server上存储只是一个sessionid的话，比
: 较容易设计，可以做成分布式的。
: 不过我主要的目的是纠正他的说法，基于cookie的session是我说的这样，基于db的ses
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 09:36:53 2013) 提到:
Cookie能放多少数据，那是有上限的。
【 在 readme916 的大作中提到: 】
: 对于要存储的数据量大的，的确是个办法，节省服务器空间，不过多了md5开销，且网络开销增加了吧，貌似得不偿失啊
: 硬盘啊，内存啊，不值钱
:
: ...................
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 09:37:07 2013) 提到:
亲自写过session容器的人会不懂session？
把变量值放cookie的实现多了去了，你倒是说说cookie放变量，服务端放sessionid和md5的实现，除了把变量暴露给用户以外，有什么安全漏洞？【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 09:29:45 2013), 站内
:
: 这个是一个客观现实问题，我就不做争论了，我说，也肯定有人坚持己见，有兴趣的同学可以找书，我也可以说我的启蒙书籍《Servket与JSP核心编程》第二版，该书9.1.1小节这个问题说得和清楚。
: 多说一句：Cookie里面放什么不放什么是个严谨的安全问题。搞不清楚这个，你Web应用就是前门和后门都是一个公共敞开的门。
: 【 在 Knightmare 的大作中提到: 】
: : 基于cookie的session指的确实是所有数据放cookie吧？然后服务器端放sessionid和所
: : 有数据的md5。
: :
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 09:42:19 2013) 提到:
亲自写，一个亲自写了的人都不知道Session的基本实现原理，还在这儿出丑，还搬经历，你丢不丢人啊？书的章节都已经说了，你都不看一眼，你就不是做技术的严谨学习研究态度。
1、你放在Cookie里面的数据是完全客户可以改。
2、你说的在前面放一份明码，后端放一份MD5验证，一份数据放两份，你以为你分布式冗余哪？又耗计算又耗网络，纯粹吃饱了城的。
3、一个做Session实现的人，连通行的Session实现机制都不知道，还在哪儿自说自话，自以为是。就你这种态度，这什么实现，也只是个实现。
4、你懂的基于Cookie的Session，也就是你自己实现的那个所谓的Session而已。
【 在 Knightmare 的大作中提到: 】
: 亲自写过session容器的人会不懂session？
: 把变量值放cookie的实现多了去了，你倒是说说cookie放变量，服务端放sessionid和md5的实现，除了把变量暴露给用户以外，有什么安全漏洞？【 在 dhcn (小石) 的大作中提到: 】
:
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 09:43:28 2013) 提到:
行，我怕你了。
我最怕弄个java就把java当大天的了，java做到的就是最好的，java没做的就是不对的。
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 09:34:10 2013), 站内
:
: 回去好好找本书看看，知道什么叫基于Cookie的session和基于URL重写的Session(这两个才是对应的)，概念都没搞清楚，就在这儿偷换概念、混淆视听，有意思吗？
: 你说的那种基于DB的和基于文件，我明确的告诉你，在那个概念簇里面，没有谁敢把那些东西里面的数据完全往Cookie里面放，为什么？首要因素还是安全问题。
: 【 在 Knightmare 的大作中提到: 】
: : 嗯，有很多这么做的。因为并发量大了的话，server上存储只是一个sessionid的话，比
: : 较容易设计，可以做成分布式的。
: : 不过我主要的目的是纠正他的说法，基于cookie的session是我说的这样，基于db的ses
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
: ※ 修改:·dhcn 于 May 1 09:38:02 2013 修改本文·[FROM: 110.232.55.*]
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 09:45:10 2013) 提到:
我服务器上就放个sessionid+md5，你客户端cookie修改我服务器上md5对不上就认为无效。
没见过吧？我懒得回你的帖子了，这样吧
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 09:42:19 2013), 站内
:
: 亲自写，一个亲自写了的人都不知道Session的基本实现原理，还在这儿出丑，还搬经历，你丢不丢人啊？书的章节都已经说了，你都不看一眼，你就不是做技术的严谨学习研究态度。
: 1、你放在Cookie里面的数据是完全客户可以改。2、你说的在前面放一份明码，后端放一份MD5验证，一份数据放两份，你以为你分布式冗余哪？又耗计算又耗网络，纯粹吃饱了城的。
: 【 在 Knightmare 的大作中提到: 】
: : 亲自写过session容器的人会不懂session？
: : 把变量值放cookie的实现多了去了，你倒是说说cookie放变量，服务端放sessionid和md5的实现，除了把变量暴露给用户以外，有什么安全漏洞？【 在 dhcn (小石) 的大作中提到: 】
: :
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 09:46:02 2013) 提到:
这个东西跟Java没关系，java顶多也就算是个那个原理的实现。本来也就是个叫法，你这种态度，完全是以你的做法和称呼否定业内的通行的东西，本来知识一个概念混淆的小问题，但你这种抵触学习的态度，我明确地告诉你，这种态度不适合搞技术。
最后再列一本PHP的相关阐述：<PHP与MySQL5程序设计 第二版>18.1.1 小节。
我列的两本书都是网络可下载的。
【 在 Knightmare 的大作中提到: 】
: 行，我怕你了。
: 我最怕弄个java就把java当大天的了，java做到的就是最好的，java没做的就是不对的。
: ※ 修改:·dhcn 于 May 1 09:38:02 2013 修改本文·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 09:48:36 2013) 提到:
你把你的做法用业内通行的名称冠名，还拿出来混淆视听，还死不认账。
你这种作坊你以为别人改不了就行了吗？有些业务数据是不能让用户看到的。
【 在 Knightmare 的大作中提到: 】
: 我服务器上就放个sessionid+md5，你客户端cookie修改我服务器上md5对不上就认为无效。
: 没见过吧？我懒得回你的帖子了，这样吧
:
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 09:57:35 2013) 提到:
别以为java就是行业通用，至于安全性，你把不想让客户看到的放服务器上去不就行了么？
变量放cookie里然后用ajax/jquery调用的应用多了去了，新浪谷歌盛大都有这么用的，反正和你不一样的就山寨呗。【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 09:48:36 2013), 站内
:
: 你把你的做法用业内通行的名称冠名，还拿出来混淆视听，还死不认账。
: 你这种作坊你以为别人改不了就行了吗？有些业务数据是不能让用户看到的。
: 【 在 Knightmare 的大作中提到: 】
: : 我服务器上就放个sessionid+md5，你客户端cookie修改我服务器上md5对不上就认为无效。
: : 没见过吧？我懒得回你的帖子了，这样吧
: :
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:12:34 2013) 提到:
PHP的，我上面列了，再来ASP的：
http://hi.baidu.com/loro5/item/b9449dcd75dd270b0bd93a4a 三个P我算列全了，奉劝你一句：自信可以，做人不要那么太主观，稍微做点调查研究，不会把自己亏下。
对于大门户的做法，我简单解释一下：大门户往Cookie里面的确放很多用户业务数据，但这个和Session还是有一定区别，Session是会话数据，大门户的用户量太大，为了减轻服务器端存储的压力，会在客户端放一点和安全无关的业务数据缓存，但这些数据的性质，就像本地生活站点里面缓存的你的本地城市名称一样：它得和实际安全相关事务数据无关，有的甚至和会话无关。
你说的那个什么单独处理的方案，我简单说一句：Cookie有Cookie的存取接口，Session有Session，我在Session里面还分两种Cookie和服务器端两种方式，其中一种是无责任委托，还是那句话：吃饱了撑的。而且会让业务逻辑实现人员无所适从。
【 在 Knightmare 的大作中提到: 】
: 别以为java就是行业通用，至于安全性，你把不想让客户看到的放服务器上去不就行了么？
: 变量放cookie里然后用ajax/jquery调用的应用多了去了，新浪谷歌盛大都有这么用的，反正和你不一样的就山寨呗。【 在 dhcn (小石) 的大作中提到: 】
:
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 10:20:09 2013) 提到:
大哥你能列出来个稍微权威点的文章url么。
咱也别弄得太高端，给你个wikipedia的链接看看吧
http://en.wikipedia.org/wiki/Session_(computer_science)#Client_side_web_sess
ions
天底下没谁规定过session变量只能存server上，有得是存cookie里的。我的论点就这一
个，不想废话了。【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 10:12:34 2013), 站内
:
: PHP的，我上面列了，再来ASP的：
http://hi.baidu.com/loro5/item/b9449dcd75dd270b0bd93a4a: 三个P我算列全了，奉劝你一句：自信可以，做人不要那么太主观，稍微做点调查研究，不会把自己亏下。
: 对于大门户的做法，我简单解释一下：大门户往Cookie里面的确放很多用户业务数据，但这个和Session还是有一定区别，Session是会话数据，大门户的用户量太大，为了减轻服务器端存储的压力，会在客户端放一点和安全无关的业务数据缓存，但这些数据的性质，就像本地生活站点里面缓存的你的本地城市名称一样：它得和实际安全相关事务数据无关，有的甚至和会话无关。
: 【 在 Knightmare 的大作中提到: 】
: : 别以为java就是行业通用，至于安全性，你把不想让客户看到的放服务器上去不就行了么？
: : 变量放cookie里然后用ajax/jquery调用的应用多了去了，新浪谷歌盛大都有这么用的，反正和你不一样的就山寨呗。【 在 dhcn (小石) 的大作中提到: 】
: :
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
: ※ 修改:·dhcn 于 May 1 10:13:04 2013 修改本文·[FROM: 110.232.55.*]
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:20:19 2013) 提到:
我一直搞不明白，我觉得不知道什么东西不可耻，学不就得了呗。在当自己的一个概念和业界普遍概念冲突的时候，其实也是一件小事，说清楚，承认了不就完了，自己又不是毛泽东，也不用发罪己诏，承认一下错误，自己也死不了。何必那？
【 在 Knightmare 的大作中提到: 】
: 别以为java就是行业通用，至于安全性，你把不想让客户看到的放服务器上去不就行了么？
: 变量放cookie里然后用ajax/jquery调用的应用多了去了，新浪谷歌盛大都有这么用的，反正和你不一样的就山寨呗。【 在 dhcn (小石) 的大作中提到: 】
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:27:51 2013) 提到:
好吧，我把这个百科里面最后一句话贴出来：
虽然这样的机制可以保存数据的前后关联，但是必须要保障数据的完整性和安全性。
Cookie里面是可以放数据，但是这个和业内通行的基于Cookie的Session概念不一样，你可以把你的做法冠以你所谓的名字，但是请不要混淆概念视听，给业内的大众技术交流带来障碍。
【 在 Knightmare 的大作中提到: 】
: 大哥你能列出来个稍微权威点的文章url么。
: 咱也别弄得太高端，给你个wikipedia的链接看看吧
:
http://en.wikipedia.org/wiki/Session_(computer_science)#Client_side_web_sess
: ...................
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 10:34:06 2013) 提到:
这一系列帖子，我只不过是定义和java那一套不太一样。
你呢？刚开始说cookie里只能放id不能放数据的是谁？
要说混淆视听，谁更混淆视听？
我不是不能更新概念看书学习，我只是觉得一个犯了严重错误的人劝我去多看书非常搞笑而已。【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 10:27:51 2013), 站内
:
: 好吧，我把这个百科里面最后一句话贴出来：
: 虽然这样的机制可以保存数据的前后关联，但是必须要保障数据的完整性和安全性。
: Cookie里面是可以放数据，但是这个和业内通行的基于Cookie的Session概念不一样，你可以把你的做法冠以你所谓的名字，但是请不要混淆概念视听，给业内的大众技术交流带来障碍。
: 【 在 Knightmare 的大作中提到: 】
: : 大哥你能列出来个稍微权威点的文章url么。
: : 咱也别弄得太高端，给你个wikipedia的链接看看吧
: :
http://en.wikipedia.org/wiki/Session_(computer_science)#Client_side_web_sess
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:35:43 2013) 提到:
权威点的：
http://www.ibm.com/developerworks/cn/java/books/javaweb_xlb/10/
http://www.ibm.com/developerworks/cn/java/j-lo-servlet/
【 在 Knightmare 的大作中提到: 】
: 大哥你能列出来个稍微权威点的文章url么。
: 咱也别弄得太高端，给你个wikipedia的链接看看吧
:
http://en.wikipedia.org/wiki/Session_(computer_science)#Client_side_web_sess
: ...................
☆─────────────────────────────────────☆
aotian (aotian) 于 (Wed May 1 10:36:11 2013) 提到:
较多数据放在cookie里面牺牲用户的安全性保障系统的安全性
cookie里面只放一个sessionid刚好反过来
【 在 Knightmare (梦醒时分) 的大作中提到: 】
: 亲自写过session容器的人会不懂session？
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:40:48 2013) 提到:
我说的ID是指SessionID，其它的业务数据缓存，我之前在对大门户的解释中说的很清楚，我什么时候说Cookie里面只能放一个ID Cookie数据了？你把连接给我贴出来。
【 在 Knightmare 的大作中提到: 】
: 这一系列帖子，我只不过是定义和java那一套不太一样。
: 你呢？刚开始说cookie里只能放id不能放数据的是谁？
: 要说混淆视听，谁更混淆视听？
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:42:32 2013) 提到:
一个指出你概念有问题的人，你就说别人指出你错误是严重错误，说白了就是说别人不能指出你错误呗。
【 在 Knightmare 的大作中提到: 】
: 这一系列帖子，我只不过是定义和java那一套不太一样。
: 你呢？刚开始说cookie里只能放id不能放数据的是谁？
: 要说混淆视听，谁更混淆视听？
: ...................
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 10:45:51 2013) 提到:
你自己看看你自己说的吧
:存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，
在服
:务器端有一份。很多人说基于Cookie的Session，就以为所有的Session数据都在Cooki
e里，
:其实不是这样的，Cookie只放那个SessionID。
【 在 SlANmASTer 的大作中提到: 】
: 长贴啊，谢啦
: 1。大概意思是服务器端建表，以sessionid为键，存放客户端饼干的内容，等于客户
端饼
干在服务器侧也存了一份，自动登录在于维持饼干保存期。【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 10:42:32 2013), 站内
:
: 一个指出你概念有问题的人，你就说别人指出你错误是严重错误，说白了就是说别人不能指出你错误呗。
: 【 在 Knightmare 的大作中提到: 】
: : 这一系列帖子，我只不过是定义和java那一套不太一样。
: : 你呢？刚开始说cookie里只能放id不能放数据的是谁？
: : 要说混淆视听，谁更混淆视听？
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:52:30 2013) 提到:
只放SessionID这句话讨论的背景是Session实现相关数据这个大前提，而不是所有Cookie数据这个语境。你这纯粹是文革专案组方法。
我最后再提醒你，不要在N多书和帖子的大背景下，还要坚持属于你一个人的概念，没意思。
【 在 Knightmare 的大作中提到: 】
: 你自己看看你自己说的吧
: :存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，
: 在服
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 10:53:29 2013) 提到:
补一个简单讲这方面安全的帖子：
http://www.ibm.com/developerworks/cn/rational/08/0401_segal/【 在 Knightmare 的大作中提到: 】
: 你自己看看你自己说的吧
: :存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，
: 在服
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 11:00:01 2013) 提到:
没有人规定，不意味没有通行的做法和概念。
【 在 Knightmare 的大作中提到: 】
: 大哥你能列出来个稍微权威点的文章url么。
: 咱也别弄得太高端，给你个wikipedia的链接看看吧
:
http://en.wikipedia.org/wiki/Session_(computer_science)#Client_side_web_sess
: ...................
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 11:00:02 2013) 提到:
其实到现在你还没懂啊
client side web session是把session数据放cookie里的，做好check既是。
顺便说你也别再贴java那些什么说明了，cookie session什么的基本上只是java的概念
。真正严谨的是client side web session和server side web session.
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 10:52:30 2013), 站内
:
: 只放SessionID这句话讨论的背景是Session实现相关数据这个大前提，而不是所有Cookie数据这个语境。你这纯粹是文革专案组方法。
: 我最后再提醒你，不要在N多书和帖子的大背景下，还要坚持属于你一个人的概念，没意思。
: 【 在 Knightmare 的大作中提到: 】
: : 你自己看看你自己说的吧
: : :存放的不是Cookie内容，是Session数据，随机字符串SessionID在Cookie里面有一份，
: : 在服
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 11:01:44 2013) 提到:
在偷换混淆概念行不通的情况下，开始转换概念。我正视听的目的也算达到了。
【 在 Knightmare 的大作中提到: 】
: 其实到现在你还没懂啊
: client side web session是把session数据放cookie里的，做好check既是。
: 顺便说你也别再贴java那些什么说明了，cookie session什么的基本上只是java的概念
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 11:04:07 2013) 提到:
PHP书的章节我都给你列了，你却老说我是Java，别说PHP，你想看，我可以给你看Django的实现。不要老拿一种语言说事。
【 在 Knightmare 的大作中提到: 】
: 其实到现在你还没懂啊
: client side web session是把session数据放cookie里的，做好check既是。
: 顺便说你也别再贴java那些什么说明了，cookie session什么的基本上只是java的概念
: ...................
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 11:07:25 2013) 提到:
你知道为啥cookie session就不是啥通用的概念么？
因为cookie session本来就有二义性，你是cookie里只存一个sessionid呢，还是除了s
essionid还存session变量呢？
就算是java里，具体的说法也没什么cookie session。而是很严谨的说法session usin
g cookie或者session using url rewriting，而且一般是和与url rewriting比对的时
候才会说using cookie。
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 11:00:01 2013), 站内
:
: 没有人规定，不意味没有通行的做法和概念。
: 【 在 Knightmare 的大作中提到: 】
: : 大哥你能列出来个稍微权威点的文章url么。
: : 咱也别弄得太高端，给你个wikipedia的链接看看吧
: :
http://en.wikipedia.org/wiki/Session_(computer_science)#Client_side_web_sess
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 11:09:11 2013) 提到:
我前面就已经说的很清楚了。和URL重写对应的.....，你到现在了列出一个英文版，来否定别人的中文表达，你有意思吗？
【 在 Knightmare 的大作中提到: 】
: 你知道为啥cookie session就不是啥通用的概念么？
: 因为cookie session本来就有二义性，你是cookie里只存一个sessionid呢，还是除了s
: essionid还存session变量呢？
: ...................
☆─────────────────────────────────────☆
Knightmare (梦醒时分) 于 (Wed May 1 11:10:23 2013) 提到:
请正面回答23239
不过我懒得看了，checkout出门有事了。
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Wed May 1 11:09:11 2013), 站内
:
: 我前面就已经说的很清楚了。和URL重写对应的.....，你到现在了列出一个英文版，来否定我的中文版，你有意思吗？
: 【 在 Knightmare 的大作中提到: 】
: : 你知道为啥cookie session就不是啥通用的概念么？
: : 因为cookie session本来就有二义性，你是cookie里只存一个sessionid呢，还是除了s
: : essionid还存session变量呢？
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 110.232.55.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 11:19:02 2013) 提到:
正面啥呀，前面已经说的很清楚，是一个语境问题，这句话我是回答LZ提问者的，你自己把中间半句话截取出来做语义歪曲。你这种手法倒退几十年在文革时期很有用，现在已经过时了。
最可笑的是，重复完别人说过的话，被别人指出时，说自己懒得看，我给你回得第二个帖子就已经说过的话。列举N多书籍和资料来说明的问题，你老人家都认为是山寨，最后了，非要看看老外用英文表达出来的，才能自己接受。这真是中文万语不用英文一言，一个倒腾编程语言的人没必要拿另一门生活日常语言做....。
【 在 Knightmare 的大作中提到: 】
: 请正面回答23239
: 不过我懒得看了，checkout出门有事了。
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 12:38:42 2013) 提到:
放在用户方面的确是安全性问题，放在后端的问题用安全性解释值得商榷，大应用侧重前端的根本原因还是那个CAP的问题。也就是说一个具体应用设计中权衡的问题，大多数应用的访问量级也达不到那个水平。KN也许只是接Leader任务在一般容器Session机制（他的MD5数据在server端）的基础上做一个面向具体应用的扩充。他做扩充时的技术调研根本就不充分，只是实现别人的设计意图，而且他自始至终不是在讨论一个基本机制概念问题，不接受任何资料，只是不停地为自己辩驳而已。又不入监，又不死人，有什么可好辨的。
【 在 aotian 的大作中提到: 】
: 较多数据放在cookie里面牺牲用户的安全性保障系统的安全性
: cookie里面只放一个sessionid刚好反过来
:
☆─────────────────────────────────────☆
aotian (aotian) 于 (Wed May 1 12:42:30 2013) 提到:
如果前端只放一个sessionid，理论上来说在大用户量的时候，别人可能会通过修改这个sessionid
碰巧和另外一个人的sessionid符合，进而获得他的身份，如果这个人刚好是有管理权限的人，就存在
攻击系统的可能
如果前端放一个人的id和加密后的密码，那么理论上有密码泄露的可能，但是他无法通过修改id和
加密密码获得其他人的身份从而攻击系统
【 在 dhcn (小石) 的大作中提到: 】
: 放在用户方面的确是安全性问题，放在后端的问题用安全性解释值得商榷，大应用侧重前端的根本原因还是那个CAP的问题。也就是说一个具体应用设计中权衡的问题，大多数应用的访问量级也达不到那个水平。KN也许只是接Leader任务在一般容器Session机制（他的MD5数据在server
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 12:51:22 2013) 提到:
1、我先解释的前面的问题，猜SessionID，这个东西能不能泄漏，可以，但是一般的做法不是靠猜，那个计算成本太高了，他是随机的，你还没猜出来，就已经被行为识别系统Block了，一般的做法是靠XSS这样的手段，直接拿，然后报告给主子即可。当然XSS是稍微用个小手段就能防止的，在就是中间人，从代理层，直接取出来。
2、存加密密码这个问题，我简单说说，你就知道了，1、用户知道自己的密码明文是什么？2、用户也可以看到你加密后的密文是什么，然后算法基本就是公开的了。然后配合前面拿Cookie的方法，人家得到的就不是一个登录识别码了，而是整个用户。
【 在 aotian 的大作中提到: 】
: 如果前端只放一个sessionid，理论上来说在大用户量的时候，别人可能会通过修改这个sessionid
: 碰巧和另外一个人的sessionid符合，进而获得他的身份，如果这个人刚好是有管理权限的人，就存在
: 攻击系统的可能
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 12:52:55 2013) 提到:
再说一点：3、关于前端放什么，不管后端量压力再大，都得是有一个安全底线，某些东西不能往前端放。对于这一点，某款安全扫描工具报告加固方案的第一条就是谈这个问题。
国内大用户量，低安全等级要求的应用典型我觉得比较合适的是微博，你可以用Chrome登录你的微博看看，它都放了些什么。
【 在 aotian 的大作中提到: 】
: 如果前端只放一个sessionid，理论上来说在大用户量的时候，别人可能会通过修改这个sessionid
: 碰巧和另外一个人的sessionid符合，进而获得他的身份，如果这个人刚好是有管理权限的人，就存在
: 攻击系统的可能
: ...................
☆─────────────────────────────────────☆
ottffsse (nothing) 于 (Wed May 1 13:41:14 2013) 提到:
理论上，能猜sessionid就能猜密码。
【 在 aotian (aotian) 的大作中提到: 】
: 如果前端只放一个sessionid，理论上来说在大用户量的时候，别人可能会通过修改这个sessionid
: 碰巧和另外一个人的sessionid符合，进而获得他的身份，如果这个人刚好是有管理权限的人，就存在
: 攻击系统的可能
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 13:47:20 2013) 提到:
后者有彩虹表社工库。猜起来稍微容易一点。
【 在 ottffsse 的大作中提到: 】
: 理论上，能猜sessionid就能猜密码。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 14:25:30 2013) 提到:
正常点的框架对session的处理都是在cookie里存AES加密后的东西，只要AES的key不泄露信息就是安全的，以现在的计算机结构，算这个KEY难度比你黑掉这个服务器从配置文件里把KEY拿出来的难度高得多(而你要能黑到这步，拿数据库权限都不是问题了，还去管这个KEY么)。
【 在 dhcn (小石) 的大作中提到: 】
: 1、我先解释的前面的问题，猜SessionID，这个东西能不能泄漏，可以，但是一般的做法不是靠猜，那个计算成本太高了，他是随机的，你还没猜出来，就已经被行为识别系统Block了，一般的做法是靠XSS这样的手段，直接拿，然后报告给主子即可。当然XSS是稍微用个小手段就能防
: 2、存加密密码这个问题，我简单说说，你就知道了，1、用户知道自己的密码明文是什么？2、用户也可以看到你加密后的密文是什么，然后算法基本就是公开的了。然后配合前面拿Cookie的方法，人家得到的就不是一个登录识别码了，而是整个用户。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 14:32:40 2013) 提到:
如果Key放在服务器端，Key怎么生成？你的Key是以什么机制存储？怎么和每个会话浏览器一一对应？
【 在 ttl 的大作中提到: 】
: 正常点的框架对session的处理都是在cookie里存AES加密后的东西，只要AES的key不泄露信息就是安全的，以现在的计算机结构，算这个KEY难度比你黑掉这个服务器从配置文件里把KEY拿出来的难度高得多(而你要能黑到这步，拿数据库权限都不是问题了，还去管这个KEY么)。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 14:42:05 2013) 提到:
数据 "sessionid=xxx"
服务器配置文件里 key = "blablabla"
服务器用这个key加密后数据写到cookie里， session=pMkuppmjTWh046t3xPp9zw==
浏览器访问时 session=pMkuppmjTWh046t3xPp9zw== 回传回服务器。
服务器用key="blablabla"一解开得到sessionid=xxx，然后去干事就行了。
【 在 dhcn (小石) 的大作中提到: 】
: 如果Key放在服务器端，你的Key是以什么机制存储？怎么和每个会话浏览器一一对应？
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 14:47:39 2013) 提到:
再就是，“正常点的框架对session的处理都是在cookie里存AES加密后的东西"这句话，你作为一个版主ID发言，直接把扩展方案当作基本解决方案来做这样的定性结论是不严谨的，你可以回去认真看看正常点的框架的基本特性文档。
【 在 ttl 的大作中提到: 】
: 正常点的框架对session的处理都是在cookie里存AES加密后的东西，只要AES的key不泄露信息就是安全的，以现在的计算机结构，算这个KEY难度比你黑掉这个服务器从配置文件里把KEY拿出来的难度高得多(而你要能黑到这步，拿数据库权限都不是问题了，还去管这个KEY么)。
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 14:49:16 2013) 提到:
所有应用一个Key，你稍微整个特定算法生成的盐值都比这个强吧？
至于这几种方案的权衡：
8.1.2. Session数据存在哪？
Session的状态数据是怎样保存的呢？
8.1.2.1. 保存在应用服务器的内存中
一般的做法，是将session对象保存在内存里。同一时间，会有很多session被保存在服务器的内存里。由于内存是有限的，较好的服务器会把session对象的数据交换到文件中，以确保内存中的session数目保持在一个合理的范围内。
为了提高系统扩展性和可用性，我们会使用集群技术 —— 就是一组独立的机器共同运行同一个应用。对用户来讲，集群相当于一台“大型服务器”。而实际上，同一用户的两次请求可能被分配到两台不同的服务器上来处理。这样一来，怎样保证两次请求中存取的session值一致呢？
一种方法是使用session复制：当session的值被改变时，将它复制到其它机器上。这个方案又有两种具体的实现，一种是广播的方式。这种方式下，任何一台服务器都保存着所有服务器所接受到的session对象。服务器之间随时保持着同步，因而所有服务器都是等同的。可想而知，当访问量增大的时候，这种方式花费在广播session上的带宽有多大，而且随着机器增加，网络负担成指数级上升，不具备高度可扩展性。
另一种方法是TCP-Ring的方式，也就是把集群中所有的服务器看成一个环，A→B→C→D→A，首尾相接。把A的session复制到B，B的session复制到C，……，以此类推，最后一台服务器的session复制到A。这样，万一A宕机，还有B可以顶上来，用户的session数据不会轻易丢失。但这种方案也有缺点：一是配置复杂；二是每增添/减少一台机器时，ring都需要重新调整，这将成为性能瓶颈；三是要求前端的Load Balancer具有相当强的智能，才能将用户请求分发到正确的机器上。
8.1.2.2. 保存在单一数据源中
也可以将session保存在单一的数据源中，这个数据源可被集群中所有的机器所共享。这样一来，就不存在复制的问题了。
然而单一数据源的性能成了问题。每个用户请求，都需要访问后端的数据源（很可能是数据库）来存取用户的数据。
这种方案的第二个问题是：缺少应用服务厂商的支持 —— 很少有应用服务器直接支持这种方案。更不用说数据源有很多种（MySQL、Oracle、Hsqldb等各种数据库、专用的session server等）了。
第三个问题是：数据源成了系统的瓶颈，一但这个数据源崩溃，所有的应用都不可能正常运行了。
8.1.2.3. 保存在客户端
把session保存在客户端。这样一来，由于不需要在服务器上保存数据，每台服务器就变得独立，能够做到线性可扩展和极高的可用性。
具体怎么做呢？目前可用的方法，恐怕就是保存在cookie中了。但需要提醒的是，cookie具有有以下限制，因此不可无节制使用该方案：
Cookie数量和长度的限制。每个domain最多只能有20条cookie，每个cookie长度不能超过4KB，否则会被截掉。
安全性问题。如果cookie被人拦截了，那人就可以取得所有的session信息。即使加密也与事无补，因为拦截者并不需要知道cookie的意义，他只要原样转发cookie就可以达到目的了。
有些状态不可能保存在客户端。例如，为了防止重复提交表单，我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端，那么它起不到任何作用。
虽然有上述缺点，但是对于其优点（极高的扩展性和可用性）来说，就显得微不足道。我们可以用下面的方法来回避上述的缺点：
通过良好的编程，控制保存在cookie中的session对象的大小。
通过加密和安全传输技术（SSL），减少cookie被破解的可能性。
只在cookie中存放不敏感数据，即使被盗也不会有重大损失。
控制cookie的生命期，使之不会永远有效。偷盗者很可能拿到一个过期的cookie。
8.1.2.4. 将客户端、服务器端组合的方案
任何一种session方案都有其优缺点。最好的方法是把它们结合起来。这样就可以弥补各自的缺点。
将大部分session数据保存在cookie中，将小部分关键和涉及安全的数据保存在服务器上。由于我们只把少量关键的信息保存在服务端，因而服务器的压力不会非常大。
在服务器上，单一的数据源比复制session的方案，更简单可靠。我们可以使用数据库来保存这部分session，也可以使用更廉价、更简单的存储，例如Berkeley DB就是一种不错的服务器存储方案。将session数据保存在cookie和Berkeley DB（或其它类似存储技术）中，就可以解决我们的绝大部分问题。
8.1.3. 创建通用的session框架
多数应用服务器并没有留出足够的余地，来让你自定义session的存储方案。纵使某个应用服务器提供了对外扩展的接口，可以自定义session的方案，我们也不大可能使用它。为什么呢？因为我们希望保留选择应用服务器软件的自由。
因此，最好的方案，不是在应用服务器上增加什么新功能，而是在WEB应用框架上做手术。一但我们在WEB应用框架中实现了这种灵活的session框架，那么我们的应用可以跑在任何标准的JavaEE应用服务器上。
除此之外，一个好的session框架还应该做到对应用程序透明。具体表现在：
使用标准的HttpSession接口，而不是增加新的API。这样任何WEB应用，都可以轻易在两种不同的session机制之间切换。
应用程序不需要知道session中的对象是被保存到了cookie中还是别的什么地方。
Session框架可以把同一个session中的不同的对象分别保存到不同的地方去，应用程序同样不需要关心这些。例如，把一般信息放到cookie中，关键信息放到Berkeley DB中。甚至同是cookie，也有持久和临时之分，有生命期长短之分。
【 在 ttl 的大作中提到: 】
: 数据 "sessionid=xxx"
: 服务器配置文件里 key = "blablabla"
: 服务器用这个key加密后数据写到cookie里， session=pMkuppmjTWh046t3xPp9zw==
: ...................
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 14:50:45 2013) 提到:
我就给你一串 pMkuppmjTWh046t3xPp9zw== 你能知道原文？呵呵。
【 在 dhcn (小石) 的大作中提到: 】
: 所有应用一个Key，你稍微整个特定算法生成的盐值都比这个强吧？
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 14:52:28 2013) 提到:
那你看现在哪个大网站的session不是这么做的？
【 在 dhcn (小石) 的大作中提到: 】
: 再就是，“正常点的框架对session的处理都是在cookie里存AES加密后的东西"这句话，你作为一个版主ID发言，直接把扩展方案当作基本解决方案来做这样的定性结论是不严谨的，你可以回去认真看看正常点的框架的基本特性文档。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 14:53:46 2013) 提到:
你怎么造，也是用户自己的信息，如果是你自己的信息，有必要放到Session里面吗？
【 在 ttl 的大作中提到: 】
: 我就给你一串 pMkuppmjTWh046t3xPp9zw== 你能知道原文？呵呵。
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 14:55:01 2013) 提到:
这个问题的解释，我之前已经讲了，而且我知道我的解释，肯定不会有人听。好吧，我上面帖子上文档了，我想够详细了吧。
【 在 ttl 的大作中提到: 】
: 那你看现在哪个大网站的session不是这么做的？
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 14:59:16 2013) 提到:
补充一点：你那句话说的是正常.......都是........,这个世界的正常情况下有几个网站能和大网站的并发流量比，至于都是就不用说了，现在单ServerWeb应用要都是这个，那就是实现者吃多了。
【 在 ttl 的大作中提到: 】
: 那你看现在哪个大网站的session不是这么做的？
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 15:07:15 2013) 提到:
我只是想说AES加密的cookie存啥其实都没有被知道里面内容的可能。（在没有黑掉服务器拿到这个key的情况下），你要是对我的措辞不满意，可以使劲喷，我不介意的，我向来以语文不好著称的。
你给的那个存session的方案文档倒是很适合给楼主看。
【 在 dhcn (小石) 的大作中提到: 】
: 补充一点：你那句话说的是正常.......都是........,这个世界的正常情况下有几个网站能和大网站的并发流量比，至于都是就不用说了，自己扩张Session实现也得编码，自动识别就更麻烦了。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 15:20:13 2013) 提到:
其实我觉得如果真要放，只放那些能放的不重要数据就行了，AES也没必要，至于破解，现在这个场景的破解重点是找Key，不是找明文内容，野蛮攻击都不用，AES密钥的大小可以是128、192、256比特，不需要我说什么吧？
【 在 ttl 的大作中提到: 】
: 我只是想说AES加密的cookie存啥其实都没有被知道里面内容的可能。（在没有黑掉服务器拿到这个key的情况下），你要是对我的措辞不满意，可以使劲喷，我不介意的，我向来以语文不好著称的。
: 你给的那个存session的方案文档倒是很适合给楼主看。
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 15:21:44 2013) 提到:
"使劲喷"这样几个字,不是一个严肃技术版版主应有的风度。
【 在 ttl 的大作中提到: 】
: 我只是想说AES加密的cookie存啥其实都没有被知道里面内容的可能。（在没有黑掉服务器拿到这个key的情况下），你要是对我的措辞不满意，可以使劲喷，我不介意的，我向来以语文不好著称的。
: 你给的那个存session的方案文档倒是很适合给楼主看。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 15:22:49 2013) 提到:
aSdQxIpbhcg27N7Xo6dkfQ==
aes192加密的，你把key找出来我看看？
【 在 dhcn (小石) 的大作中提到: 】
: 其实我觉得如果真要放，只放那些能放的不重要数据就行了，AES也没必要，至于破解，现在这个场景的破解重点是找Key，不是找明文内容，野蛮攻击都不用，AES密钥的大小可以是128、192、256比特，不需要我说什么吧？
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 15:26:38 2013) 提到:
同学，我不是Hacker，我只是告诉你一个具体应用场景解决方案理论上存在的漏洞，你这明显不是讨论技术问题了，如果真要挑战，你也应该把使用这种方案的具体应用说出来，给渗透测试授权协议书，然后再开始下面的问题。
【 在 ttl 的大作中提到: 】
: aSdQxIpbhcg27N7Xo6dkfQ==
: aes192加密的，你把key找出来我看看？
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 15:36:12 2013) 提到:
不是挑战的问题，现有的理论体系+计算机框架破解AES加密是不可能的，这是一个常识。
【 在 dhcn (小石) 的大作中提到: 】
: 同学，我不是Hacker，我只是告诉你一个具体应用场景解决方案理论上存在的漏洞，你这明显不是讨论技术问题了，如果真要挑战，你也应该把使用这种方案的具体应用说出来，给渗透测试授权协议书，然后再开始下面的问题。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 15:42:50 2013) 提到:
那个破解是由密文得明文，而你往Cookie的数据如果对Cookie数据做严密监控，其实明文内容是可以猜出来的，（比如数据添加的时机等因素），所以破解的不是明文，而是破解Key。
【 在 ttl 的大作中提到: 】
: 不是挑战的问题，现有的理论体系+计算机框架破解AES加密是不可能的，这是一个常识。
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 15:46:53 2013) 提到:
我举个简单案例：那些做游戏外怪的人可能就会用这种方式，当然难度比你这个大，因为他的Key固定周期没有那么长。
【 在 ttl 的大作中提到: 】
: 不是挑战的问题，现有的理论体系+计算机框架破解AES加密是不可能的，这是一个常识。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 15:49:00 2013) 提到:
你要是把key都破解出来了，明文不久出来了么？你这个解释是想表达神马？
【 在 dhcn (小石) 的大作中提到: 】
: 那个破解是由密文得明文，而你往Cookie的数据如果对Cookie数据做严密监控，其实明文内容是可以猜出来的，（比如数据添加的时机等因素），所以破解的不是明文，而是破解Key。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 15:52:24 2013) 提到:
我的意思是说，先确定明文内容，然后根据明文和密文得密钥，剩下你会问做什么，如果你的Server端什么会话状态数据都不保存验证的话，客户端就可以利用你那个唯一的密钥伪造业务状态数据了。
【 在 ttl 的大作中提到: 】
: 你要是把key都破解出来了，明文不久出来了么？你这个解释是想表达神马？
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 16:02:42 2013) 提到:
1. 知道明文，算key对现有理论体系+计算机架构也是不可能的，如果是我知识落后了，麻烦你给个文档。
2. 就算你说的成立，明文里带个随机数可破之。
【 在 dhcn (小石) 的大作中提到: 】
: 我的意思是说，先确定明文内容，然后根据明文和明文得密钥，剩下你会问做什么，如果你的Server端什么会话状态数据都不保存验证的话，客户端就可以利用你那个唯一的密钥伪造业务状态数据了。
☆─────────────────────────────────────☆
aotian (aotian) 于 (Wed May 1 16:08:51 2013) 提到:
别忘了id和密码是有对应的，你不可能用A的id和B的密码登入
【 在 ottffsse (nothing) 的大作中提到: 】
: 理论上，能猜sessionid就能猜密码。
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 16:38:20 2013) 提到:
要穷举啊，咱就拿最弱的来吧，128bit，你机器超强，你一秒穷举10亿个可能，128bit等你穷举完是多少时间？
【 在 dhcn (小石) 的大作中提到: 】
: 你觉得难搞，我提一个问题，RJ以多少算法分支选择性来阻挡一个256比特数据的穷举？
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 17:15:13 2013) 提到:
稍微较真一下：根据你的Web应用场景计算要求，肯定不可能用高配置的AES，访问量大，商业目标价值也大，搞的人如果用Square等简化运算量级的算法+几个云主机或者GPU也不是不可能。那个Square攻击算法就不用我列文档了吧，很出名啊。
【 在 ttl 的大作中提到: 】
: 要穷举啊，咱就拿最弱的来吧，128bit，你机器超强，你一秒穷举10亿个可能，128bit等你穷举完是多少时间？
:
☆─────────────────────────────────────☆
ottffsse (nothing) 于 (Wed May 1 17:17:27 2013) 提到:
一回事。无非是sessionid长短的问题
【 在 dhcn (小石) 的大作中提到: 】
: 后者有彩虹表社工库。猜起来稍微容易一点。
☆─────────────────────────────────────☆
ottffsse (nothing) 于 (Wed May 1 17:19:02 2013) 提到:
你看看我回的贴——我是说他说的猜sessionid而猜不出来密码的论据不成立。
【 在 aotian (aotian) 的大作中提到: 】
: 别忘了id和密码是有对应的，你不可能用A的id和B的密码登入
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 17:21:16 2013) 提到:
我是说实操面密码好猜，你理解反了吧？
【 在 ottffsse 的大作中提到: 】
: 一回事。无非是sessionid长短的问题
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 17:41:45 2013) 提到:
算法在前年有过一次突破，128bit把世界上最强的几台超级计算机用上，勉强可以在有生之年算完吧。而且以现在CPU性能，还选128bit的少年越来越少了吧。
话说，数据要是有那破解价值，绝对早早地就上aes256了。
【 在 dhcn (小石) 的大作中提到: 】
: 稍微较真一下：根据你的Web应用场景计算要求，肯定不能用高配置的AES，访问量大，商业目标价值也大，搞的人如果用Square等简化运算量级的算法+几个云主机或者GPU也不是不可能。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 19:03:57 2013) 提到:
现在的主要区别在轮数上，因为破解的时候重点关注某些位。
再就是我指出你一个根本实现上的漏洞，全Cookie的实现机制，Session的有效时间这个特性基本就等于无法控制的摆设了。
【 在 ttl 的大作中提到: 】
: 算法在前年有过一次突破，128bit把世界上最强的几台超级计算机用上，勉强可以在有生之年算完吧。而且以现在CPU性能，还选128bit的少年越来越少了吧。
: 话说，数据要是有那破解价值，绝对早早地就上aes256了。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 19:33:41 2013) 提到:
我可没说过全cookie啊，我给你举的例子里可是只存session id的。
我只是说，东西加密放cookie里是安全的，不用担心泄露问题，而你之前回文看着象很容易搞出来似的。
至于放什么，你自己那篇回文已经基本覆盖了流行的方案了。
现在流行的框架里，基本都配个session key+session加密算法(选AES)，然后配置一下session存储的层就可以了，都可以认为它是安全的，不会泄露信息的。
【 在 dhcn (小石) 的大作中提到: 】
: 现在的主要区别在轮数上，因为破解的时候重点关注某些位。
: 再就是我指出你一个根本实现上的漏洞，全Cookie的实现机制，Session的有效时间这个特性基本就等于无法控制的摆设了。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 21:07:52 2013) 提到:
我真正批驳的是有人定制实现了个Session接口，就认为容器基本Session机制不存在甚至对新手做概念混淆错误诱导的问题。
至于这种一部分放Server端，一部分放Cooie端在那篇文档之前我就应用场景解释了，你还再来一个正常...都是...(你去看你那句话的表述，完全的全Cookie存储，一点SERVER端都没提。)，然后在正确的方案里面某一部分数据加个密然后就标称完全不一样，你这不对真正的问题裹乱吗？
【 在 ttl 的大作中提到: 】
: 我可没说过全cookie啊，我给你举的例子里可是只存session id的。
: 我只是说，东西加密放cookie里是安全的，不用担心泄露问题，而你之前回文看着象很容易搞出来似的。
: 至于放什么，你自己那篇回文已经基本覆盖了流行的方案了。
: ...................
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 21:54:20 2013) 提到:
我就没跟你讨论过session在前端后端如何存储如何对应啊，我回你这么多，都是因为你这篇
发信人: dhcn (小石), 信区: WebDev
标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
发信站: 水木社区 (Wed May 1 12:51:22 2013), 站内
1、我先解释的前面的问题，猜SessionID，这个东西能不能泄漏，可以，但是一般的做法不
是靠猜，那个计算成本太高了，他是随机的，你还没猜出来，就已经被行为识别系统Block
了，一般的做法是靠XSS这样的手段，直接拿，然后报告给主子即可。当然XSS是稍微用个小
手段就能防止的，在就是中间人，从代理层，直接取出来。
2、存加密密码这个问题，我简单说说，你就知道了，1、用户知道自己的密码明文是什么？
2、用户也可以看到你加密后的密文是什么，然后算法基本就是公开的了。然后配合前面拿
Cookie的方法，人家得到的就不是一个登录识别码了，而是整个用户。
你这里说的跟加密存储的信息解开跟玩儿似的，实际上根本不是这样，动用最NB的计算资源都得用年为单位的东西，你觉得几块显卡就能搞定，我所有回帖都在跟你说，AES加密，就不要想解开它的问题。
【 在 dhcn (小石) 的大作中提到: 】
: 我真正批驳的是有人定制实现了个Session接口，就认为容器基本Session机制不存在甚至对新手做概念混淆错误诱导的问题。
: 至于这种一部分放Server端，一部分放Cooie端在那篇文档之前我就应用场景解释了，你还再来一个正常...都是...(你去看你那句话的表述，完全的全Cookie存储，一点SERVER端都没提。)，然后在正确的方案里面某一部分数据加个密然后就标称完全不一样，你这不对真正的问题裹乱
☆─────────────────────────────────────☆
dhcn (小石) 于 (Wed May 1 22:11:55 2013) 提到:
Square那个里没有看吧，它在低轮数简化以后的效果，计算量已经基本接近DES破解。
再就是客户端单向加密最大的劣势是无法发挥目前Web应用场景下前端缓存真正的优势--本地数据操作。
KN也许没搞明白它的方案是基于什么Session机制实现的，但它实现的设计方案还是有可取之处的。前端可操作，后端可验证。
【 在 ttl 的大作中提到: 】
: 我就没跟你讨论过session在前端后端如何存储如何对应啊，我回你这么多，都是因为你这篇
: 发信人: dhcn (小石), 信区: WebDev
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: ...................
☆─────────────────────────────────────☆
ttl (小驴) 于 (Wed May 1 22:34:57 2013) 提到:
不是有简化算法，把全球所有机器都来算，算到地球毁灭也解不开一个aes128啊。AES到目前没有非常有效的攻击手段的，aes 128没记错的话是10轮的，你自己看看攻击10轮的复杂度是多高。
【 在 dhcn (小石) 的大作中提到: 】
: Square那个里没有看吧，它在低轮数简化以后的效果，计算量已经基本接近DES破解。
: 再就是客户端单向加密最大的劣势是无法发挥目前Web应用场景下前端缓存真正的优势--本地数据操作。
: KN也许没搞明白它的方案是基于什么Session机制实现的，但它实现的设计方案还是有可取之处的。前端可操作，后端可验证。
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 09:04:24 2013) 提到:
轮数不是唯一指定的，只是有上限，根据具体应用场景选择，在Web处理场景，你的轮数过高的话，就已经悖离了你选择Cookie端存储的一个基本初衷：性能问题。
在从提及Square到现在,我发现你和KN不同程度地存在一样的问题：就是拒绝资料和文档学习调研。在某些环境下，这种情况是大多数，但我认为这不是开发技术工作者应有的学习态度。
【 在 ttl 的大作中提到: 】
: 不是有简化算法，把全球所有机器都来算，算到地球毁灭也解不开一个aes128啊。AES到目前没有非常有效的攻击手段的，aes 128没记错的话是10轮的，你自己看看攻击10轮的复杂度是多高。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 10:44:59 2013) 提到:
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
跟我说了这么久，你看过一篇正儿八经的文档么，aes128 10轮，aes192 12轮，aes 256 14轮，固定的。
我不说了么，我给你的时间都是基于简化算法（这个概念你提的，我觉得名字还算符合）的，11年的时候还有过一次突破的，比你的square attack提升了3到5倍的效率，你要是想知道细节，看这里
http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf
现在的机器性能负担aes256都完全不是问题，现在新买的机器CPU都有AES指令集，aes256的吞吐率在都过100MB/s，你要买的起这带宽，机器成本根本不是问题了。
【 在 dhcn (小石) 的大作中提到: 】
: 轮数不是唯一指定的，只是有上限，根据具体应用场景选择，在Web处理场景，你的轮数过高的话，就已经悖离了你选择Cookie端存储的一个基本初衷：性能问题。
: 在从提及Square到现在,我发现你和KN不同程度地存在一样的问题：就是拒绝资料和文档学习调研。在某些环境下，这种情况是大多数，但我认为这不是开发技术工作者应有的学习态度。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 11:21:00 2013) 提到:
计算如果有硬件层支撑，也许不是问题。
关于文档是不是正经，你又回到KN的那个问题：用自己的主观质疑大多数现成资料，我昨天主要参考密码学书籍和在线资料。
轮数是不是固定，我单位没放这类书，给你一个北大的课程PPT你自己看吧(15页右下角)：
http://infosec.pku.edu.cn/~caojl/download/G09-04n.pdf
AES (Rijndael)算法结构
Rijndael:可变块长、可变密钥长度 根据AES的要求，分组长度指定为128 位，密钥长度为128，192或256位，相 应的迭代轮数R为10、12和14。
【 在 ttl 的大作中提到: 】
:
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard: 跟我说了这么久，你看过一篇正儿八经的文档么，aes128 10轮，aes192 12轮，aes 256 14轮，固定的。
: 我不说了么，我给你的时间都是基于简化算法（这个概念你提的，我觉得名字还算符合）的，11年的时候还有过一次突破的，比你的square attack提升了3到5倍的效率，你要是想知道细节，看这里
: ...................
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 11:26:05 2013) 提到:
15页右下角已经告诉你aes 128是10轮了啊，没说上限10轮啊。
你是觉得维基百科跟微软的文档不可信是咋的。
【 在 dhcn (小石) 的大作中提到: 】
: 计算如果有硬件层支撑，也许不是问题。
: 关于文档，昨天主要参考密码学书籍和在线资料。
: 轮数是不是固定，我单位没放这类书，给你一个北大的课程PPT你自己看吧(15页右下角)：
: ...................
☆─────────────────────────────────────☆
HGL (荆棘) 于 (Thu May 2 11:30:46 2013) 提到:
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Thu May 2 11:21:00 2013), 站内
:
: 计算如果有硬件层支撑，也许不是问题。
: 关于文档是不是正经，你又回到KN的那个问题：用自己的主观质疑大多数现成资料，我昨天主要参考密码学书籍和在线资料。
: 轮数是不是固定，我单位没放这类书，给你一个北大的课程PPT你自己看吧(15页右下角)：
:
http://infosec.pku.edu.cn/~caojl/download/G09-04n.pdf: AES (Rijndael)算法结构
: Rijndael:可变块长、可变密钥长度 根据AES的要求，分组长度指定为128 位，密钥长度为128，192或256位，相 应的迭代轮数R为10、12和14。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这。。。。
: 【 在 ttl 的大作中提到: 】
: :
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard: : 跟我说了这么久，你看过一篇正儿八经的文档么，aes128 10轮，aes192 12轮，aes 256 14轮，固定的。
: : 我不说了么，我给你的时间都是基于简化算法（这个概念你提的，我觉得名字还算符合）的，11年的时候还有过一次突破的，比你的square attack提升了3到5倍的效率，你要是想知道细节，看这里
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
: ※ 修改:·dhcn 于 May 2 11:27:53 2013 修改本文·[FROM: 124.42.13.*]
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 124.42.13.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 11:37:06 2013) 提到:
KN也是这样，只看自己想看的东西,你说的这句话在括号里面，它为上面哪句做解好似，括号上面这一句是：所有轮密钥比特的总数等于分组长度乘轮数加1。后面还给你列了一个计算案例。推一万步讲，如果轮数真的完全固定，那些研究低轮数破解的人难道仅仅是为了Paper玩？
Wiki百科不是不可信，只是有时候表述不严谨。KN也是拿那个上面充数。
【 在 ttl 的大作中提到: 】
: 15页右下角已经告诉你aes 128是10轮了啊，没说上限10轮啊。
: 你是觉得维基百科跟微软的文档不可信是咋的。
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 11:38:08 2013) 提到:
你只看了结论，没看清楚前提。
【 在 HGL 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这。。。。
: ※ 修改:·dhcn 于 May 2 11:27:53 2013 修改本文·[FROM: 124.42.13.*]
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 11:41:51 2013) 提到:
http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf
这篇微软的技术细节的文档，有square attack以及他们的NB算法的细节，那你怎么不看呢
你能找到成功攻击AES的案例么？目前只有利用系统漏洞的旁道攻击成功过，那不是AES的问题
AES在目前的理论体系+计算机架构下是不可破的，这种常识性的东西，你非要质疑，那你潜心研究写个论文吧，成功了绝对载入史册。
【 在 dhcn (小石) 的大作中提到: 】
: KN也是这样，只看自己想看的东西,你说的这句话在括号里面，它为上面哪句做解好似，括号上面这一句是：所有轮密钥比特的总数等于分组长度乘轮数加1。后面还给你列了一个计算案例。推一万步讲，如果轮数真的完全固定，那些研究低轮数破解的人难道仅仅是为了Paper玩？
: Wiki百科不是不可信，只是有时候表述不严谨。KN也是拿那个上面充数。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 11:50:50 2013) 提到:
现在问题已经转到轮数是否绝对固定这个问题了，你又跳回到square attack这个已经取得共识Pass掉的问题。你这不成转移话题了吗？
【 在 ttl 的大作中提到: 】
:
http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf: 这篇微软的技术细节的文档，有square attack以及他们的NB算法的细节，那你怎么不看呢
: 你能找到成功攻击AES的案例么？目前只有利用系统漏洞的旁道攻击成功过，那不是AES的问题
: ...................
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 12:20:56 2013) 提到:
【 在 dhcn (小石) 的大作中提到: 】
: 标 题: Re: MD5加密，网上随便找个JS，靠得住吗？
: 发信站: 水木社区 (Thu May 2 11:21:00 2013), 站内
:
: 计算如果有硬件层支撑，也许不是问题。
: 关于文档是不是正经，你又回到KN的那个问题：用自己的主观质疑大多数现成资料，我昨天主要参考密码学书籍和在线资料。
: 轮数是不是固定，我单位没放这类书，给你一个北大的课程PPT你自己看吧(15页右下角)：
:
http://infosec.pku.edu.cn/~caojl/download/G09-04n.pdf: AES (Rijndael)算法结构
: Rijndael:可变块长、可变密钥长度 根据AES的要求，分组长度指定为128 位，密钥长度为128，192或256位，相应的迭代轮数R为10、12和14。
如果我们说的轮数是这个，那不就已经明了么？
: 【 在 ttl 的大作中提到: 】
: :
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard: : 跟我说了这么久，你看过一篇正儿八经的文档么，aes128 10轮，aes192 12轮，aes 256 14轮，固定的。
: : 我不说了么，我给你的时间都是基于简化算法（这个概念你提的，我觉得名字还算符合）的，11年的时候还有过一次突破的，比你的square attack提升了3到5倍的效率，你要是想知道细节，看这里
: : ...................
:
: --
: 玉不琢，不成器。
: 读千卷书，行千万里路：这个标准比较符合这个时代。
: ※ 修改:·dhcn 于 May 2 11:27:53 2013 修改本文·[FROM: 124.42.13.*]
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 124.42.13.*]
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 12:26:22 2013) 提到:
你在你引用课件PPT的那句话上下背景看全了，再把这句话的前提条件也看全了再下结论。
【 在 ttl 的大作中提到: 】
: 如果我们说的轮数是这个，那不就已经明了么？
: ※ 修改:·dhcn 于 May 2 11:27:53 2013 修改本文·[FROM: 124.42.13.*]
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 12:28:09 2013) 提到:
AES is a variant of Rijndael which has a fixed block size of 128 bits, and a key size of 128, 192, or 256 bits.
The key size used for an AES cipher specifies the number of repetitions of transformation rounds that convert the input, called the plaintext, into the final output, called the ciphertext. The number of cycles of repetition are as follows:
10 cycles of repetition for 128-bit keys.
12 cycles of repetition for 192-bit keys.
14 cycles of repetition for 256-bit keys.
那你对这个描述有异议么？
还有你是见过某家的crypto库的AES有rounds这个参数的？这么有自信。
【 在 dhcn (小石) 的大作中提到: 】
: 你在你引用课件PPT的那句话上下背景看全了，再把这句话的前提条件也看全了再下结论。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 13:23:47 2013) 提到:
我提醒你分组大小也是一个因素，然后你来个标准规定把block size人为Fixed掉，这不是Bug，你Fix了，它就会彻底消失。我们是在讨论一个算法技术细节问题。AES是，它选择了Rijndael算法作为其方案，况且我昨天可就直接提过Rd的（Rd就是哪两个作者的头字母，他们俩的名字也是算法名称的来源）。不要断章取义地引经据典。
【 在 ttl 的大作中提到: 】
: AES is a variant of Rijndael which has a fixed block size of 128 bits, and a key size of 128, 192, or 256 bits.
: The key size used for an AES cipher specifies the number of repetitions of transformation rounds that convert the input, called the plaintext, into the final output, called the ciphertext. The number of cycles of repetition are as follows:
: 10 cycles of repetition for 128-bit keys.
: ...................
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 13:28:17 2013) 提到:
AES的名字是Advanced Encryption Standard，本身就是一个标准。指定了block size跟key size以及轮数。而Rijndael使用的密钥和区块长度可以是32位的整数倍，以128位为下限，256比特为上限。
难道你真的在哪家的库里见过AES可以指定block大小和round的？求参观~~~
【 在 dhcn (小石) 的大作中提到: 】
: 我提醒你分组大小也是一个因素，然后你来个标准规定把block size人为Fixed掉，这不是Bug，你Fix了，它就会彻底消失。我们是在讨论一个算法技术问题。AES标准只是选择了Rijndael算法作为其方案，况且我昨天可就直接提过Rd的（Rd就是哪两个作者的头字母，他们俩的名字也是
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 13:36:17 2013) 提到:
这只是标准固定了它而已，人为固定的算法参数和真正的常数是有区别，你的数学实现库里面PI的大小你能指定成6.28吗？
【 在 ttl 的大作中提到: 】
: AES的名字是Advanced Encryption Standard，本身就是一个标准。指定了block size跟key size以及轮数。而Rijndael使用的密钥和区块长度可以是32位的整数倍，以128位为下限，256比特为上限。
: 难道你真的在哪家的库里见过AES可以指定block大小和round的？求参观~~~
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 13:41:38 2013) 提到:
所以AES是128 block size，key size 128，192，256，对应轮数是10，12，14，这是固定的啊，低轮的rd可破，你就觉得AES也可破，这是什么逻辑？
【 在 dhcn (小石) 的大作中提到: 】
: 这只是标准固定了它而已，人为固定的算法参数和真正的常数是有区别，你的数学实现库里面PI的大小你能指定成6.28吗？
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 13:47:42 2013) 提到:
你之前的论述是只承认KeySize，不承认block size这个因素好不好？
【 在 ttl 的大作中提到: 】
: 所以AES是128 block size，key size 128，192，256，对应轮数是10，12，14，这是固定的啊，低轮的rd可破，你就觉得AES也可破，这是什么逻辑？
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 13:49:24 2013) 提到:
你要用rd才有block size的问题，我们一直在说固定block size的AES，这个东西有必要提么，还是你刚知道AES是固定block size啊？
【 在 dhcn (小石) 的大作中提到: 】
: 你之前的论述是只承认KeySize，不承认block size这个因素好不好？
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 13:56:11 2013) 提到:
你这样提问就好比，我一直说圆周长与半径有关，你突然冒出一句，还有PI的因素好不好。
【 在 dhcn (小石) 的大作中提到: 】
: 你之前的论述是只承认KeySize，不承认block size这个因素好不好？
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 13:59:33 2013) 提到:
你和我讨论存在并行问题：
1、你的知识来源可能直接来自于实现一个标准的算法库接口。所以实现预定义的东西你不关注。
2、我的主要资料来源直接来自于密码学书籍，作为原理解读，它自然要讲具体实现内部及之外的东西，而忽略标准接口。
【 在 ttl 的大作中提到: 】
: 你要用rd才有block size的问题，我们一直在说固定block size的AES，这个东西有必要提么，还是你刚知道AES是固定block size啊？
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 14:02:16 2013) 提到:
而且这个场景中的PI不是客观规律限定的，也不是真正的算法原理所限，只是一个人为预定义变量。
【 在 ttl 的大作中提到: 】
: 你这样提问就好比，我一直说圆周长与半径有关，你突然冒出一句，还有PI的因素好不好。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 14:02:43 2013) 提到:
从一开始就在说AES，你的回文一会儿AES轮数可变，一会儿又来个block size有关，说别人不看文档不学习，然后弄了半天，放出一句我说的是rd，是这个意思吧。
【 在 dhcn (小石) 的大作中提到: 】
: 你和我讨论存在并行问题：
: 1、你的知识来源可能直接来自于实现一个标准的算法库接口。所以实现预定义的东西你不关注。
: 2、我的主要资料来源直接来自于密码学书籍，作为原理解读，它自然要讲具体实现内部及之外的东西，而忽略标准接口。
: ...................
☆─────────────────────────────────────☆
shaolin (慢慢当爹路) 于 (Thu May 2 14:03:01 2013) 提到:
你俩。。。真人pk去吧。。。
【 在 ttl (小驴) 的大作中提到: 】
: 从一开始就在说AES，你的回文一会儿AES轮数可变，一会儿又来个block size有关，说别人不看文档不学习，然后弄了半天，放出一句我说的是rd，是这个意思吧。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 14:10:31 2013) 提到:
你可以往前看，我在昨天明确地提出具体的Rd算法。
【 在 ttl 的大作中提到: 】
: 从一开始就在说AES，你的回文一会儿AES轮数可变，一会儿又来个block size有关，说别人不看文档不学习，然后弄了半天，放出一句我说的是rd，是这个意思吧。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 14:10:33 2013) 提到:
啧啧，你个暴力狂~~~~~~
【 在 shaolin (慢慢当爹路) 的大作中提到: 】
: 你俩。。。真人pk去吧。。。
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 14:12:41 2013) 提到:
因为昨天参考的一本书的作者，他本人就是AES另外一个参选方案的作者，所以他对算法的讲述自然落脚点不同。
【 在 ttl 的大作中提到: 】
: 从一开始就在说AES，你的回文一会儿AES轮数可变，一会儿又来个block size有关，说别人不看文档不学习，然后弄了半天，放出一句我说的是rd，是这个意思吧。
:
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 14:15:53 2013) 提到:
和TTL的讨论基本在技术讨论范围之内，和KN的讨论完全没法讲，他的概念就是他对Session的扩展就是标准，然后所有的资料都是山寨。讲事实，他只认他的实现，摆道理，别人的道理都没有可信性。
【 在 shaolin 的大作中提到: 】
: 你俩。。。真人pk去吧。。。
:
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 14:18:17 2013) 提到:
结束这个争论吧，结论：
1. AES现在是破不了的。
2. 目前最有效率的攻击手段叫Biclique，square attack已经落后了。(其实这条也没有啥意义。。。-.-)
这个你现在总没有啥异议了吧。
【 在 dhcn (小石) 的大作中提到: 】
: 因为昨天参考的一本书的作者，他本人就是AES另外一个参选方案的作者，所以他对算法的讲述自然落脚点不同。
☆─────────────────────────────────────☆
shaolin (慢慢当爹路) 于 (Thu May 2 14:24:01 2013) 提到:
dhcn回个话，我合集。。
【 在 ttl (小驴) 的大作中提到: 】
: 结束这个争论吧，结论：
: 1. AES现在是破不了的。
: 2. 目前最有效率的攻击手段叫Biclique，square attack已经落后了。
: ...................
☆─────────────────────────────────────☆
dhcn (小石) 于 (Thu May 2 14:26:14 2013) 提到:
这个争论早该结束了，这篇帖子真正该说清楚什么问题，我昨天也已经说了。
【 在 ttl 的大作中提到: 】
: 结束这个争论吧，结论：
: 1. AES现在是破不了的。
: 2. 目前最有效率的攻击手段叫Biclique，square attack已经落后了。
: ...................
☆─────────────────────────────────────☆
ttl (小驴) 于 (Thu May 2 14:26:53 2013) 提到:
ok
【 在 dhcn (小石) 的大作中提到: 】
: 这个争论早该结束了，这篇帖子真正该说清楚什么问题，我昨天也已经说了。
修改:dhcn FROM 110.232.55.*
FROM 124.42.13.*