首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > .NET > C# >

高分征集一个加密思路,该如何处理

2012-01-10 
高分征集一个加密思路明天我还可以再加100分。给出一个理论上可行的思路即可。要求是使用现有的密码体系,使

高分征集一个加密思路
明天我还可以再加100分。

给出一个理论上可行的思路即可。

要求是使用现有的密码体系,使用一种或多种算法实现下面的问题。

一个服务器,多个用户。
用户的所有数据都加密存储在服务器上。
用户可以随意的访问、修改自己的数据。
用户可以设置自己的某些数据在某些时刻可以被某些人访问,也可以随时撤销那些访问权限。

简单点说,有点像QQ空间的权限管理。
可以随意的设置哪些人可以进来看,哪些人不能进来看。不同的是要把权限细化到哪些人可以看到哪些文件,不能看到哪些文件。

这种设计还要求即使服务器管理员拿到了存储数据,也没有办法解密数据。
(当然,用户自己必须要有自己的密钥。现在假设这些密钥始终都是安全的。)

[解决办法]
单纯的加密不是问题,用可逆加密。
[解决办法]
首先这个问题个人感觉应该分为2个问题:
1、权限分配的问题。
这个问题可以参考操作系统的用户群和权限设置进行分类和权限定义。
权限可采用用户类型和用户名结合的方法来方便用户设置。如好友群加、减个别用户名的方法快速设定。

2、加解密问题。
密匙如果是用户自己保管并且安全的话,可以采用对称加密DES进行加密和解密。由于管理员没有用户的密匙,所以不可能打开用户的数据。
存储时,先采用用户自己的密匙进行加密。访问时,先验证权限,如果通过,然后要求用户提交密匙进行解密。如果密匙和加密的文件都正确,用户应该能正常访问。
不要在服务端存储解密后的文件。加解密可以在客户端进行,这样可以有效增加数据和密匙的安全性。

如果还需要增加安全性的话,可以考虑在服务器端再进行一次对称加密,采用公匙进行加、解密。解密时需要注意加解密的次序。
一般我都采用一次客户端用户自己密匙加解密,这样速度会好点。

[解决办法]
不会。帮顶......
[解决办法]
呵呵,还要说的哪么详细吗?
你的最后一条归入第一个问题,即权限分配的问题。
再加上一个时间区间有效性判断即可,这个在网络上不是很常用吗?
撤销就是删除特定用户或者用户群的权限分配即可。限时就用增加的时间有效性来判断。
至少在路由器上经常用。你可以参考下TP Links的路由器权限分配及时间有效性指定。
Goodluck!
[解决办法]
从你现在的设想,应该是不太现实的。除非是双重安全。也就是说通过授权的用户可以访问用户数据,但是是加密过的数据。同时还必须需要用户的解密密钥。不然的话,权限的分配和设置无非是数据库,文本,配置文件等存储方式,如果不是双重安全的话,管理员很容易就通过修改数据库等方式得到权限了,那么你最后说的“这种设计还要求即使服务器管理员拿到了存储数据,也没有办法解密数据”的要求就很难成立了。
总之我认为你最后对管理员的限制实现起来需要下很大的功夫设计,因为管理员肯定是拥有Windows管理员权限的,那么你服务器上任何的设置,从理论上来说,都是可以被恶意破解的。而且即使你实现了对管理员的限制,你还要考虑到用户的密匙丢失情况,在这种高安全的级别下,是没有管理员可以帮忙恢复或找回的,你需要什么样的机制来实现密匙丢失的操作呢?

以上为个人愚见,互相探讨。
[解决办法]

探讨
且即使你实现了对管理员的限制,你还要考虑到用户的密匙丢失情况,在这种高安全的级别下,是没有管理员可以帮忙恢复或找回的,你需要什么样的机制来实现密匙丢失的操作呢?


[解决办法]

[解决办法]
权限管理就可以了,加密慎用,毕竟数据库的权限功能已经很完善了,记录内容再加密,开库操作就麻烦了,成批操作也基本不行了,总之没有必要不要这样设计。
真要这样做,去搜“不对称加密”,里面就有这种情况
[解决办法]
这里需要对称加密,比如DES,和RSA。因为数据需要原样地给解回来。像MD5、SHA之类的,就不能用了。

不过……我觉得,楼主的描述更多的是权限的要求,而不是数据加密。因为,如果你某时刻需要对某些人公开你的数据,而不是所有人的话,那么你需要与这些人分享你的密钥。这是危险的。所以……数据加密的话,你的第二点无法满足。

同时,还需要考虑效率。还有管理的方便性。除非你可以定时地允许用户更换自己的密钥,但这样的话,就必须再次通知全部的当前可共享用户资源者。但通知的过程,这是否保密呢?呵呵。但可以公开公钥进行通信,但是双方都需要各自保存自己的私钥,这样通信的双方是不好变动的,你就不能频繁地更改“好友”。加密不仅无效,反而成为了累赘。

