生命在于折腾 http://www.xa01.cc 折腾不息... Mon, 20 Feb 2012 07:16:32 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Hadoop伪分布模式搭建 http://www.xa01.cc/59.html http://www.xa01.cc/59.html#comments Mon, 20 Feb 2012 06:45:26 +0000 adminjs http://www.xa01.cc/?p=59 http://www.xa01.cc/59.html/feed 0 Mysqlhotcopy 备份方法 http://www.xa01.cc/57.html http://www.xa01.cc/57.html#comments Sun, 29 Jan 2012 03:47:26 +0000 afoolfox http://www.xa01.cc/?p=57 Mysqlhotcopy 是一个 PERL 程序。它使用 LOCK TABLES、FLUSH   TABLES 和 cp 或 scp  来快速备 份数据库。它是备份数据库或单个表的最快的途径，但它只能运行在数据库文件(包括数据表定义文件、数 据文件、索引文件)所在的机器上。 mysqlhotcopy 只能用于备份 MyISAM，并且只能运行在 类 Unix 和 NetWare 系统上。 mysqlhotcopy 支持一次性拷贝多个数据库，同时还支持正则表达。 msqlhotcopy 和 mysqldump 对比： 1、前者是文件意义上的 COPY，后者是一个数据库端的 SQL 语句集合。 2、前者只能运行在数据库目录所在的机器上，后者可以用在远程客户端。 3、相同的地方都是在线执行 LOCK TABLES 以及 UNLOCK TABLES 4、前者恢复只需要 COPY 备份文件到源目录覆盖即可，后者需要倒入 SQL 文件到原来库中。(source 或 者\.或者 mysql < 备份文件)。 5、前者只适用于 MyISAM 引擎，而后则则可同时使用于 MyISAM 引擎和 InodDB 引擎. 6、前者在使用前必须安装 perl-DBD-mysql 包,而后者则不需要. 试验环境： 虚拟机操作系统：Centos 5.5 数据库版本：mysql 5.1.49 perl-DBD-mysql-4.014   （Mysqlhotcopy 需要有 perl-dbd 模块的支持） mysql 数据库目录：/var/lib/mysql mysql 数据库备份路径：/backup/mysql 1、设置/etc/my.cnf,重启 mysqld 服务，之后使用 msqlhotcopy 就不用输入用户密码 [mysqlhotcopy] interactive-timeout user=root password=123456 port=3306 2、备份方法 # mysqlhotcopy mysqldb_name /backup
// 备份 mysql 整个数据库 # mysqlhotcopy -u root -p 123456 mysql /backup/mysql // 同时备份 mysql 和 test1 两个数据库 # mysqlhotcopy -u root -p 123456 mysql test1 /backup/mysql // 备份 mysql 数据库里的 user 表，支持正则表达式 # mysqlhotcopy -u root -p 123456 mysql./user*/ /backup/mysql 3、备份查询 可以将每次的备份写入数据库，日后查询备份记录. // 创建 hotcopy 数据库并建立表格 mysql> create database hotcopy; mysql> use hotcopy mysql> create table checkpoint(time_stamp timestamp not null,src varchar(32),dest varchar(60), msg varchar(255)); mysql> select * from checkpoint; +---------------------+-------+------------+-----------+ | time_stamp                 | src     | dest            | msg            | +---------------------+-------+------------+-----------+ | 2010-07-30 14:11:45 | mysql | /tmp/mysql | Succeeded | | 2010-07-30 14:12:37 | test1 | /tmp/test1 | Succeeded | +---------------------+-------+------------+-----------+ 2 rows in set (0.00 sec)
4、恢复方法 // 复制备份的数据库 test 到相应目录，注意目录的权限。 # /bin/cp -rf /backup/mysql/test/ /var/lib/mysql/ 5、选项解释 // 显示帮助消息并退出。 --help // 如果目标存在不放弃(加上一个_old 后缀重新命名它)。 --allowold // 不要重命名目标目录（如果存在）;新的备份自动覆盖原来的，可以实现增量备份。 --addtodest // 在指定的 db_name.tbl_name 插入检查点条目。 --checkpoint=db_name.tbl_name // 启用调试输出。 --debug // 报告动作而不执行它们。 --dryrun，-n // 所有表锁定后刷新日志。 --flushlog // 完成后不删除以前(重新命名的)的目标。 --keepold // 复制方法(cp 或 scp)。 -- method=command
// 备份中不包括全部索引文件。这样使备份更小、更快。可以在以后用 myisamchk -rq 重新构建索引。 --noindices // 当连接服务器时使用的密码。请注意该选项的密码值是不可选的，不象其它 MySQL 程序。 --password=password，-p password // 当连接本地服务器时使用的 TCP/IP 端口号。 --port=port_num，-P port_num // 除了出现错误时保持沉默。 --quiet，-q // 复制所有数据库名匹配给出的正则表达式的数据库。 --regexp=expr // 用于连接的 Unix 套接字文件。 --socket=path，-S path // 所复制的数据库名的后缀。 --suffix=str // 临时目录(代替/tmp)。 --tmpdir=path // 当连接服务器时使用的 MySQL 用户名.要想执行 mysqlhotcopy，你必须可以访问备份的表文件，具有 那些表的 SELECT 权限和 RELOAD 权限(以便能够执行 FLUSH TABLES). --user=user_name，-u user_name 6、备份脚本 1）建立数据库自动备份脚本 # vi mysql-backup.sh
#！/bin/bash PATH=/usr/local/sbin:/usr/bin:/bin # The Directory of Backup BACKDIR=/backup/mysql # The Password of MySQL ROOTPASS=123456 # Remake the Directory of Backup rm -rf $BACKDIR mkdir -p $BACKDIR # Get the Name of Database DBLIST=`ls -p /var/lib/mysql | grep / | tr -d /` # Backup with Database for dbname in $DBLIST do mysqlhotcopy $dbname -u root -p $ROOTPASS $BACKDIR | logger -t mysqlhotcopy done 2）测试脚本运行 // 给脚本增加执行权限 # chmod 700 mysql-backup.sh // 运行脚本 # ./mysql-backup.sh // 查看备份是否成功 # ll /backup/mysql // 设置备份脚本每天自动运行 # crontab –e // 在文本里添加下面一行 00 03 * * * /root/mysql-backup.sh // 查看作业情况
# crontab -l 00 03 * * * /root/mysql-backup.sh]]> http://www.xa01.cc/57.html/feed 0 Web开发中需要了解的东西 http://www.xa01.cc/50.html http://www.xa01.cc/50.html#comments Wed, 18 Jan 2012 08:11:56 +0000 lv http://www.xa01.cc/?p=50 What should every programmer know about web development?（关于Web开发，什么是所有程序员需要知道的？）里面给出的答案非常不错，所以，我翻译转载过来。 顺便说一下，StackExchange真是非常好，大家可以对同一个答案做贡献和修订，看看这个问题的修订过程你就知道了——专业的问答网站应该怎么去做。这就是我在这篇文章中也说过真正的用户体验是什么样的。 好了，下面是正文（我对原文做了一些批注，也许不对或有误导，请大家指正） 下面的这些东西可能对于大多数人并不陌生，但是可能会有些东西你以前并没有看过，或是没有完全搞懂，甚至都没有听说过。（陈皓注：我相信当你看完这个列表后，你会觉得对于我国的Web开发有点弱了，还是那句话，表面上的东西永远是肤浅的）

