基于Python和Django实现的虚拟网络银行

1.背景与意义

1.1 项目开发意义

随着以信息网络技术为代表的科学技术的迅猛发展，21 世纪，我们已步入了一个以网络应用为核心的数字化革命时代，全球经济一体化程度进一步加强，金融企业的经营环境发生了巨大变化。传统产业的运作模式已经让位于知识经济和信息经济。在未来的市场竞争中谁掌握和应用好网络银行这一现代化的营销方式和手段，谁就能在激烈的竞争中取胜，反之则会被淘汰。大力发展网络银行对银行业的发展具有重要的作用。

网络银行的兴起与电子计算机信息技术和电子商务的发展有密切的关系。电子商务是网络银行产生的商业基础,可以说没有电子商务的发展，就不会有网络银行的兴起，电子商务是一种伴随因特网的普及而产生的新型贸易方式，它是当代信息技术和网络技术在商务领域广泛应用的结果。

电子商务技术的发展催生了网络银行。通常说，电子商务对银行的要求有两方面：一是要求银行为之提供相互配套网上的支付系统；另一面是要求银行提供与之相适应的虚拟金融服务。电子商务是一种网上交易方式。所有的网上交易都由两个环节组成的，一是交易环节，二是支付环节，前者是在客户与销售之间完成，后者需要通过银行网络完成。

1.2 国内外现状及技术综述

我国的网上银行产生于上世纪九十年代后期，虽然起步较晚，但发展的势头却很迅猛。1997年招商银行率先在国内推出了网上银行业务，开了我国网上银行的先河，并通过网上银行推出信息咨询、个人银行、企业银行、网上证券等多项服务。2003年的“非典”在我国暴发，激起了网上银行业务的迅速发展。据中国人民银行统计，到 2008年底，我国境内已有70多家银行的分支机构开展了实质性的网上银行业务，当年交易额已超过90万亿元人民币，较上年增长70.79％。据统计，2002-2008年间，中国网上银行交易额年均增长率高达115％。

根据IRESEARCH艾瑞市场咨询研究成果显示：2008年，中国国内个人网上银行用户规模为4469万户；国内网上银行使用人数与2007年相比有了大幅度增长，抽查样本中，同比增长了1.7倍，网上银行使用企业数增长了近3倍。我国网上银行走了十多年历程，取得的成效是显而易见的，但也受多种困难的挑战和制约，还存在不少问题，突出有以下几点：

1.2.1 网上银行发展的基础比较薄弱

基础设施落后 。主要是指硬件不硬，我国的网络建设除了省、市级以上的大中城市和东部沿海城市发展较快外，其他地方仍然存在着网络覆盖面窄、速度较慢、容量较小、频带不宽、网络吞吐能力有限的现象。目前我国电话、电脑和网络总体普及率不高，远低于美国2000年的水平。同时软件过软，特别是在软件开发方面，重复开发过多，造成了巨大浪费。

网上银行使用对象少 。经济总量大，人均量很小的现实使我国Internet的社会普及程度较低，电子商务不活跃，导致网上银行缺乏人气基础。资料显示，目前美国使用互联网的成年人已经超过了 1亿，接近国民人口的一半，我国不足四分之一。并且，网民中有三分之一是学生，他们使用网上银行服务的机率很小，绝大多数网民上网的主要目的在于娱乐和获取信息。

市场主体发展不健全 。目前国内网上银行是在现有银行的基础上格局上发展起来的，通过网上银行延伸服务即所谓的传统业务挂靠的电子银行系统，大多数只满足于存款、汇款、汇兑、代收费等业务，只是一个简单化的传统业务外挂，严格说只能算柜面业务的 “上网银行”，总体服务层次低，缺乏内涵，缺乏特色。少数银行对网上银行发展方向认识模糊，仅把它当作扩大传统业务的手段，没有意识到这是一场金融界的革命。

1.2.2 网上银行的发展环境待完善

