004.内测.情景之迷你用户验证
题图:2014年圣诞节,12306明文密码及用户信息泄露,随后,此案被迅速告破。
004.内测.情景之迷你用户验证
用户信息被拖库,是攻城狮的耻辱,也使整个行业蒙羞。
耻辱柱上,已经钉过了CSDN,小米和某些票贩子网站。
@史荣久 / 2015-01-05 / CC-BY-SA-3.0
任务说明
本次练习是一个迷你版的用户模块,目标是用户验证。
用户模块,最低级错误有:(1)被注入(2)存明文。
算法上,要用慢算法防强暴,要加盐防用户密码太傻。
通常的用户模块,是独立的三块,等价于以下三张表。
(1)信息表(USER_INFORMATION),存用户信息。
(2)验证表(USER_AUTHENTICATION),存验证信息。
(3)授权表(USER_AUTHORIZATION),存权限信息。
题外话:在发达地区,泄露用户信息会被法律制裁。
我们正在发展的路上,所以安全意识一定要接轨。
数据关系
CREATE TABLE IF NOT EXISTS `USER_INFORMATION` (
`UID` INT(11) NOT NULL COMMENT '用户ID',
`SURNAME` VARCHAR(50) NOT NULL COMMENT '姓',
`GVNNAME` VARCHAR(50) NOT NULL COMMENT '名',
`BIRTHDAY` DATE NOT NULL COMMENT '生日',
PRIMARY KEY (`UID`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_bin;
CREATE TABLE IF NOT EXISTS `USER_AUTHENTICATION` (
`LOGINID` VARCHAR(100) NOT NULL COMMENT '登陆ID',
`UID` INT NOT NULL COMMENT '用户ID(FK)',
`PASSHASH` VARCHAR(200) NOT NULL COMMENT '密码散列',
`PASSSALT` VARCHAR(100) NOT NULL COMMENT '密码加盐',
`HASHTYPE` INT NOT NULL COMMENT '散列算法',
PRIMARY KEY (`LOGINID`),
CONSTRAINT `AUTHEN_UID`
FOREIGN KEY (`UID`)
REFERENCES `USER_INFORMATION` (`UID`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `USER_AUTHORIZATION` (
`UID` INT NOT NULL COMMENT '用户ID(FK)',
`ROLE` INT NOT NULL COMMENT '角色ID(FK)',
PRIMARY KEY (`UID`, `ROLE`),
CONSTRAINT `AUTHOR_UID`
FOREIGN KEY (`UID`)
REFERENCES `USER_INFORMATION` (`UID`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_bin;
基础问题
(1)上述表,一个用户,可以有多个LOGINID么?
(2)常用的密码算法有哪些?他们各有什么特点?
(3)文中的"慢算法"指什么?如何做到防爆的?
(4)文中的"加盐"指什么?什么样的密码"太傻"?
(5)简单的"注入"有哪些?怎么防止被注入?
编码问题
(a)写一个计算密码强度的服务,1-100表示强度值。
(b)尽情发挥,写一个用户登陆服务(即通过验证)。
(c)尽情发挥,写一个用户注册服务。
提示:所谓服务,可以但不应该是简单的程序。