防止恶意登录的设计思路

关于上一篇《关于加密解密设计思路》提到的动态密钥,加密解密的设计思路来保证每次password。key这类重要信息每次请求都发生变化,可是我用抓包工具截获get,post请求时,假设我password动态加密完,是keyjafjalewei78732可是我假设没对这个内容做有效期校验。还是照样能够登录系统,进行恶意破坏。

因为我们常常实现这样的,都是在一个类似单点登录的跨服务的web系统上,比方A系统发送post请求登录B系统。我们能够做两套安全方案:

一,我们的密钥每天变换一次。加密好的密文还掺杂有密钥随机数和分钟数,接收方能够依据约定好的规则进行解密。解密完能够得知请求是在一分钟内,或者5分钟内的请求key,有人会认为5分钟太长了吧。可是实际场景中Aserver,Bserver的时间不一定同步,有时还差不止5分钟。这样有人就会问了。刚才keyjafjalewei78732这个东西不是在5分钟内,我能够任意地登录破坏。二。这时我们能够把keyjafjalewei78732放入缓存中。能够设置缓存有效期是20分钟,这样有人恶意发送keyjafjalewei78732,我缓存有这个东西了,照样没法登录。尽管缓存serverkill后会失效,可是我排除故障,启动server的时间应该不止5分钟吧。

所以还是比較安全的,能够有效控制恶意登录。

时间: 2024-08-25 20:52:20

防止恶意登录的设计思路的相关文章

主流移动端账号登录方式的原理及设计思路

哈尔滨SEO: 1.引言 在即时通讯网经常能看到各种高大上的高并发.分布式.高性能架构设计方面的文章,平时大家参加的众多开发者大会,主题也都是各种高大上的话题——什么5G啦.AI人工智能啦.什么阿里双11分分钟多少万QPS高并发等等. 但实际上,对于普通的开发者(包括IM开发人员)来说,多数公司.多数团队也都是干着默默无闻.平淡无奇的产品开发,并没有那么多高并发.高大上的事情可以做. 就拿一个IM系统来说,无论你的架构设计考虑了多少分布式.高吞吐.高可用,所有这些事情只要落地,那编码的第一件事情

如何写出安全的API接口?接口参数加密签名设计思路

开发中经常用到接口,尤其是在面向服务的soa架构中,数据交互全是用的接口. 几年以前我认为,我写个接口,不向任何人告知我的接口地址,我的接口就是安全的,现在回想真是too young,too simple.但凡部署在广域网的应用程序,随随便便的好多工具可以根据ip或域名扫描应用程序的所有暴露的接口,进而分析参数,注入程序,分分钟被攻击. 那咋才能保证接口的安全性呢? (一)面临的主要安全问题 a.网络环境假设: a1.假设公共网络(Internet,如:WIFI.非家庭网络.非办公网络等) 是不

React Native状态机和应用设计思路

在原生Android开发中:当用户点击"登录"按钮时,从用户名输入框中读取用户输入的用户名,从密码输入框中读取用户输入的密码,然后交给注册模块去处理.但是,React Native不是这样的思维. 一.状态机 1.1 状态机思维 React框架将所有的UI视为一个简单的状态机,那么任意一个UI场景就是状态机的一种状态.根据决定状态的状态机变量的值,React框架渲染状态机的当前状态--对于开发者来说,单个UI场景就被渲染出来了.随着状态机变量值的改变,UI状态机也在不停地改变状态,UI

[转载] 站内消息DB设计思路

[转载]:点击打开链接  原文标题:两年后,再议“站内信”的实现  注:仅因为在工作中用到相似的东西,故借鉴作者的文章,如有不便请告知,即刻删除 两年前,万仓一黍在博客园发了两篇关于站内信的设计实现博文,<群发“站内信”的实现>.<群发“站内信”的实现(续)>,其中阐述了他关于站内信群发的设计思想,很具有借鉴意义.他在设计时考虑到用户量和存储空间的占用等问题.当然,在他的两篇博文中强调了站内信的设计要考虑具体情况,没有理想的设计方案,他的设计只是对于群发(点到面)的解决方案. 在此

跟张小龙学习做优秀产品经理的设计思路

提起张小龙,大家都非常熟悉这位极度优秀的产品经理,不仅仅是因为Foxmail,更因为目前深刻改变你我移动生活的移动互联网产品 - 微信,其江湖地位的确定已经让众多国内立志于做优秀产品经理的人顶礼膜拜了,我们首先借助互联网材料回顾一下微信的创立历程: 一.微信的演化历程: 2010年11月19日23时58分,张小龙在腾讯微博上写下了这么一句话: 我对iPhone5的唯一期待是,像iPad(3G)一样,不支持电话功能.这样,我少了电话费,但你可以用kik跟我短信,用googlevoice跟我通话,用

(转)OAuth 2.0的设计思路

OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版. 本文对OAuth 2.0的设计思路和运行流程,做一个简明通俗的解释,主要参考材料为RFC 6749. 原文地址:http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html 一.应用场景 为了理解OAuth的适用场合,让我举一个假设的例子. 有一个"云冲印"的网站,可以将用户储存在Google的照片,冲印出来.用户为了使用该服

TYPESDK手游聚合SDK客户端设计思路与架构之二:安卓平台统一化接口结构及思路

在上一篇<TypeSDK聚合sdk设计基本原则>中我们提到了,设计聚合sdk需要设计开发平台部分的接口,以及设计发布平台的聚合这2个大模块.那么我们今天就先来讲讲发布平台之一:安卓平台的统一化接口结构和思路. 一.相关的需求 安卓平台的统一化接口,我们需要考虑到具体以下的几点: 1.对外需要有统一的接口,保证不同的渠道sdk 对同一个游戏来说,是调用相同的接口,传递相同的参数 2.对内需要有一套扩展性很好的框架,可以应对不同渠道的sdk差异性 二.设计的模块 那么针对这些考虑点,安卓平台的统一

TYPESDK手游聚合SDK服务端设计思路与架构之一:应用场景分析

TYPESDK 服务端设计思路与架构之一:应用场景分析 作为一个渠道SDK统一接入框架,TYPESDK从一开始,所面对的需求场景就是多款游戏,通过一个统一的SDK服务端,能够同时接入几十个甚至几百个各种渠道的SDK.而且这些渠道接口的具体接入字段和接入逻辑,每个月以至每周,都可能发生或大或小的变动.在这样一个复杂的应用场景下,我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢? 首先我们需要厘清,在整个应用场景中,TYPESDK所处的位置,以及它所需要实现的核心功能. 图1 如图1所示,T

Hybrid APP架构设计思路

原文:Hybrid APP架构设计思路 关于Hybrid模式开发app的好处,网络上已有很多文章阐述了,这里不展开. 本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考. 通讯 作为一种跨语言开发模式,通讯层是Hybrid架构首先应该考虑和设计的,往后所有的逻辑都是基于通讯层展开. Native(以Android为例)和H5通讯,基本原理: Android调用H5:通过webview类的loadUrl方法可以直接执行js代码,类似浏览器地址栏输入一段js一样的效果 webvie