法律法规滞后 。网上银行在有关服务承担者的资格、交易规则、交易合同的有效成立、交易双方当事人权责等方面，比传统银行更复杂，难以界定，必须通过法制的手段来解决。发达国家和地区的金融监管，当局大都针对网上银行业务制定了系统的监管法规、风险监管指引和监管手册。例如，美国联邦储备委员会于1997年12月发布了《网络信息安全最佳实务指引》，美国货币监管署于1998年8月发布了《网上银行业务检查手册》。2001年中国人民银行虽然颁发了《网络银行业务管理暂行办法》，之后又出台了《电子银行业务管理办法》等法规，但网上银行的发展十分迅速，有些规定难以适应新形势发展需要，必须与时俱进，制定出台适应网上银行发展的规章制度。

安全保障令人担忧 。网络安全事关网上银行的生死存亡，是网上银行发展的核心问题。安全既是个技术问题，也是个管理问题。只有保证了安全才能谈得上盈利，资金安全对银行客户、商家永远是至关重要的。从 2004年8月到2008年10月期间，全国感染各类网上银行木马病毒及其变种的用户数量增长了600倍，用户每月感染病毒及其变种的数量约为160种。中国金融认证中心2007年调查时就发现，超过50％的人不打算使用或者不敢使用网上银行，2008 年不但未好转，反而更加严重。

2.需求分析

2.1 总体需求

本系统的用户可以分为两类，普通用户和管理员用户。消费者和商家都可以注册为普通用户，当以商家身份注册时，需要银行管理员的审核通过。管理员提供给商家支付链接。

管理员可以审核用户的注册，开通账户、冻结账户以及审核账户的安全性。本系统给电商平台提供支付链接，认证支付信息并自动更改用户的账户余额等信息。

所有用户都可以进入银行系统查看账户信息并转账。

2.2 功能需求

2.2.1 银行系统

注册：用户上传实名身份信息，设置登陆密码和支付密码，审核通过后开通账户，并提供给用户唯一 ID，用于登陆
登陆：用户输入 ID 和密码，验证成功后进入系统界面。
修改个人信息 ：可修改手机号、邮箱等信息，但是身份证号和姓名信息一旦注册后不可修改
修改密码 ：登陆密码和支付密码必须验证原密码后才可修改
银行卡管理 ：用户验证支付密码之后可开通一张新的银行卡，并提供给用户唯一卡号，用于转账、存款和取款时识别银行卡。一个用户可申请多张银行卡，每张卡的金额独立。用户可随时登陆系统查看自己的余额和卡状态
转账：用户选择自己的银行卡，输入对方银行卡号，再输入支付密码后确认转账。余额不足、支付密码错误、卡号错误时都不能转账
存取款 ：此功能是为方便用户给银行卡添加一定的金额（银行卡新申请时余额为 0），在实际网上银行系统中并无此功能（实际的银行系统存取款需要到实体 ATM 机进行）
查询转账记录 ：转账记录包括流水号、转账人、源卡号、目的卡号、转账金额、转账时间。用户只可查看和自己的银行卡号有关的转账记录
查看存取款记录 ：存取款记录包括流水号、操作、银行卡号、金额、本次余额和存取款时间

2.2.2 电子商城接口

给电子商城提供支付接口（127.0.0.1:8001/pay?xxx=xxx&xxx=xxx）。消费者首先在银行系统注册并添加银行卡，获取用户 ID 和银行卡号。在电子商城产生订单后使用支付接口将支付信息和订单摘要发送给银行（SET 协议验证），用户界面将跳转到银行系统，输入支付密码后完成支付。

2.3 安全需求

2.3.1 账户安全

只有上传个人资料管理员审核之后才能允许注册。所有账户必须保证身份信息真是可靠。

用户的资料以及转账记录不能被其他人监视。只有本人登陆后才可查看。

用户的密码信息，包括登陆密码和支付密码，不以明文方式存储。只存储摘要。

