Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >在线、离线激活鉴权实战

在线、离线激活鉴权实战

原创
作者头像
Ewdager
修改于 2020-09-23 02:15:17
修改于 2020-09-23 02:15:17
2.7K0
举报
文章被收录于专栏:Gvoidy备份小站Gvoidy备份小站

任务目标

实现一个客户端通过给与的指定激活码,激活仅限当前机器使用具体软件的功能。客户端可能处于能连接互联网无法连接互联网两种情况。同时均要实现在指定时间使权限过期的功能,激活码在使用时才开始计时。

在线激活模式

这个就非常简单了,使用最简单的哈希加盐就可以实现了,与正常 REST 接口的哈希加盐验证只有,验证服务器端需要预先存好设置的激活码这一步。

激活码有效期就通过一个取巧的方法,将有效期的秒数转换成16进制,埋藏在序列号的指定段上。

在将当前时间和过期时间一起加盐,实现用户无法通过修改或锁定系统时间破解我们的系统。

当然,激活后,也要每隔一段时间验证一下是否过期,并且同时更新验证的时间戳,防止用户修改或锁定系统时间。

可以将鉴权放在请求前检验登录情况的装饰器里,每次更新只更新到flush里,在其他操作commit的时候再更新到数据库,防止一个请求里多个commit会导致数据无法回滚。

比较有风险的一点就是,用户可能会抓包服务端发到客户端的鉴权结果请求,然后伪造成功信息实现越过真实的鉴权结果,所以我们要设置一些比较特殊的字符串成功信息的字符串。或者可以实现类似银行电子狗,客户端-服务端均会随时间产生的相同动态加密校验码,与成功或失败信息加密后,再返回给客户端,保证中间过程即时被抓包,也无法破解。以下伪代码不考虑此过程

代码语言:txt
AI代码解释
复制
# 激活部分client伪代码

def online_active():
	# 前端传递激活码
	serial_number = form.serial_number.data

	# 获取本机硬件信息
	device_info = get_device_info()

	# 盐
	secret = config.secret

	# 记录激活码过期时间

	expire_time = int(serial_number[6:], 16) * (60 * 60 * 24)
	expire_timestamp = now_timestamp + expire_time

	# 硬件信息加盐生成的指纹
	signature = md5(device_info, expire_timestamp, now_timestamp, secret)

	# 向激活服务器发起验证请求
	if verify_license(serial_number, device_info, expire_timestamp, now_timestamp, signature):

		# 写入数据库
		insert_active()
		return True
	else:
		return False
代码语言:txt
AI代码解释
复制
# 激活部分server伪代码

def verify_license(serial_number, device_info, expire_timestamp, now_timestamp, signature):

	# 验证是否存在对应的激活码
	if serial_number in db:
		# 与客户端一致,只要验证指纹是否一致就行了
		if signature == md5(device_info, expire_timestamp, now_timestamp, secret):
			return True

	return False
代码语言:txt
AI代码解释
复制
# 客户端检测权限是否仍然有效
def is_active():
	# 验证激活设备是否改变,同时验证了激活时间是否被篡改

	timestamp_or_false = is_active_equipment()

	if not expire_timestamp_or_false:
		return False

	# 获取下面每次鉴权写入数据库的时间last_timestamp,防止用户篡改系统时间,躲避过期机制
	expire_timestamp, last_timestamp = expire_timestamp_or_false

	# 是否因为超过过期时间而过期
	if now_time > expire_timestamp:
		return False

	# now_time 为当前系统时间
	# 防止用户锁定时间
	if last_timestamp >= now_time:
		return False

	# 更新数据库中的now_timestamp并重新生成指纹
	now_timestamp = now_time
	signature = md5(something)

	# 写入数据库
	insert_active()
	return True



# 客户端检测是否设备是否改变

def is_active_equipment():
	# 其实就是重复哈希加盐鉴权的过程,只不过是将验证客户端指纹、验证服务器指纹改为了,
	# 客户端指纹、客户端数据库指纹鉴权了

	db_signature, serial_number, expire_timestamp, now_timestamp = get_db_signature()

	# 获取本机硬件信息
	device_info = get_device_info()

	# 盐
	secret = config.secret

	# 硬件信息加盐生成的指纹
	signature = md5(device_info, expire_timestamp, now_timestamp, secret)

	if signature == db_signature:
		return expire_timestamp, now_timestamp
	return False

离线激活模式

这里逻辑就比较恶心,但是还是类似上面在线激活的思想。只不过从客户端-激活服务器改为了客户端-手机-激活服务器

客户端-手机这一部分通过扫描二维码,自动跳转网址,给激活服务器发起请求实现。