接口和用户体验

  • 小心浏览器的实现标准上的不一致，确信让你的网站能够适当地跨浏览器。至少，你的网站需要测试一下下面的浏览器：
最后，你可以使用一下这个工具 来看看你的网页在不同的浏览器下是怎么被显示出来的（陈皓注：这个工具就是以前本站介绍过的在不同浏览器和平台上检查你的网站的兼容性）
  • 多考虑一下人们是怎么来访问你的网站而不是那些主流的浏览器：手机，读屏软件和搜索引擎，例如：一些Accessibility的东西： WAI 和  Section508, 移动设备开发：MobiForge.
  • 部署Staging：怎么部署网站的更新而不会影响用户的访问。 Ed Lucas的答案 可以让你了解一些（陈皓注：Ed说了一些如版本控制，自动化build，备份，回滚等机制）。
  • 千万不要直接给用户显示不友好的错误信息。
 
  • 千万不要把用户的邮件地址以明文显示出来，这样会被爬虫爬走并被让用户的邮箱被垃圾邮件搞死。
  • 为用户的链接加上 rel="nofollow" 的属性以 避免垃圾网站的干扰。（陈皓注：nofollow是HTML的一个属性，用于通知搜索引擎“这个链接所指向的网页非我所能控制，对其内容不予置评”，或者简单地说，该链接不是对目标网站或网页的“投票”，这样搜索引擎不会再访问这个链接。这个是用来减少一些特定垃圾页面对原网站的影响，从而可以改善搜索结果的质量，并且防止垃圾链接的蔓延。）
  • 为网站建立一些的限制 - 这个属于安全性的范畴。（陈皓注：比如你在Google注册邮箱时，你一口气注册超过两个以上的邮箱，gmail要求给你发短信或是给你打电话认证，比如Discuz论坛的会限制你发贴或是搜索的间隔时间等等，更多的网站会用CAPTCHA来确认是人为的操作。 这些限制都是为了防止垃圾和恶意攻击）
  • 学习如何做 Progressive Enhancement. （陈皓注：Progressive Enhancement是一个Web Design的理念，如：1）基础的内容和功能应该可以被所有的浏览器存取，2）页面布局的应该使用外部的CSS链接，3）Javascript也应该是外部链接还应该是 unobtrusive 的，4）应该让用户可以设置他们的偏好）
  • 严重关注Accessibility。因为这是法律上的需求（陈皓注：Section 508是美国的508法案，其是美国劳工复健法的改进，它是一部联邦法律，这个法律要求所有技术要考虑到残障人士的应用，如果某个大众信息传播网站，如果某些用户群体（如残疾人）浏览该网站获取信息时，如果他们无法正常获得所期望的信息（如无法正常浏览），那可以依据相关法规，可以对该网站依法起诉）。 WAI-ARIA 为这方面的事提供很不错的资源.