2.3.2 订单安全

银行系统不能查看商家和客户之间的订单信息，只能查看转账信息，但是系统可以验证订单信息是否被伪造。这里使用双签名技术，并使用 SET 协议保证订单全程的安全。

2.3.3 通信安全

银行系统的使用中，客户端和服务器之间所有的通信信息都经过加密，可对抗旁路攻击。

电商平台和银行系统之间的通信必须保证机密性、完整性。

电商平台的用户生成订单后会点击支付链接，这时电商平台和银行系统之间开始展开秘密通信。

首先电商平台和银行系统互相查看各自的 CA 证书并获取公钥，银行用私钥加密一条随机消息串发送给电商，电商用银行的公钥解密，这样双方有了共同的秘密消息，之后双方利用此秘密消息作为私钥，加密双方的通信。

共同私钥定时更换，比如十分钟更换一次。

2.3.4 数据库安全

银行数据库作为整个网上交易系统中最为重要的数据库，需要有加密技术来支持，并且及时备份。

2.4 性能需求

能够同时满足 1000 人的访问
用户认证过程需要安全可靠，速度快，普通用户登录时间小于 3s
系统可以 24 小时不间断工作
可以和电商平台对接
平台兼容性好，能够在各种浏览器上运行

3.概要设计

3.1 硬件环境

云服务器 ：

有独立 IP 和域名
网络带宽不低于 10Mbps
内存 8G
硬盘 500G

3.2 开发环境

操作系统 ：Windows 10 Pro
数据库 ：Mysql
服务器 ：Django
语言：Python3.6 + html + JavaScript + css

3.3 用户环境

Windows、Mac、Linux、Android、IOS，通过浏览器访问。支持的浏览器为 IE、火狐、谷歌浏览器。

3.4 业务数据流

3.5 功能模块划分

3.6 功能模块定义

3.6.1 管理员模块

管理员模块需要经过银行管理员登陆并认证后操作。管理员可以审核用户注册、获取用户异常，并根据异常信息冻结账户，所有的操作记录数据库。

3.6.2 用户操作

用户包括电商用户和普通用户，都可以进行状态修改，比如修改个人信息、修改密码。有敏感操作时需要转到认证模块作安全认证。

3.6.3 身份认证

银行系统的敏感操作之前需要有安全认证。验证内容包括数字证书是否真实、是否过期，登陆状态是否正常。

3.6.4 订单审核

执行 SET 协议，判断订单信息是否真实，再执行支付操作，转账信息写入数据库，并更改账户余额。

3.6.5 通信模块

电商平台根据提供的支付链接转到银行系统，此后双方执行类似于 SSH 的协议互相认证身份并协商出临时对称密钥，用于加密之后的通信。

3.7 功能模块划分

3.7.1 用户基本信息表

Users

字段	类型	长度	是否主键	是否非空	备注
uID	int	32	是	是	用户 ID
uName	Varchar	32	否	是	用户姓名
Uphone	Varchar	32	否	是	用户手机号
Uemail	Varchar	32	否	是	用户邮箱
uPassword	Varchar	128	否	是	登陆密码
uPaypasswd	Varchar	128	否	是	支付密码
Time	Date		否	是	创建时间
Status	Varchar	32	否	否	用户状态

3.7.2 管理员基本信息表

Admins

字段	类型	长度	是否主键	是否非空	备注
aID	int	32	是	是	管理员 ID
aName	Varchar	32	否	是	用户姓名
aPassword	Varchar	64	否	是	用户密码

3.7.3 转账信息

Transfer

字段	类型	长度	是否主键	是否非空	外键	备注
Serial	int	32	是	是		流水号
Suser	int	32	否	是	Users	发起者 ID
Duser	int	32	否	是	Users	接收者 ID
Scard	int	32	否	是	Crashcard
dcard	int	32	否	是	Crashcard
mID	Varchar	32	否	否		电商 ID
Amount	Float		否	是		金额
sBalance	Float		否	是		发起者本次余额
dBalance	Float		否	是		接收者本次余额
Time	Date		否	是		日期
Remark	Varchar	128	否	否		备注