具体流程(非常绕!)就是,在客户端输入激活码,客户端生成一个携带设备等校验信息的二维码和一个用于校验的校验码,返回给前端的只有二维码,用户扫描二维码向激活服务器发起校验,如果校验成功,则生成一个和客户端一样的校验码返回到用户手机上,用户将该校验码再次输到客户端里。客户端自己生成的校验码和用户输入的校验码一致,则激活成功。如果校验失败,那向用户手机直接发送失败信息。

需要保证每次不同终端客户端-手机-服务端服务端-手机-客户端生成的校验码签名均是计算出来的,而不能存起来。

过期部分还是同在线激活方式相同,以下伪代码不做赘述。

与在线激活方式遇到的中间人攻击类似,这种方式最好在客户端-手机手机-服务器这两个过程中加密信息,但是这篇文章讨论的是两种激活模式的业务逻辑实现,不涉及具体实现。

代码语言:txt
AI代码解释
复制
# 客户端输入激活码,使用请求地址和参数生成二维码

def generate_qr_code():
	# 前端传递激活码
	serial_number = form.serial_number.data

	# 获取本机硬件信息
	device_info = get_device_info()

	# 盐
	secret = config.secret

	# 记录激活码过期时间

	expire_time = int(serial_number[6:], 16) * (60 * 60 * 24)
	expire_timestamp = now_timestamp + expire_time

	# 硬件信息加盐生成的指纹
	signature = md5(device_info, expire_timestamp, now_timestamp, secret)

	# 生成校验码
	pin_code = someting_Encrypt()

	# 激活服务器的激活接口
	request_url = "aaa.com/bbbb"

	return request_url, 上面的相关信息
代码语言:txt
AI代码解释
复制
# 用户手机向验证服务器发起请求,返回pin_code

def offline_active():
	# 鉴权,与在线激活同样
	verify_license()

	# 生成校验码
	pin_code = someting_Encrypt()

	return pin_code
代码语言:txt
AI代码解释
复制
# 客户端验证pin_code