安全

  • 在网上有很多关于安全的文章，但是 OWASP 开发指导 涵盖了几乎所有关于Web站点安全的东西。（陈皓注：OWASP(开放Web应用安全项目- Open Web Application Security Project)是一个开放的非营利性组织，目前全球有130个分会近万名会员，其主要目标是研议协助解决Web软体安全之标准、工具与技术文件，长期 致力于协助政府或企业了解并改善网页应用程式与网页服务的安全性。OWASP被视为Web应用安全领域的权威参考。2009年下列发布的美国国家和国际立法、标准、准则、委员会和行业实务守则参考引用了OWASP。美国联邦贸易委员会(FTC)强烈建议所有企业需遵循OWASP十大WEB弱点防护守则）
  • 永远不要相信用户的输入（包括Cookies，因为那也是用户的输入）
  • 对用户的口令进行Hash，并使用salt，以防止Rainbow 攻击（陈皓注：Hash算法可用MD5或SHA1等，对口令使用salt的意思是，user 在设定密码时，system 产生另外一个random string(salt)。在datbase 存的​​是与salt + passwd 产的md5sum 及salt。 当要验证密码时就把user 输入的string 加上使用者的salt，产生md5s​​um 来比对。 理论上用salt 可以大幅度让密码更难破解，相同的密码除非刚好salt 相同，最后​​存在database 上的内容是不一样的。google一下md5+salt你可以看到很多文章。关于Rainbow 攻击，其意思是很像密码字典表，但不同的是，Rainbow Table存的是已经被Hash过的密码了，而且其查找密码的速度更快，这样可以让攻击非常快）。使用慢一点的Hash算法来保存口令，如 bcrypt (被时间检证过了) 或是 scrypt (更强，但是也更新一些) (1, 2)。你可以阅读一下 How To Safely Store A Password（陈皓注：酷壳以前曾介绍过bcrypt这个算法，这里，我更建议我们应该让用户输入比较强的口令，比如Apple ID注册的过程需要用户输入超过8位，需要有大小写和数字的口令，或是做出类似于这样的用户体验的东西）。
  • 使用 SSL/HTTPS 来加密传输登录页面或是任可有敏感信息的页面，比如信用卡号等。
  • 知道如何对付session 劫持。（陈皓注：请参看wikipedia的这Session Hijacking，）
  • 保持你的系统里的所有软件更新到最新的patch。
  • 确保你的数据库连接是安全的。
  • 确保你能了解最新的攻击技术，以及你系统的脆弱处。