总之,你的要求,按照目前的有效机制来说,自相矛盾……毕竟,现有的机制也是你要求的。
[解决办法]
按照楼主的意思多半是在说权限问题,如果是权限就要简单,需要在数据库里设置就可以了
[解决办法]
权限问题,楼上们都已经解决了,加密问题可以用MD5加密,可以在客户端加密后存储在服务器上。其他用户验证时,需要权限和密码。
[解决办法]
推荐使用AES加密
[解决办法]
需要密匙和KEY以及向量
[解决办法]
在我看来你这个肯定问题是数据库设计的问题,在你实现了功能之后再来考虑加密的问题,是吧?
“用户可以设置自己的某些数据在某些时刻可以被某些人访问,也可以随时撤销那些访问权限。 ”
我想到的解决方案是这样:你在设计数据库的时候有一张用户表(userid,...),一张文件表(fileid,...),你可以从这两张表中再建一张访问权限表:(fileid, userid, 访问权限,时间段),fileid, userid为主键,这样就维护不就可以实现你的功能了吗?
至于用什么加密方法,非对称和对称加密方法都可以,看你的安全级别是多少了。
------解决方案--------------------


看了楼上的回复,不知以下设计是否可行
1.密钥的保管应该可以放在密钥服务器而非存储服务器上,至少就实现了存储服务器管理员无法解密数据的要求
2.用户共享数据应该共享解密后的数据而非加密数据,这样就无需向其他用户提供自己的密钥
这样应该可以规避楼主最后一条的矛盾了
[解决办法]
楼上的说都说的很详细了。其实楼主最主要的是做好权限设计,WINDOWS的模式就很不错,可以做来参考。
至于说不想让管理员修改权限的话,可以将用户信息写在一个自定义的文件里,而这个文件是经过加密的,加解密的KEY直接写在程序里面。如果将用户信息写在数据库里的话,记得SQLSERVER是可以设置成不允许使用管理工具的,有这么个印象,记不清了。

[解决办法]

探讨
这里需要对称加密,比如DES,和RSA。因为数据需要原样地给解回来。像MD5、SHA之类的,就不能用了。

不过……我觉得,楼主的描述更多的是权限的要求,而不是数据加密。因为,如果你某时刻需要对某些人公开你的数据,而不是所有人的话,那么你需要与这些人分享你的密钥。这是危险的。所以……数据加密的话,你的第二点无法满足。

同时,还需要考虑效率。还有管理的方便性。除非你可以定时地允许用户更换自己的密钥,但这样…

[解决办法]
我也是来和大家讨论的。
第一:安全与效率本来就是矛盾的,需要选择一个中间点。
LZ目前讨论的安全问题,我们暂且以安全为主,效率为辅。
密文对于不知道密匙的人来说是不是安全?如果您认为这样都不安全的话,那我就不想说了,大家也就不用再往下讨论了。
那么既然可以假设密文对于不知道密匙的人来说是不是安全,也就是说即便是由于权限等问题出现了漏洞,不该得到密文的人得到了,但是没有密匙,是不是就不担心这种情况?如果是不用担心,那管理员或者黑客又如何,看到了,拿到了密文有用吗?
答案肯定是没有用。只有用户可以用自己的密匙在客户端解密还原出明文。
第二:用户密匙安全性问题。
LZ说过用户的密匙是安全的,所以数据的安全性是可以保障的。
至于用户密匙的保存和恢复的问题,那是另外的安全问题。
用户密匙的保存可以用第三方认证的方式存储,成本小点。如果你还要求更高的安全性,可以采用硬件加密狗存储密匙,或者在加密狗内部实现密匙的解密或者密文的解密,当然速度不高,加密狗也不建议这种用法。
如果用户密匙丢失或者忘记,可通过自己在第三方认证的申诉等重新获得密匙,这个密匙保存和恢复方面的工作比你的这个要求要多多了,建议你就只停留在使用上即可。
以上内容中,采用加密狗在客户端进行密文解密我自己做过,其他的没有实现过,只是些想法,一起和大家讨论。欢迎指正。

[解决办法]
探讨
从你现在的设想,应该是不太现实的。除非是双重安全。也就是说通过授权的用户可以访问用户数据,但是是加密过的数据。同时还必须需要用户的解密密钥。不然的话,权限的分配和设置无非是数据库,文本,配置文件等存储方式,如果不是双重安全的话,管理员很容易就通过修改数据库等方式得到权限了,那么你最后说的“这种设计还要求即使服务器管理员拿到了存储数据,也没有办法解密数据”的要求就很难成立了。
总之我认为你最后对管…

[解决办法]
此贴不错,加个精华,希望有更多的人来讨论一下
[解决办法]

[解决办法]
探讨
权限问题,楼上们都已经解决了,加密问题可以用MD5加密,可以在客户端加密后存储在服务器上。其他用户验证时,需要权限和密码。

[解决办法]
mark
[解决办法]
此贴不错,加个精华,希望有更多的人来讨论一下
[解决办法]
mark一下
[解决办法]
权限管理与加解密技术问题
[解决办法]
学习一下
[解决办法]
原有想法,.......
[解决办法]
rsa
[解决办法]

[解决办法]
普通的对称加密算法(比如DES算法),结合系统本身的权限控制即可,没必要搞什么非对称加密
[解决办法]
关注,顶。。。。
[解决办法]
文件在服务器上,用系统的密钥加密后存放。。。。。。系统的密钥谁也不知道