3.7.4 银行卡信息

字段	类型	长度	是否主键	是否非空	外键	备注
kID	int		是	是		银行卡号
Balance	Varchar	32	否	否		余额
User	int		否	是	Users	用户 id
Time	Date		否	是		创建时间
Status	Varchar	32	否	否		卡状态

3.7.5 存取款信息

字段	类型	长度	是否主键	是否非空	外键	备注
Serial	int		是	是		流水号
User	int		否	是	Users	用户 ID
Amount	Varchar	32	否	是		存取款金额
Balance	Float		否	是		用户本次剩余金额
Type	Varchar	8	否	是		存/取
Datafrom	Varchar	32	否	否		存取款来源
Time	Date		否	是		日期

4.详细设计

4.1 注册

4.1.1 页面设计

4.1.2 实现方法

输入地址 127.0.0.1:8001，自动跳转到登陆页面，点击注册按钮进入注册页面。

传输安全：将 CA 服务器提供的证书放到 html 页面，用户客户端提交表单时首先提取证书中的公钥字段，利用公钥加密表单，传输到服务器。服务器接收到信息后首先用私钥解密，再执行下一步操作。

前端加密 Signup.html

```html

```

后端加密 Views.py

python def signup(request): if request.method=="GET": return render(request, "signup.html") if request.method=="POST": name = request.POST.get("name", None) idcard = tools.DecodeDecrypt(request.POST.get("idcard", None)).decode() phone = tools.DecodeDecrypt(request.POST.get("phone", None)).decode() email = tools.DecodeDecrypt(request.POST.get("email", None)).decode() passwd = tools.DecodeDecrypt(request.POST.get("passwd", None)).decode() paypasswd = tools.DecodeDecrypt(request.POST.get("paypasswd", None)).decode()

数据库存储密码：登陆密码和支付密码不能直接存入数据库，而是存加 salt 的哈希值。

4.2 登陆

4.2.1 页面设计

4.2.2 实现方法

用户点击登陆后，客户端向服务器发送一个 post 请求，包含公钥加密后的ID 和登陆密码。服务器接收后，用系统私钥解密，解密成功后：

验证登陆密码的加 salt 哈希和数据库存储是否一致，一致的话执行下一步操作，不一致返回登陆界面
服务器设置 session，添加用户 ID 和 name 字段，之后每次操作验证登陆信息时，检查这两个 session 值是否存在即可
服务器返回“success“字段，客户端接收后执行 href="/viewuserinf/" ，执行信息查看操作
传输安全：用户在登陆界面提交的表单，前端用公钥加密，服务器用私钥解密，具体操作同注册的传输安全

4.3 信息查看

4.3.1 页面设计

4.3.2 实现方法

请求查看页面的请求类型全部为 get 型，url 为 127.0.0.1:8001/viewuserinf/，服务器接收到该请求后，首先验证session 的 id 字段是否存在，存在才可继续查看，不存在则清楚所有 session 并返回登陆界面。

Views.py

python def viewuserinf(request): if request.method=="GET": try: id_session = request.session["id"] tmp = Users.objects.get(id=int(id_session)) return render(request,"user_inf_show.html",{"inf":tmp}) except: return render(request, "login.html") return render(request, "login.html")

4.4信息修改

4.4.1 页面设计

4.4.2 实现方法

由于用户姓名、身份证号是认证信息，不可修改，登陆密码和支付密码不在此模块。所以这里只能修改手机号和电子邮箱。

获取信息修改页面的请求方式是 get，用户点击“信息修改”按钮或者直接在浏览器地址栏中输入 url ： http://127.0.0.1:8001/edituserinf/ ，就会返回信息修改页面。