性能

  • 优化页面 —— 不要使用20KB图片来平铺网页背景。（陈皓注：还有很多网页页面优化性的文章，你可以STFG – Search The Fucking Google一下。如果你要调试的话，你可以使用firebug或是chrome内置的开发人员的工具来查看网页装载的性能）
  • 学习如何 gzip/deflate 网页 (deflate 更好).
  • 把多个CSS文件和Javascript文件合并成一个，这样可以减少浏览器的网络连数，并且使用gzip压缩被反复用到的文件。
  • 为那些小的图片使用 CSS Image Sprites，就像工具条一样。 (参看 “最小化 HTTP 请求” ) （陈皓注：把所有的小图片合并成一个图片，然后用CSS把显示其中的一块，这样，这些小图片只用传输一次，酷壳的Wordpress样式的那个RSS订阅列表中的小图标就是这样做的）
  • 繁忙的网络应该考虑把网页的内容分开存放在不同的域名下。（陈皓注：比如有专门的图片服务器——图片相当耗带宽，或是专门的Ajax服务器）
  • 静态网页 (如，图片，CSS，JavaScript，以及一些不需要访问cookies的网页) 应该放在一个不使用cookies的独立的域名下，因为所有在同一个域名或子域名下的cookie会被这个域名下的请求一同发送。另一个好的选择是使用 Content Delivery Network (CDN).
  • 使用单个页面的HTTP请求数最小化。
  • 为Javascript使用 Google Closure Compiler 或是 其它压缩工具（陈皓注：压缩Javascript代码可以让你的页面减少网络传输从而可以得到很快的喧染。注意，并不是所有的工具都可以正确压缩Javascript的，Google的这个工具甚至还可以帮你优化你的代码）
  • 确认你的网站有一个 favicon.ico 文件放在网站的根下，如 /favicon.ico. 浏览器会自动请求这个文件，就算这个图标文件没有在你的网页中明显说明，浏览器也会请求。如果你没有这个文件，就会出大量的404错误，这会消耗你的服务器带宽。（陈皓注：服务器返回404页面会比这个ico文件可能还大）