然后是一个权限管理系统,符合权限设定的,系统才允许某人对某文件开放或关闭给另外某人,某人才有权访问某文件

[解决办法]
关注···
[解决办法]
探讨


引用:

权限问题,楼上们都已经解决了,加密问题可以用MD5加密,可以在客户端加密后存储在服务器上。其他用户验证时,需要权限和密码。

MD5不是被破解了吗,已经不安全了阿,现在还有人在用?


[解决办法]
收藏以后用!
[解决办法]

引用楼主 aimeast 的帖子:
用户可以设置自己的某些数据在某些时刻可以被某些人访问,也可以随时撤销那些访问权限。

[解决办法]
mark
[解决办法]
下面思路是有版权的,来自csdnvip专家,如果采用,请联系我
:此地贴上,只为启发楼主。。。。
==============
原文:
请教软件产品加密方法、方式、架构、实现关键点
上海赞迪信息技术 2009-03-24 10:19
最近几天在头痛如何保护软件产品的安全,为了省钱应该也是使用软加密了,但是怎么样加密会更安全呢?
验证手段是散布在整个软件中还是另外有更好的解决方法呢?
选择哪种密钥算法比较好啊?

在用户注册的时候,序列号 + 用户硬盘号 + X验证方式 = 验证Key,那验证Key存放在哪里会比较安全呢?

各位在实现软件加密上一般都用什么方法呢?
软件加密在软件架构中存在于哪个位置会比较好呢?
在实现过程中需要注意的关键点又有哪些呢?

都不能说请教了,求教...求教.....呵呵


看看PKI(Public Key Infrastructure )"公开密钥体系"。密钥对的产生可以使用开源工具“gnupg”。加密算法可以用开源库cryptlib。

  
上海赞迪信息技术 
尚视互动 : 看看PKI(Public Key Infrastructure )"公开密钥体系"。密钥对的产生可以使用开源工具“gnupg”。加密算法可以用开源库cryptlib。
先谢!
可是,不是说这些开源库包是被研究得最多的,最容易破解的吗?

忘了说,是ASP.NET项目,开发工具定为VS2008,各位.NET方面的高人请帮忙踩两脚啊!


回复#3
尚视互动 
用户软件保存公钥,软件产商保存私钥,产商为每个用户生成一个激活码或序列号(简单实现就是随机数),软件产商为用户(序列号 + 用户硬盘号)用私钥生成签名,这样(序列号 + 用户硬盘号+签名)=(验证码),存在用户端哪都可以,只能用公钥对签名进行验证。


回复#4
尚视互动 先谢!
可是,不是说这些开源库包是被研究得最多的,最容易破解的吗?

忘了说,是ASP.NET项目,开发工具定为VS2008,各位.NET方面的高人请帮忙踩两脚啊!
最重要的是密钥对的产生和保护,PKI的安全性也就是在这,银行也是用这加密体系。开源库包只是工具使用而已,算法都是公开的。另:cryptlib支持c#/.Net。

 
原来在浪潮,一直是使用这种方式。

 
普罗通信
我自己的产品,如果需要加密,一般都是使用商业加密狗,觉得比较好。
我一般用safenet的宏狗,也不贵,开发版120,不过送个120的狗,基本上就是免费的。
嗯商用加密,我的经验,还是要使用动态时序加密,别用静态算法。在线程池等服务池里面建立弱维持机制,然后强迫使用狗计算作为池维持标准,这个时候的加密是最严厉的。由于程序流程的片段性,破解无法跟踪,也就无法破解了。