def verify_pin():
	# 获取前端发送过来的pin_code
	pin_code = form.pin_code.data

	# 生成校验码
	if pin_code == someting_Encrypt():
		return True
	return False

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
基于Flask开发企业级REST API应用(二)
本节开始项目的编码实现。首先我们来实现登录注册模块的相关 API。本项目我们是使用前后端分离的模式,在实现登录注册功能之前,假设我们的接口是开放的,那么需要确定接口校验方案。
阳仔
2019/08/06
9760
【玩转腾讯云】万物皆可Serverless之借助微信公众号简单管理用户激活码
就可以添加并回复一个指定有效期的会员激活码,实现了在微信公众号简单管理用户激活码的需求
乂乂又又
2020/04/22
1.5K0
【玩转腾讯云】万物皆可Serverless之借助微信公众号简单管理用户激活码
鉴权实战 - Koa
Bearer token 组成:Header、payload(载荷)、Signature(签名) Header.Payload.Signature
Cellinlab
2023/05/17
4630
前端需知道的常见登录鉴权方案
说起鉴权大家应该都很熟悉,不过作为前端开发来讲,鉴权的流程大头都在后端小哥那边,本文的目的就是为了让大家了解一下常见的鉴权的方式和原理。
coder_koala
2020/11/10
2.8K0
前端需知道的常见登录鉴权方案
三方接口调用设计方案
为保障三方接口的安全性,可采取多方面措施,包括使用 HTTPS 协议确保数据传输安全,利用 AK 和签名进行身份验证以及对请求验签来防止非法请求与重放攻击,还有对敏感数据进行加密传输等。不过具体实现细节会因项目需求而存在差异,并且在实际开发中,还需兼顾错误处理、异常情况处理以及日志记录等方面内容。
用户1142828
2024/12/08
1870
微服务架构下的安全认证与鉴权
本文目录: 一、单体应用 VS 微服务 二、微服务常见安全认证方案 三、JWT介绍 四、OAuth 2.0 介绍 五、思考总结 从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化,身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的鉴权方案?本文将会为大家阐述微服务架构下的安全认证与鉴权方案。 一、单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下
yuanyi928
2018/03/30
3.7K0
微服务架构下的安全认证与鉴权
使用python实现后台系统的JWT认证
專 欄 ❈ 茶客furu声,Python中文社区专栏作者 博客: http://www.jianshu.com/p/537b356d34c9 ❈ 今天的文章介绍一种适用于restful+json的API认证方法,这个方法是基于jwt,并且加入了一些从oauth2.0借鉴的改良。 1. 常见的几种实现认证的方法 首先要明白,认证和鉴权是不同的。认证是判定用户的合法性,鉴权是判定用户的权限级别是否可执行后续操作。这里所讲的仅含认证。认证有几种方法: 1.1 basic auth
Python中文社区
2018/01/31
3.2K0
一口气说出前后端 10 种鉴权方案~
在介绍鉴权方法之前,我们先要了解的是:什么是认证、授权、鉴权、权限控制以及他们之间的关系,有了他们做铺垫,那么我们才能做到从始至终的了解透彻 ~
终码一生
2022/10/28
7.3K1
一口气说出前后端 10 种鉴权方案~
【Node】使用 koa 实现一个简单JWT鉴权
全称 JSON Web Token, 是目前最流行的跨域认证解决方案。基本的实现是服务端认证后,生成一个 JSON 对象,发回给用户。用户与服务端通信的时候,都要发回这个 JSON 对象。
GopalFeng
2022/08/01
1.8K0
【Node】使用 koa 实现一个简单JWT鉴权
聊聊微服务架构中的认证鉴权那些事
应用系统绕不开基础的鉴权,微服务架构推荐使用 HTTP 的方式进行服务间通信,这里推荐一篇介绍 HTTP 认证鉴的文章。
aoho求索
2021/11/25
3.3K0
聊聊微服务架构中的认证鉴权那些事
浅谈一下前后端鉴权方式 ^.^
虽然本人现在从事前端开发,但是之前一直是 PHP 全栈,所以对前后端鉴权机制也有一定的了解,就找些资料简单记录一下吧。(瞎掰扯~)
老猫-Leo
2023/12/11
5550
浅谈一下前后端鉴权方式 ^.^
15分钟详解 Python 安全认证的那些事儿~
系统安全可能往往是被大家所忽略的,我们的很多系统说是在互联网上"裸奔"一点都不夸张,很容易受到攻击,系统安全其实是一个复杂且庞大的话题,若要详细讲来估计用几本书的篇幅都讲不完,基于此本篇及下一篇会着重讲解在我们开发系统过程中遇到的一些安全校验机制,希望能起到抛砖引玉的作用,望各位在开发过程中多多思考不要只局限于功能实现上,共勉~
python编程从入门到实践
2021/04/14
2K0
15分钟详解 Python 安全认证的那些事儿~
SpringBoot2.0 整合 JWT 框架,解决Token跨域验证问题
JWT(全称:JSON Web Token),在基于HTTP通信过程中,进行身份认证。
知了一笑
2019/07/19
2K0
使用越来越广泛的2FA双因素认证,缘何越发受到推崇?
随着互联网在生活方方面面的应用,日常少不了要登录各个网站或者应用、或者是银行转账等需要验证自己身份的场景。从早期的输入账号密码来登录,到后来普遍开始通过手机验证码进行登录、或者APP扫码进行登录,身份校验的操作方式经历了一轮又一轮的迭代演进。
是Vzn呀
2024/11/22
2491
公司来了个大神,三方接口调用方案设计的真优雅~~
在为第三方系统提供接口的时候,肯定要考虑接口数据的安全问题,比如数据是否被篡改,数据是否已经过时,数据是否可以重复提交等问题。
程序员蜗牛
2024/04/22
2.5K0
公司来了个大神,三方接口调用方案设计的真优雅~~
一文理解JWT鉴权登录的应用
如果对cookie/token有疑问的,可以查看之前的博客快速了解会话管理三剑客cookie、session和JWT
全菜工程师小辉
2021/04/26
3K0
微信公众平台开发[2] —— 微信端分享功能
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u011415782/article/details/51870790
泥豆芽儿 MT
2018/09/11
5.5K0
微信公众平台开发[2] —— 微信端分享功能
认证鉴权也可以如此简单—使用API网关保护你的API安全
随着企业数字化进程的发展,企业正在大量使用 API 来连接服务和传输数据,API 在带来巨大便利的同时也带来了新的安全问题,被攻击的 API 可能导致重要数据泄漏并对企业业务造成毁灭性影响。因此,API 安全正受到业界和学术界的广泛关注。
克莱尔小熊
2021/12/26
10.9K2
认证鉴权也可以如此简单—使用API网关保护你的API安全
从零玩转系列之微信支付实战PC端支付微信回调接口搭建 | 技术创作特训营第一期
此篇文章过长我将分几个阶段的文章发布(项目源码都有,小程序和PC端),至此微信支付Native支付完成.此篇文章过长我将分几个阶段的文章发布(项目源码都有,小程序和PC端)
杨不易呀
2023/08/14
9240
从零玩转系列之微信支付实战PC端支付微信回调接口搭建 | 技术创作特训营第一期
微服务网关限流&鉴权
​ 不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信,会有以下的问题:
杨不易呀
2022/01/19
2K0
相关推荐
基于Flask开发企业级REST API应用(二)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档