SEO (搜索引擎优化)

  • 使用 “搜索引擎喜欢的” URL，如：使用 example.com/pages/45-article-title 而不是 example.com/index.php?page=45 (陈皓注：这里的URL是说Wordpress的，后者是默认的)
  • 如果你的动态页面要使用 # ，那么请把其改成 #! ，而在服务端，你需要处理$_REQUEST["_escaped_fragment_"] 这是Google搜索引擎需要的。换句话说，./#!page=1 会被Google搜索引擎转成 ./?_escaped_fragments_=page=1。 （陈皓注：通常来说URL中的#后的东西都不会被传到服务器上，所以，为了要让Google可以抓取AJAX的东西，你需要使用#!，而Google会把“#!”转成“_escaped_fragment_”来向服务器发请求，Twitter的大量的链接者是#!的，比如：https://twitter.com/#!/your_activity）。另外，用户也许会使用Firefox 或 Chromium， history.pushState({"foo":"bar"}, "About", "./?page=1"); 是一个很不错的命令。所以，就算是我们的地址栏上的地址改变了，页面也不会重新装载。这可以让你使用 ? 而不是 #! 也能无刷地保住当前的动态的页面，这可以让AJAX的请求被浏览器记住。
  • 别使用 “click here” 这样的链接。这样一来，无法SEO，而且对于一些需要使用读屏人来说很不友好（陈皓注：关于读屏软件，可参看本站的“如果看不见你还能编程吗”）
  • 了解 robots.txt 和搜索引擎爬虫是如何工作的。
  • 重定向请求 (使用 301 重定向网站) ，如果你要把 www.example.com 定向到 example.com(或是其它的变更) 这样可以防止Google的rank因为域名的变化发生改变。（陈皓注：301重定向一般用作域名变更）
  • 知道并不是所有的爬虫都是好的，有些爬虫的行为并不好。（陈皓注：比如向你的网站发大量的请求导致服务器性能低下）
  • 如果你有一些非文本的内容需要在 Google’s sitemap  中，比如视频什么的。Tim Farley的答案，可以让你看到很多有价值的东西。

技术

  • 理解什么是 HTTP 比如 GET, POST, sessions, cookies等，了解什么是 “stateless” 无状态。
  • 让你的 XHTML/HTML 和 CSS 符合 W3C 规范，并确认他们都是 合格的。我们的目标是避免浏览器的 “quirks mode”，并且可以让其更容易地能和非标准的浏览器工作，比如读屏器或移动设备。
  • 理解浏览器是怎么处理 JavaScript 的。（陈皓：你会看到有些Javascript代码在页面上前面，有些则是在后面，所以你需要对其了解清楚为什么是这样）
  • 了解浏览器是怎么装载 JavaScript，CSS和其它资源的，了解其对视觉上的影响。（陈皓注：10年前我做网页的时候因为HTML还很弱，所以只能使用table来布局，使用table布局的问题就是整个table读完后页面才会显示，用户的视觉体验并不好）。在某些情况下，你可能需要把你的脚本放在页面的后面。
  • 理解 JavaScript 的 sandbox 是怎么怎么工作的，尤其是你想使用iframes。
  • 请注意 JavaScript 可能会被禁止，这样会让你的AJAX失效。就算是大多数用户都开启了Javascript功能，但是也可能在一些情况下脚本是不被运行的，比如移动终端上，搜索引擎抓网页的时候也并不会执行你的脚本。
  • 尽可能多地学习你的部署平台。（比如：操作系统，Web Server：Apache/Nginx，防火墙，数据库，等等）
  • 把视觉效果和JS框架合在一起讨论，考虑使用一个Service，如：Google Libraries API 来装载框架，这样可以让浏览器可能早就把这个JS框架已经cache了而不需要再从你的网站上下载了。

Bug fixing

  • 明白你会花20%的时间写代码，而80%的时候在维护，所以你要小心编码。（陈皓注：参看本站的“多些时间可以少些代码”一文）
  • 设计一个好的错误报告机制。
  • 设计一个入口可以让人们联系到你并给你建议和批评。
  • 为你开发的东西形成文档，这样可以让后来的人容易维护你的软件和系统。
  • 频繁备份（也可确保你的这些备份功能正常） Ed Lucas 的回答 有一些忠告。你还需要有一个恢复策略，而不只是一个备份策略。
  • 使用一个版本控制系统来保存你的代码，如： Subversion 或 Git.
  • 别忘了做Acceptance Testing，使用 Selenium 能帮到你。
  • 确保你有足够的日志，你可以使用 log4j, log4n 或 log4r。如果出了问题，这是可以让你快速找到问题的方式。
  • 当你写日志的时候，确保你记录了你捕获了处理和未处理异常。报告和分析日志可以让你知道你网站的问题。