上海赞迪信息技术 
尚视互动 用户软件保存公钥,软件产商保存私钥,产商为每个用户生成一个激活码或序列号(简单实现就是随机数),软件产商为用户(序列号 + 用户硬盘号)用私钥生成签名,这样(序列号 +
是不是就相当于:
1.开发商在软件实现时:加入公钥验证
2.开发商在软件销售时:附带序列号或验证码
3.用户注册时:将序列号和硬盘号(通过网络)提交给开发商【验证用户身份】
4.开发商接收到序列号和硬盘号时:用私钥对(序列号+硬盘号)生成签名(也就是验证码)回传用户
5.用户使用软件时:软件的公钥对验证码进行验证【验证使用许可】

整个流程是否这样呢?

回复#8
尚视互动 2009-03-24 13:33
上海赞迪信息技术 项目经理 卢思奇: 是不是就相当于:
1.开发商在软件实现时:加入公钥验证
2.开发商在软件销售时:附带序列号或验证码
3.用户注册时:将序列号和硬盘号(通过网络)提交给开发商【验证用户身份
建议:
3. 为保护用户信息,通常是用户用公钥对(序列号+硬盘号的哈希值)加密后再通过网络提交给开发商【验证用户身份】
4. 开发商用私钥解出(序列号+硬盘号的哈希值):检查序列号有效性,再用私钥对(序列号+硬盘号的哈希值)生成签名(也就是验证码)回传用户;

PKI体系通常是两对密钥,数据密钥和签名密钥,以上实现是简化了其流程。
*

上海赞迪信息技术 2009-03-24 13:49
尚视互动 
3. 为保护用户信息,通常是用户用公钥对(序列号+硬盘号的哈希值)加密后再通过网络提交给开发商【验证用户身份】
4. 开发商用私钥解出(序列号+硬盘号的哈希值
非常感谢!

那实现软件的过程中,在哪层或者说哪个关键点验证许可比较好呢?

 
回复#10
尚视互动 
普罗通信: 我自己的产品,如果需要加密,一般都是使用商业加密狗,觉得比较好。
我一般用safenet的宏狗,也不贵,开发版120,不过送个120的狗,基本上就是免费的。
嗯商用加密,我的经验,还
加密狗也是一种实现方式。打个比方,加密体系是会话层,加密狗属于物理层。
如果选用对称加密体系,加密狗存储对称密钥和实现对称加密算法;
如果选用非对称加密体系,比如PKI,加密狗存储用户私钥和实现非对称加密算法;在银行办网银的密钥就是这个例子。

 

回复#11
上海赞迪信息技术
普罗通信西安有限公司 : 我自己的产品,如果需要加密,一般都是使用商业加密狗,觉得比较好。
我一般用safenet的宏狗,也不贵,开发版120,不过送个120的狗,基本上就是免费的。
嗯商用加密,我的经验,还
谢谢肖兄!肖兄的动态时序加密能够说详细些吗?

如果使用加密狗,那是可以将用户使用数都控制住了,安全也得到保障。
可客户都是不希望被限制的,这“狗”的数量上2位数的话估计会直接降低对软件的满意度(钱和“狗”的管理都是问题)

如果不是客户觉得数据相当重要的话,也不会选择加密狗。



在这里最主要是考虑如何不让我们开发的东西随随便便就被人copy去用而已。

  
回复#12
上海赞迪信息技术 2009-03-24 14:06
尚视互动 架构师 :
3. 为保护用户信息,通常是用户用公钥对(序列号+硬盘号的哈希值)加密后再通过网络提交给开发商【验证用户身份】
4. 开发商用私钥解出(序列号+硬盘号的哈希值
对了,黄兄,这密钥对的生产和保护有哪些是需要特别注意的呢?


回复#13
尚视互动 2009-03-24 14:07
上海赞迪信息技术: 非常感谢!

那实现软件的过程中,在哪层或者说哪个关键点验证许可比较好呢?
通常是启动或登陆过程验证,服务层实现;除非你要在不同核心操作间做区分,那得(验证+用户角色权限模型),应该不会有不同角色存在不同的验证码这么复杂吧?


回复#14
上海赞迪信息技术009-03-24 14:12
尚视互动 : 通常是启动或登陆过程验证,服务层实现;除非你要在不同核心操作间做区分,那得(验证+用户角色权限模型),应该不会有不同角色存在不同的验证码这么复杂吧?
呵呵,暂时的确不需要,不过既然有高人在,当然想了解深入些
^_^



回复#15
北京超鸿电脑软件开发中心 2009-03-24 15:09
购买第三方的混淆器是最标准的.NET安全防盗方式。


回复#16
上海赞迪信息技术 09-03-24 15:50
北京超鸿电脑软件开发中心 架构师 曹艳白: 购买第三方的混淆器是最标准的.NET安全防盗方式。
对了,曹兄是标准搞.NET的吧,介绍介绍用过的混淆器怎么样?

 
回复#17
北京超鸿电脑软件开发中心 2009-03-24 16:04
上海赞迪信息技术 : 对了,曹兄是标准搞.NET的吧,介绍介绍用过的混淆器怎么样?
05年用过SpDevelop,可以把私有方法混淆。不知道有没有支持最新版本.NET的。其他收费的没用过,不知道如何。现在我做的东西多数都开源了,所以不是很考虑这方面的事情,也没有什么经验。


回复#18
尚视互动 2009-03-24 16:19
上海赞迪信息技术 : 对了,黄兄,这密钥对的生产和保护有哪些是需要特别注意的呢?
密钥的产生,位数越高越安全,“gnupg”最高是256还是512,得看它的手册,以前用过的是128位;至于密钥保护,这就是人为因素了,生成的密钥对,尤其是开发商保管的私钥很重要,这不属于技术问题了,属于公司级安全问题了。对了,不用客气,叫我大黄就行了,:)



回复#19
普罗通信 2009-03-24 17:08
动态时序加密,是程序设计中融合了加密技术。
我们知道,通常的加密,都是在程序某个关键点,判断某个条件是否符合,以此作为系统停止服务的条件。
前面所述的密匙什么的,都很好,但是,只要是软件加密,就会被跟踪,对方只要跟踪出你判断点,直接跳转就好了,这让绕过去,不管多高深的加密手段,密匙算法都无效。
这里我有一个建议方法,在系统内部,有一个或者n个服务线程,专门向一个队列中输入“真”,然后所有系统内部的判断,需要求真的地方,从队列中取数字。非零的整数就是真。
只要系统一切OK,这些逻辑会运行的很好。
但一旦某个服务线程检测到狗不见了,或者其他加密条件破坏,则向队列中不定期放入“假”,系统运行就变得开始不稳定。
但由于队列是被高速读写,因此,放入的“假”会很快被取走,并被应用到程序中,相当于被消费掉了。
这样,一切都是动态的,跟踪者没有一个恒定的状态可供跟踪,中间发生假的时间,仅仅几个毫秒而已,也仅仅影响众多服务模块中的某一个,自然实现高强度加密了。
其实程序破解跟踪本身,也有很多漏洞的,并不是那么容易,很多时候,可以考虑埋暗桩,发现狗不见了,不一定要明显退出,简单申请一块内存泄露掉就好了。方法太多了。
至于密匙问题,这个在我看来,仅仅是众多判断手段之一,可用,也可以不用,狗也一样,关键的,不管采用什么判断技术,还是要程序写得够强悍,让别人无法跟踪准确的状态值。


回复#20
普罗通信 2009-03-24 17:11
嗯,补充一点,如果是C/S或B/S程序,可以考虑在Server端加狗,并提供加密计算服务,Client仅仅是将本机信息上传Server,然后Server决策是否提供服务,则所有的Client自然也就获得了高强度加密。
因为Client不管怎么破解,Server不提供服务,是解密者永远无法破解的。
这样,发货成本,和客户满意度都可控制了。

 
回复#21
VIP俱乐部 2009-03-24 17:22
这个帖子很经典!充分体现了在一个真实、真诚的技术社区中,大家互助的气氛!

回复#22
深圳元征软件 2009-03-24 17:48
“...很多时候,可以考虑埋暗桩,发现狗不见了,不一定要明显退出,简单申请一块内存泄露掉就好了...”
学习了,肖兄很有经验啊。


回复#23
上海赞迪信息技术2009-03-24 18:05
普罗通信动态时序加密,是程序设计中融合了加密技术。
我们知道,通常的加密,都是在程序某个关键点,判断某个条件是否符合,以此作为系统停止服务的条件。
前面所述的密匙什么的,都
肖兄果然是强人!学习...学习....

只是还有些疑问:
“有一个或者n个服务线程,专门向一个队列中输入‘真’”,这不也是一个关键点吗?
万一这个关键点被找到,输出值被替换为全部真的话?

是不是可以说这个关键点是散布在整个程序中,所有验证地点都可向队列插入“真”或“假”,从而造成破解这个程序会非常繁琐???

“暗桩”和“Server端加狗”这两种解决方法的确非常好!
大黄(我就不客气了,嘿嘿...)在基础理论上的指点和肖兄实践经验的指点真的对我很有帮助,多谢指点!

*
大连恒基电子

回复#24
大连恒基电子2009-03-24 19:08
我们一直是服务器端用加密狗。客户端在弄点软加密什么的。

*
北京亿民网软件技术公司 

回复#25
北京亿民网软件技术公司 
国内以前有个“看雪论坛”,专门讨论加密的,里面有高手(还出过一本书),不知道在不在了。

*
上海赞迪信息技术 

回复#26
上海赞迪信息技术009-03-24 20:21
大连恒基电子 : 我们一直是服务器端用加密狗。客户端在弄点软加密什么的。
庞兄实现过?能不能详细说下怎么做的呢?

*
上海赞迪信息技术 

回复#27
上海赞迪信息技术 09-03-24 20:22
北京亿民网软件技术公司 : 国内以前有个“看雪论坛”,专门讨论加密的,里面有高手(还出过一本书),不知道在不在了。
看雪论坛还在,我先进去探探路,呵呵....谢啦!

*
南京铭图软件科技有限公司

回复#28
南京铭图软件科技有限公司 2009-03-24 21:10
嗯,在这里学了不少东西。


*
普罗通信

回复#29
普罗通信 2009-03-24 22:19
C语言里面有inline,C++有类声明处直接写函数实体,实际上都是内联编译,即这段代码被放到执行处,而不是函数跳转。
前面说的放“真”的算法,实际上是一个内联的GetNotZero函数,在程序中可以多次调用,调用时,在队列中消费掉一个非0随机数,则补回一个非0,就这么简单一个逻辑。
而这个队列可以设置为关键计算队列,废弃随机数函数,从该队列中直接取值,跟踪者如果废弃这个队列,则所有随机数计算随之消失。
然后,每个While(1)写成while(GetNotZero)试试看。
遍地都是算法,呵呵,不太好跟的。

*
香港开放科技(深圳)公司 

编辑 删除 #30
香港开放科技(深圳)25 10:07
普罗通信西安有限公司 : 我自己的产品,如果需要加密,一般都是使用商业加密狗,觉得比较好。
我一般用safenet的宏狗,也不贵,开发版120,不过送个120的狗,基本上就是免费的。
嗯商用加密,我的经验,还
我支持肖先生的见解

*
橙天华音 

回复#31
橙天华音 2009-03-27 18:10
学习

*
徐州海派科

回复#32
徐州海派 2009-03-31 09:13
使用硬加密的非技术因素:我们大部分客户还在使用加密狗,不使用软加密的主要原因是客户感觉软加密不实在,宁愿多花钱就是要硬件加密狗,不然不放心,还有就是软加密不能随时随地更换电脑使用软件,必须先注册软加密KEY。
[解决办法]
顶了
[解决办法]
好贴
[解决办法]
PKI/PMI
[解决办法]
学习
[解决办法]
来学习一下
[解决办法]
up
[解决办法]
学习了。帮顶。
[解决办法]

探讨
引用:

首先这个问题个人感觉应该分为2个问题:
1、权限分配的问题。
这个问题可以参考操作系统的用户群和权限设置进行分类和权限定义。
权限可采用用户类型和用户名结合的方法来方便用户设置。如好友群加、减个别用户名的方法快速设定。

2、加解密问题。
密匙如果是用户自己保管并且安全的话,可以采用对称加密DES进行加密和解密。由于管理员没有用户的密匙,所以不可能打开用户的数据。
存储时,先…

这样不能满足我的需求。不能满足最后一条:
用户可以设置自己的某些数据在某些时刻可以被某些人访问,也可以随时撤销那些访问权限。

[解决办法]
帖子很热闹,我用不同的颜色吧:)

楼主这个题目比银行的系统还要复杂。
银行系统的账户子能自己查看,楼主的系统在要满足安全性的条件下,让别人可以查看。啥东西这么重视安全?

这里我给楼主简单介绍一下银行系统的密码是怎么存放的:
银行系统的用户的密码并不存放在数据库系统中,存放在数据库系统的是用户真正的密码(PIN),经过DES(或TripleDES)加密后得到的偏移量(行话叫PIN Offset),由PIN Offset是基本不可能反推出PIN的(这说明DES或TripleDES加密函数没有或者很难找到反函数),这样就保证了PIN的安全。PIN被用户记在大脑里或者他自己认为安全的地方,需要验证时,用户提交自己的PIN给系统,系统用DES或TripleDES算法对密码进行加密运算,得到PIN Offset',然后系统查看数据库中的PIN Offset和刚计算出来的PIN Offset'是否相同,如果相同,则说明登录成功,否则失败。

因此,DES/TripleDES可以用来验证用户的密码是否正确,每次用户登录系统都会运算一次DES或者TripleDES。采用上述方式,即便是数据库系统管理员,也不可能知道用户的真正密码。

如果一个用户不慎丢失了密码,系统管理管理员可以为用户重置一个新的密码,然后通知用户修改密码,修改密码的时候系统会重新计算PIN Offset,并将PIN Offset保存在数据库中。

以上就是实际应用中的银行系统,对用户PIN是怎么处理的过程。

至于楼主提到的文件之类的加密,建议慎用,理论上可以做到你的要求,但实际中很少有系统是这么做的(兄弟不了解楼主系统的应用场景),而且实现起来将会超级复杂(相对银行的核心系统而言,比电子证书的机制应该还要复杂一个数量级,因为电子证书的主要作用就是让客户端和服务器端以非对称的方式,协商出一个sessionKey,然后数据是通过这个sessionKey用对称加密的方式加密数据,并传输的,之所以这么做,是因为非对称的加解密方式很耗时),因此,建议楼主完善权限管理系统就可以了。如果想防止数据在传输过程中的被窃或者被监听,这时候就可以采用电子证书的方式以确保安全。

最后,我想表达的是,安全是一个相对的概念,绝对的安全是没有的。就像上面说到的,银行账户里面的数据并没有加密,数据库管理员可以随意修改一个账户的余额(尽管他不知道该用户的真正PIN),这些从安全的本质上来说都是漏洞,诸如此类的漏洞,从纯技术的观点来说,很难或者不可能堵住,而是需要辅之以相应的法律、法规和操作流程。毕竟我们必须要事先相信一些人,当然如果这些人出了问题,我们要有对应措施予以惩处,以警他人。
[解决办法]
[Quote 引用: ]


首先这个问题个人感觉应该分为2个问题: 
1、权限分配的问题。 
这个问题可以参考操作系统的用户群和权限设置进行分类和权限定义。 
权限可采用用户类型和用户名结合的方法来方便用户设置。如好友群加、减个别用户名的方法快速设定。 

2、加解密问题。 
密匙如果是用户自己保管并且安全的话,可以采用对称加密DES进行加密和解密。由于管理员没有用户的密匙,所…
[/Quote]
[解决办法]
ss
------解决方案--------------------


我先总结一下楼主的要求:
1、用户的数据都是保存在服务器端的,并且是加密的。
2、用户保存了自己加密数据的密钥。
3、用户可以选择性地发布自己的数据。
4、服务器管理员不能操作用户的数据。

也就是说,用户具有管理员的部分功能。现在的难点就在于客户如何自己发布数据有能绕过服务器管理员,不让服务器管理员获取自己的密钥。因此,我提供以下思路:
1、用户数据的密钥肯定不能放在服务器端,只能保存在用户端。
2、用户在发布自己的数据给特定客户时,应该在服务器里设置一下,就是在客户需要访问用户数据时,服务器应该请求用户的密钥(注意:这个密钥不能在服务器端保存下来。),将解密后的数据发布给特定客户。

同过以上分析,对用户端的应该有以下需求:
用户端应该具有密钥服务器的功能,就是在自己的客户需要浏览自己的数据时,用户端需要向服务器提供密钥。

简单流程如下:
客户请求浏览数据《=》服务器器请求用户提供密钥《=》用户提供密钥
[解决办法]
可以考虑比较大众的对称加密。
[解决办法]

探讨
这里需要对称加密,比如DES,和RSA。因为数据需要原样地给解回来。像MD5、SHA之类的,就不能用了。

不过……我觉得,楼主的描述更多的是权限的要求,而不是数据加密。因为,如果你某时刻需要对某些人公开你的数据,而不是所有人的话,那么你需要与这些人分享你的密钥。这是危险的。所以……数据加密的话,你的第二点无法满足。

同时,还需要考虑效率。还有管理的方便性。除非你可以定时地允许用户更换自己的密钥,但这样…

[解决办法]
学习学习
[解决办法]
1.sql连接字符串与数据库的所有数据都需要加密保存
2.密码不能存放在服务器端(因为网站源代码很可能被反编译),需要由你远程输入启动网站(网络上传输入的密码也应该是加密码过后的,密码最好是通过时间或其它规则变换,如每分种都不同,客户端通过程序生成这个密码).
其实,就算是这样也不可能从根本上防止服务器管理员的攻击行为,他同样可以从内存中扫描到密码
[解决办法]
可逆加密 加密数据
不可逆加密 加密可逆加密的密钥
[解决办法]
还有,如果服务器管理员伪造服务器端,也没有办法解决...
说到底,技术能力强的服务器管理员是没法防的,主要是看他的技术能力有多强.
[解决办法]
抛开加密防管理员攻击不说,这个就只剩下一个很简单的权限管理功能了.
[解决办法]
加密算法很贵的,一般C#都用System.Security.Cryptography;这个吧,至于权限你得好好想想了。
火鸟软件竭诚为您服务
[解决办法]
如此苛刻的要求,不知lz用在什么地方?
这些要求本身似乎很矛盾,lz还是写明应用环境吧,也许有变通的方法也不一定!
[解决办法]
学习了,加密!应该很有意思的东西吧
[解决办法]
ding顶
[解决办法]
来看看学习学习的!

[解决办法]
对于LZ提出来的问题,建议LZ去研究一下目前的云计算的加密解决办法,跟你提的问题很像!
[解决办法]
学习学习
[解决办法]
这个贴子讨论的不错!
50楼pathuang68的帖子很不错,是结合实际的实例。
建议LZ先分析下您的硬件环境和应用范围,用户群,看看效率、安全、成本之间的平衡。
41楼的回复中有很多是很有创意的,值得学习。

[解决办法]
很棒
[解决办法]
谈谈看法:
目前关键是解决数据的定向定时发布问题:
假设:
A 用户的数据是经过加密的,如果没有密钥任何人是不能查看数据的。
所有的用户都具有非对称加密公私密钥体系。
[color=#0000FF]
那么如果需要给B用户看数据,那就要将密钥传给B用户,怎么传给B用户呢,总不能问A要吧,A只是个客户端,不具备任何功能。

因此,我们需要将密码传给B用户,很简单,采用公私密钥体系就行了,用户A在设定B用户有权限查看谋篇文章的时候,只要将文章的名字和加密密钥通过B用户的公钥进行加密存放在数据库中,只有B通过自己的私钥才能解开这些信息获取文章的名称和文章密钥。

那么文章的加密密钥是怎么生成的呢,这个由系统自动随机生成,然后通过A用户的公开密钥加密后存放在数据库中。

如果发现某个用户的阅读时限过了,系统就自动重新生成随机密钥,并自动用各用户的公钥加密密钥存储在数据库中。
已经过期的用户就不再生成对应的数据,改用户自然也就不然获得阅读权限。

这样就解决了密钥的传递问题。

1、A用户新文章
A用户新的文章明文 ---》系统自动生成随机密码,并用该密码加密文章,并存储文章的密文--》用用户A的公钥加密该文章的密码,将密码密文存放在数据库中。

2、A用户自己读文章
获取该文章用用户A公钥加密的密码密文-->用用户A私钥进行解密,获得文章的加密密码--》获取文章的密文--》用文章的密码对文章进行解密--》文章的明文。

3、A用户授权B用户读取文章3个月
获取该文章用用户A公钥加密的密码密文-->用用户A私钥进行解密,获得文章的加密密码--》用用户B的公钥加密该文章的密码,将密码密文存放在数据库中。



4、用户B阅读该文章
获取该文章用用户B公钥加密的密码密文-->用用户A私钥进行解密,获得文章的加密密码--》获取文章的密文--》用文章的密码对文章进行解密--》文章的明文。

5、过期
删除对应的密码密文就可。[/color]

[解决办法]
[size=18px]接70楼

为了防止服务器内存窃取和传输线路窃取,建议在客户端完成加解密工作。

1、用户的公钥是存放在服务器上的

2、服务器上存放的都是密文

3、用户的私钥是存放在客户端的

4、所有的传输都是获取密文,然后在客户端通过私钥进行加密和解密。[/size]



[解决办法]

引用楼主 aimeast 的帖子:
要求是使用现有的密码体系,使用一种或多种算法实现下面的问题。

一个服务器,多个用户。
用户的所有数据都加密存储在服务器上。
用户可以随意的访问、修改自己的数据。
用户可以设置自己的某些数据在某些时刻可以被某些人访问,也可以随时撤销那些访问权限。

[解决办法]
不错啊!
[解决办法]
引用楼主 aimeast 的帖子:
简单点说,有点像QQ空间的权限管理。

[解决办法]
学习ing

[解决办法]
4 安全:要防止管理员在服务器端用窃听软件截取数据,要把生成DES密码、加密数据,用组公钥加密DES密码的过程放在客户端。

5 组管理:组要能让普通用户随意创建和删除(仅限于删除自己创建的组)。组创建时必须制指定成员,创建后不能修改。创建组时是在客户端生成RSA密钥对,组的私钥要用每个组员的公钥加密一次分别储存,这样才能让组员用自己的私钥获取组私钥,同时让管理员无法获得组私钥。
[解决办法]
1、权限分配的问题。 
我觉得如果可以 ,可以仿造SQL 或者 VISTA的权限分配。不过一定可以解决楼主的问题。

2、加解密问题。 
其实我觉得MD5就OK ,因为MD5是不可逆向的,
个人感觉所有可以逆的加密方式,如果找到逆向方法,或者KEY,都会查到全部密码。
但是MD5不可加密,所以安全性高很多。
可能有很多人说网上MD5码破解网站,软件很多,但是我们可以先修改我们所要加密的字符串。

例如
密码为123 
我可以改为 #_1*2*3_#
如果那个网站可以吧这个MD5码破解出来那是牛人。
但是我们写一个把123 改为#_1*2*3_#
的程序却很简单。(PS:就连菜鸟级的我都可以,楼主不要说不会哦。)
我们可以给不同的用户 更改字符串 的方式不同,
这样哪怕拿到MD5密码也不行。

最后,SQL可以为数据加密,可以吧MD5作为密码来加密就OK了,
本人菜鸟一个,如有错误的地方请指出,谢谢。!!!!
[解决办法]
探讨
权限问题,楼上们都已经解决了,加密问题可以用MD5加密,可以在客户端加密后存储在服务器上。其他用户验证时,需要权限和密码。

[解决办法]
来学习一下了。
[解决办法]
帮顶一个 做个标记后面再看
[解决办法]
多重加密,得到的某一次结果的密文是有意义的东西,让破密者误认为得逞了
[解决办法]
探讨
4 安全:要防止管理员在服务器端用窃听软件截取数据,要把生成DES密码、加密数据,用组公钥加密DES密码的过程放在客户端。

5 组管理:组要能让普通用户随意创建和删除(仅限于删除自己创建的组)。组创建时必须制指定成员,创建后不能修改。创建组时是在客户端生成RSA密钥对,组的私钥要用每个组员的公钥加密一次分别储存,这样才能让组员用自己的私钥获取组私钥,同时让管理员无法获得组私钥。

[解决办法]
太麻烦了吧
[解决办法]
OA数字证书,安全性最高
[解决办法]
学习@帮顶下!
[解决办法]
权限分配问题........
[解决办法]
继续关注中。。。。。。
[解决办法]
看来我来玩了,不知道能不能领点分数。
[解决办法]
弄个证书服务器 根据用户的权限分配证书
[解决办法]


我觉得权限同功能最好分开。
如一个权限只有查看功能
一个权限又能查看,又能编辑。
将可能涉及到的功能都同权限结合。设计比较麻烦。但是功能很强大。
继续留名。看帖
[解决办法]
单向散列算法
[解决办法]

探讨
谈谈看法: 
目前关键是解决数据的定向定时发布问题: 
假设: 
A 用户的数据是经过加密的,如果没有密钥任何人是不能查看数据的。 
所有的用户都具有非对称加密公私密钥体系。 
[color=#0000FF] 
那么如果需要给B用户看数据,那就要将密钥传给B用户,怎么传给B用户呢,总不能问A要吧,A只是个客户端,不具备任何功能。 

因此,我们需要将密码传给B用户,很简单,采用公私密钥体系就行了,用户A在设定B用户有权限查看谋…

[解决办法]
服务器管理员即使拿到了B用户的公匙也无所谓,没有B用户的私匙,也打不开B用户的文件和A用户共享给B用户的加密文件。

[解决办法]
探讨
引用:
谈谈看法: 
目前关键是解决数据的定向定时发布问题: 
假设: 
A 用户的数据是经过加密的,如果没有密钥任何人是不能查看数据的。 
所有的用户都具有非对称加密公私密钥体系。 
[color=#0000FF] 
那么如果需要给B用户看数据,那就要将密钥传给B用户,怎么传给B用户呢,总不能问A要吧,A只是个客户端,不具备任何功能。 

因此,我们需要将密码传给B用户,很简单,采用公私密钥体系就行了,用…

[解决办法]
好想法
[解决办法]
Herb2的思路正好能解决你的问题

[解决办法]
严重关注。

热点排行