信息修改的表单提交使用 post 请求，用户输入的表单信息用公钥加密后传输，服务器接收后用私钥解密，然后检查 session 的 id 字段是否存在，存在则修改成功，返回信息查看界面，否则返回登陆界面。

4.5 更改密码

4.5.1 页面设计

4.5.2 实现方法

获取修改密码界面的请求方式是 get，用户在登陆状态下，点击“修改密码”或者在浏览器地址栏输入 url：127.0.0.1:8001/editpasswd/获得界面。用户可选择登陆密码和支付密码，更改密码必须输入原密码。

表单提交的请求方式是 post 请求，客户端使用公钥加密表单，服务器接收请求后用私钥解密，之后：

检查服务器 session 中是否存在 id 字段，存在继续下一步，不存在返回登陆界面
MD5加盐计算密码哈希值，与数据库存储的哈希值对比，相等，执行下一步，否则返回信息修改界面重新提交
计算新密码的加 salt 哈希值，存入数据库。修改完成后，如果是修改支付密码，返回信息查看界面，如果是修改登陆密码，删除 session 后返回登陆界面

安全设计：客户端公钥加密传输表单，客户端私钥解密，保证传输安全。修改密码必须验证原密码，并且密码只存储哈希值，保证密码数据库安全。

4.6 银行卡管理

4.6.1 页面设计

查看所有个人银行卡：

添加银行卡：

4.6.2 实现方法

用户获取银行卡管理界面的请求方式为 get，在登陆状态下点击“银行卡管理”或者 url 输入 127.0.0.1:8001/cardmanage/ 进入银行卡管理界面。服务器将银行卡信息返回给用户，每张银行卡信息包括卡号、建立时间、余额和状态。由于涉及到金额，银行卡一旦添加不可删除。

在银行卡管理模块可以选择添加银行卡，获取页面的请求方式仍是 get。获取到界面后，用户必须输入支付密码，点击确认添加，向服务器发送 post 请求，表单内容为公钥加密后的支付密码。

服务器接收到请求后，首先检查 session 的 id 字段是否存在，存在执行下一步，否则删除全部 session 返回登陆界面。解密表单内容，获取明文支付密码，计算加 salt 哈希值，对比数据库支付密码哈希值，相同后即可分配银行卡。

银行卡添加成功后，分配一个唯一卡号，状态默认为正常，余额默认为 0。随后返回银行卡管理界面。

4.7 转账

4.7.1 页面管理

4.7.2 实现方法

在登录状态下，用户通过点击“转账”或者输入 url： 127.0.0.1:8001/transfer/向服务器发送 get 请求，进入转账界面。

用户选择本方卡号，输入对方卡号、转账金额、支付密码后确认转账，javascrpt使用公钥加密表单后传输给服务器。服务器接收并私钥解密后：

检查登陆状态，即检查 session 的 id 字段是否存在，不存在返回登陆界面，存在则进入下一步
计算用户输入的 paypasswd 的加 salt 哈希值，与数据库提取的密码哈希值对比，相同则进入下一步，不同则返回转账界面重新输入
将此转账信息写入数据库，再将对应的银行卡做余额更改。执行成功后进入转账查询界面。

安全：

客户端公钥加密后传输，防止旁路攻击
密码存哈希值，明文不出现数据库
转账记录表和银行卡表中记录的更改在确认转账可以执行后，才一起更改防止数据不同步

python tmp1 = Transfer(time=time, scard=CrashCard.objects.get(id=scard), dcard=CrashCard.objects.get(id=dcard), suser=Users.objects.get(id=uid), duser=Users.objects.get(id=CrashCard.objects.get(id=dcard).user.id), amount=amount, scbalance=CrashCard.objects.get(id=scard).balance - amount, dcbalance=CrashCard.objects.get(id=dcard).balance + amount ) CrashCard.objects.filter(id=scard).update(balance=scbalance - amount) CrashCard.objects.filter(id=dcard).update(balance=dcbalance + amount) tmp1.save()