这里有多的东西被省略了，并不是因为那些可能不是有帮助的答案，而是因为那些东西都太细节了，超出了这个问题的范围，因为这本来就是一个Web开发需要了解东西的Overview。我想你可以去看一下其它人的答案，我有时间，我也会补充别人的答案进来。请随意编辑这个答案，因为可能有些东西忘了，也有可能有些东西不对。 （全文完）]]> http://www.xa01.cc/50.html/feed 0 你会做Web上的用户登录功能吗？ http://www.xa01.cc/46.html http://www.xa01.cc/46.html#comments Wed, 18 Jan 2012 08:09:19 +0000 lv http://www.xa01.cc/?p=46 以下内容，转载时请保持原文一致，并请注明作者和出处。

用户名和口令

首先，我们先来说说用户名和口令的事。这并不是本站第一次谈论这个事了。如何管理自己的口令让你知道怎么管理自己的口令，破解你的口令让你知道在现代这样速度的计算速度下，用穷举法破解你的口令可能会是一件很轻松的事。在这里我想告诉从开发者的角度上来做设计这个用户名和口令的事。下面一几件规则：
  • 限制用户输入一些非常容易被破解的口令。如什么qwert，123456, password之类，就像twitter限制用户的口令一样做一个口令的黑名单。另外，你可以限制用户口令的长度，是否有大小写，是否有数字，你可以用你的程序做一下校验。当然，这可能会让用户感到很不爽，所以，现在很多网站都提供了UX让用户知道他的口令强度是什么样的（比如这个有趣的UX），这样可以让用户有一个选择，目的就是告诉用户——要想安全，先把口令设得好一点。
  • 千万不要明文保存用户的口令。正如如何管理自己的口令所说的一样，很多时候，用户都会用相同的ID相同的口令来登录很多网站。所以，如果你的网站明文保存的话，那么，如果你的数据被你的不良员工流传出去那对用户是灾难性的。所以，用户的口令一定要加密保存，最好是用不可逆的加密，如MD5或是SHA1之类的有hash算法的不可逆的加密算法。CSDN曾明文保存过用户的口令。（另，对于国内公司的品行以及有关部门的管理方式，我不敢保证国内网站以加密的方式保存你的口令。我觉得，做为一个有良知的人，我们应该加密保存用户的口令）
 
  • 是否让浏览器保存口令。我们有N多的方法可以不让浏览器保存用户名和口令。但是这可能对用户来说很不爽。因为在真实世界里谁也记得不住那么多的口令。很多用户可能会使用一些密码管理工具来保存密码，浏览器只是其中一种。是否让浏览器保存这个需要你做决定，重点是看一下你的系统的安全级别是否要求比较高，如果是的话，则不要让浏览器保存密码，并在网站明显的位置告诉用户——保存口令最安全的地方只有你的大脑。
  • 口令在网上的传输。因为HTTP是明文协议，所以，用户名和口令在网上也是明文发送的，这个很不安全。你可以看看这篇文章你就明白了。要做到加密传输就必需使用HTTPS协议。但是，在中国还是有很多网站的Web登录方式还在使用ActiveX控件，这可能成为IE6还大量存在的原因。我通常理解为这些ActiveX控件是为了反键盘记录程序的。 不过，我依然觉ActiveX控件不应该存在，因为在国外的众多安全很重要的站点上都看不到ActiveX的控件的身影。

用户登录状态

