开发者社区> 问答> 正文

请问这种C/S加密思路有什么问题吗?:报错

大体思路就是,想把服务端与客户的通信加密,但是不用HTTPS,  比如: 用户提交访问: http://localhost/login.jsp?name="ABC"&pass="ABC",  假设这个ABC 是用SHA-256,MD5等等 算出来的一长串ASCII 字符,服务器拿到这一长串的字符做客服端相应解密,  前提是,服务端与客服端用的是同一种加解密方式(C->encoder("明文")-->密文--->decoder("密文")--->S(明文) ), 同样的服务器反馈回来的字符也是按上述方式一样是加密的字串,客服端必须相应解密才能变成明文. 请问大家这种 不用SSL 的方式可行吗?我用的服务器是,tomcat 8 + Servlet, 请各位指教

展开
收起
kun坤 2020-06-14 09:57:46 573 0
1 条回答
写回答
取消 提交回答
  • 主要看你的用途了,B/S项目加密也没有用。密文用户是看不到的,并且你的加密算法也是明文的。如果仅仅是不想在url中显示这些信息,可以采用post方式进行提交。或者考虑SSO方案。######我现在只是想要验证这种方式的可行性,SSO在后面可能会考, 我只是用这种方式做一个简单,认证->下载服务器,只是不想用HTTPS, 且提交参数不是的明文的,两端的加解密方式只有开发者知道. 客服务端的加密是通过SDK包装发出去.######请大家指导一下方向与思路.######我发现在这个思路有问题, 加密HTTPS是少不了的.
    ######如果是向服器单向传送是可以的。但应该用rsa非对称加密。如果是双向的,还不如用https 简单。######

    引用来自“lirenqing2000”的评论

    主要看你的用途了,B/S项目加密也没有用。密文用户是看不到的,并且你的加密算法也是明文的。如果仅仅是不想在url中显示这些信息,可以采用post方式进行提交。或者考虑SSO方案。
    这个方案在一些支付网站和开放平台就是这样做的,使用了动态密码、token等技术。可以研究下淘宝、拍拍、支付宝或者paypal等API,这些对你会有帮助。加密和解密模块可以在提交请求和接收请求数据的时候处理。以前采用Rest方式,在项目中使用过。可以采用AES、DES等对称加密算法。增加加密和解密模块对性能有一些影响,这个需要考虑。
    2020-06-14 09:57:50
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
基于可信计算与加密计算 打造云上原生计算安全 立即下载
\"视频服务特色解决方案——直播连麦与点播加密 \" 立即下载
量子加密通信技术 立即下载