首先，我想告诉大家的是，因为HTTP是无状态的协议，也就是说，这个协议是无法记录用户访问状态的，其每次请求都是独立的无关联的，一笔是一笔。而我们的网站都是设计成多个页面的，所在页面跳转过程中我们需要知道用户的状态，尤其是用户登录的状态，这样我们在页面跳转后我们才知道是否可以让用户有权限来操作一些功能或是查看一些数据。 所以，我们每个页面都需要对用户的身份进行认证。当然，我们不可能让用户在每个页面上输入用户名和口令，这会让用户觉得我们的网站相当的SB。为了实现这一功能，用得最多的技术就是浏览器的cookie，我们会把用户登录的信息存放在客户端的cookie里，这样，我们每个页面都从这个cookie里获得用户是否登录的信息，从而达到记录状态，验证用户的目的。但是，你真的会用cookie吗？下面是使用cookie的一些原则。
  • 千万不要在cookie中存放用户的密码。加密的密码都不行。因为这个密码可以被人获取并尝试离线穷举。所以，你一定不能把用户的密码保存在cookie中。我看到太多的站点这么干了。
  • 正确设计“记住密码”。这个功能简直就是一个安全隐患，我觉得并不是所有的程序员都知道怎么设计这个事。一般的设计 是——一时用户勾选了这个功能，系统会生成一个cookie，cookie包括用户名和一个固定的散列值，这个固定的散列值一直使用。这样，你就可以在所有的设备和客户上都可以登录，而且可以有多个用户同时登录。这个并不是很安全。下面是一些更为安全的方法供你参考： （——更新 2011/08/26，原文中有些小错误，并且说的不清楚，重新调整了一下——）
1）在cookie中，保存三个东西——用户名，登录序列，登录token。 用户名：明文存放。 登录序列：一个被MD5散列过的随机数，仅当强制用户输入口令时更新（如：用户修改了口令）。 登录token：一个被MD5散列过的随机数，仅一个登录session内有效，新的登录session会更新它。 2）上述三个东西会存在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。 3）这样的设计会有什么样的效果，会有下面的效果， a）登录token是单实例登录。意思就是一个用户只能有一个登录实例。 b）登录序列是用来做盗用行为检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录token”，而真正的用户回来访问时，系统发现只有“用户名”和“登录序列”相同，但是“登录token” 不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况，于是，系统可以清除并更改登录序列 和 登录token，这样就可以令所有的cookie失效，并要求用户输入口令。并给警告用户系统安全。 4）当然，上述这样的设计还是会有一些问题，比如：同一用户的不同设备登录，甚至在同一个设备上使用不同的浏览器保登录。一个设备会让另一个设备的登录token和登录序列失效，从而让其它设备和浏览器需要重新登录，并会造成cookie被盗用的假象。所以，你在服务器服还需要考虑- IP 地址， a) 如果以口令方式登录，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为口令只有真正的用户知道。 b) 如果 IP相同 ，那么，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为是同一用户有同一IP（当然，同一个局域网里也有同一IP，但我们认为这个局域网是用户可以控制的。网吧内并不推荐使用这一功能）。 c) 如果 （IP不同 && 没有用口令登录），那么，“登录token” 就会在多个IP间发生变化（登录token在两个或多个ip间被来来回回的变换），当在一定时间内达到一定次数后，系统才会真正觉得被盗用的可能性很高，此时系统在后台清除“登录序列”和“登录token“，让Cookie失效，强制用户输入口令（或是要求用户更改口令），以保证多台设备上的cookie一致。
  • 不要让cookie有权限访问所有的操作。否则就是XSS攻击，这个功能请参看新浪微博的XSS攻击。下面的这些功能一定要用户输入口令：
1）修改口令。
2）修改电子邮件。（电子邮件通常用来找回用户密码，最好通发邮件或是发手机短信的方式修改，或者干脆就不让改一一用电子邮件做帐号名）
3）用户的隐私信息。
4）用户消费功能。
  • 权衡Cookie的过期时间。如果是永不过期，会有很不错的用户体验，但是这也会让用户很快就忘了登录密码。如果设置上过期期限，比如2周，一个月，那么可能会好一点，但是2周和一个月后，用户依然会忘了密码。尤其是用户在一些公共电脑上，如果保存了永久cookie的话，等于泄露了帐号。所以，对于cookie的过期时间我们还需要权衡。

找回口令的功能

找回口令的功能一定要提供。但是很多朋友并不知道怎么来设计这个功能。我们有很多找回口令的设计，下面我逐个点评一下。
  • 千万不要使用安全问答。事实证明，这个环节很烦人，而且用户并不能很好的设置安全问答。什么，我的生日啊，我母亲的生日，等等。因为今天的互联网和以前不一样了，因为SNS，今天的互联比以前更真实了，我可以上facebook，开心，人人网，LinkedIn查到你的很多的真实的信息。通过这些信息我可以使用安全问答来重设你的口令。 这里需要说一下 Facebook，Facebook的安全问答很强大，还要你通过照片认人，呵呵。
  • 不要重置用户的密码。因为这有可能让用户的密码遭到恶意攻击。当然，你要发个邮件给用户让其确认，用户点击邮件中的一个链接，你再重置。我并不推荐这样的方法，因为用户一般都会用笔记下来这个很难记的口令，然后登录系统，因为登录系统时使用了“记住密码”的功能，所以导致用户不会去修改密码，从而要么导到被写下来的密码被人盗取，要么又忘记了密码。
  • 好一点的做法——通过邮件自行重置。当用户申请找回口令功能的时候，系统生成一个MD5唯一的随机字串（可通过UID+IP+timestamp+随机数），放在数据库中，然后设置上时限（比如1小时内），给用户发一个邮件，这个连接中包含那个MD5的字串的链接，用户通过点击那个链接来自己重新设置新的口令。
  • 更好一点的做法——多重认证。比如：通过手机+邮件的方式让用户输入验证码。手机+邮件可能还不把握，因为手机要能会丢了，而我的手机可以访问我的邮箱。所以，使用U盾，SecureID（一个会变化的6位数token），或是通过人工的方式核实用户身份。当然，这主要看你的系统的安全级别了。

口令探测防守

  • 使用验证码。验证码是后台随机产生的一个短暂的验证码，这个验证码一般是一个计算机很难识别的图片。这样就可以防止以程序的方式来尝试用户的口令。事实证明，这是最简单也最有效的方式。当然，总是让用户输入那些肉眼都看不清的验证码的用户体验不好，所以，可以折中一下。比如Google，当他发现一个IP地址发出大量的搜索后，其会要求你输入验证码。当他发现同一个IP注册了3个以上的gmail邮箱后，他需要给你发短信方式或是电话方式的验证码。
  • 用户口令失败次数。调置口令失败的上限，如果失败过多，则把帐号锁了，需要用户以找回口令的方式来重新激活帐号。但是，这个功能可能会被恶意人使用。最好的方法是，增加其尝试的时间成本（以前的这篇文章说过一个增加时间成本的解密算法）。如，两次口令尝试的间隔是5秒钟。三次以上错误，帐号被临时锁上30秒，5次以上帐号被锁1分钟，10次以上错误帐号被锁4小时……但是这会导致恶意用户用脚本来攻击，所以最好再加上验证码，验证码出错次数过多不禁止登录而是禁lP。
  • 系统全局防守。上述的防守只针对某一个别用户。恶意者们深知这一点，所以，他们一般会动用“僵尸网络”轮着尝试一堆用户的口令，所以上述的那种方法可能还不够好。我们需要在系统全局域上监控所有的口令失败的次数。当然，这个需要我们平时没有受到攻击时的数据做为支持。比如你的系统，平均每天有5000次的口令错误的事件，那么你可以认为，当口令错误大幅超过这个数后，而且时间相对集中，就说明有黑客攻击。这个时候你怎么办？一般最常见使用的方法是让所有的用户输错口令后再次尝试的时间成本增加。
最后，再说一下，关于用户登录，使用第三方的 OAuth 和 OpenID 也不失为一个很不错的选择。

参考文章

]]> http://www.xa01.cc/46.html/feed 0 一根筋的第一篇文章 http://www.xa01.cc/13.html http://www.xa01.cc/13.html#comments Thu, 12 Jan 2012 09:17:50 +0000 一根筋 http://wp.hsw.cn/?p=13 http://www.xa01.cc/13.html/feed 1