GOS又在元旦发布了新的一年里有关Google的大预言，今年共预测了22条Google在2012年有可能发生的事情。事实上，仔细数一下，国内发布的仅有21条，其中有一条似乎是翻译漏掉了。
以下是笔者在补充了原有内容的基础上，按相似分类整理了一下，并加入了对应山寨市场的观点。这样对国内读者来说，看得更直观些。
Google 首页
1、Google的导航条菜单将改进为可自定义方式，提示栏也会支持一些新服务，这个计划原来只是在Google+实行。2011年，Google的首页导航条变更，已经让新浪、腾讯这些山寨大叔们趋之若鹜。2012年，这些山寨者将更加疯狂。
Google Doodle
2、Google Doodle Creator发布后，允许用户自己创建自己的doodle（即Google首页上会随着节日变化的小Logo），并且这些doodle可以像Google+一样分享给好友。腾讯可以学习分享，但要学到创建估计很难，除非把QQ涂鸦板合并，但那块的市场需求太小了，仅靠几位没有签约机制的大师级玩家明显不给力。
Google Goggles
3、还记得图片搜索应用吗？它将会应用于Google网页上的图片搜索中，并可分析图片并识别出其中的物体和人物。这是国内企业抄不来的东西，希望Google继续向着09年提出的那个透明平板的概念不断迈进。
Google Music
4、Google Music会变成订阅服务。这条内容目前我还无法直观的理解它。但Google Music一直是以正版音乐的方式给大家带来高音质的服务，只可惜该服务仅对美国用户提供，如果也想体验，只能用美国代理的方试访问了。音乐的订阅服务在国内其实也不少，表现最出色的就是音乐网站推出的电台服务。
Google Drive
5、Google Docs一直要改成Google Drive，即是将原来的文档存储编辑服务，向文件存储服务转变。等于是向网盘模式进军。改版后，也将更适合平板使用。据说这次改进将可以免费存储并同步任何文件。如果真是这样，我会果断放弃现在测试的所有国内网盘服务。
Google Instant Answers
6、Google Instant Answers发布，这是一个改进的即时解答服务，可以提供很详细回答的搜索服务。不知道能否对百度知道形成威胁，似乎雅虎已经抢先了一步。不过另一个Google汇问倒是不错，一个名不见经传的东西极具创意。很适合追求用户体验的产品需求调研使用。
Google history
7、Google history将会做更多的细节改进。Google的历史记录一直是资深用户推崇的产品，如果你只是偶尔登陆谷歌搜索，是无法体会在他背后那数以千万计服务器支持下的个性化服务。如果你使用谷歌有一年以上。你可以在谷歌历史记录看查看自己过去一年来的战绩。我允许谷歌来记录我的工作、生活、足迹、行为习惯，因为这些记录将会只针对我个人来提供全面的个性化服务。它安全、稳定，未经我的允许绝不对外授权。这就像为什么这么多有钱人喜爱瑞士银行一样，我的记录也是我一生的财富。这是山寨兄弟们永远也无法比肩的。
YouTube
8、HTML 5已逐渐取代HTML 4成为网页的新标准，YouTube的HTML 5播放器将成为默认设置。
9、Google会在YouTube中采用类似电视频道一样的结构。会是PPTV的模式吗？虽然国内不能访问YouTube，但这两条设置，足以让土豆、优酷等国内同行跟风。
Google+
10、Google+将拥有3亿用户，并与很多Google应用合并，Google甚至会用Chrome来强推Google+。Google曾在2011年12月底利用首页，AdWords等方式全面推广Chrome，如果再用他来推广Google+，也就不奇怪了。不过希望Google能改进一个人有多个邮箱的关联方式。对于这个我一直很困扰，以至于圈子总是很局限，不敢经易向外扩张。
11、Google+将提供可整合到博客里的留言系统。作为独立博客的管理建设者，一直致力于改善访客的用户体验，这将是我最为期待的一条改进。希望这个留言系统能够很好的与Wordpress整合，这将更加促进访客对评论的参与度，同时也会进一步提升垃圾信息的自动处理能力。
12、Google+ Answers发布，替代之前收购的Aardvark。在它成功推出后，能否将成为Google+中又一大热门应用/频道。会和知乎网一样的作用吗？只是不知道这个和前面提到的Google Instant Answers有何关系？
13、Google将会根据你的Google+信息流、Google Calendar日程表和你安装的一些Google应用来进行个性化的搜索。已知道的搜索依据有历史记录，Cookie，IP地址，终端平台等等。未来这些新的手段加入将让Google搜索更加强大，强大到让百度、盘古都无地自容了。
Google Chrome
14、Chrome会提供一个新的在线控制中心，他将允许你控制所有的在线同步数据（书签、密码、应用等），即便你不使用Chrome也能进行管理。这是一个值得期待的强化功能。一直对Chrome的同步机制很青睐，即时你在两台离线的电脑中同时处理书签里的项目，它也能在你在线时，把两台电脑中的记录合并起来。你不要再去一一核对是否有误删的行为，或是否有残留的信息。这点比早期使用傲游时要好很多。近年没用过国产浏览器，不知道他们是否已达到这个高度？至少目前的QQ五笔同步功能就很悲剧。
15、在Chrome中，将会发布一个新的在线音乐编辑服务，不知道这是否是一个大众化的功能。希望这只是尝试的开始，也期待语音功能的植入。
Google Android
16、Google将专注于改进Android应用的质量，比如提供更好的用户界面，一些新应用会要求更多的权限。目前Android发布了4.0，有消息说六个月后发布4.1。从功能上看，4.0比以往更加的人性化。很多以往忽略的细节，在这上面都实现了。权限管理也是在安全上的一个重要保证。小米和魅族已经在邀请用户测试自制系统for Android 4.0了，不知道百度易、阿里QQ、华为、联想等国产兄弟们是否做好了准备？
17、Android会有一个虚拟助理，比Siri更强大且可在桌面电脑上通过进入Google首页来使用。现在想尝试的用户可以试试Google语音输入法、Google语音搜索，这是一个可以支持汉语普通话和粤语发音的工具，在中文支持上不比Siri更强大吗？有了这个强大的后盾，再配上Google庞大的搜索体系，以及前面提到的几个Answers系统，世界上还有谁能超过它。或许百度说他也可以，希望不是baidu.jp的雅美蝶助理，如果真是，那还真可能有很大的市场。
Google Games
18、Google Games多人的游戏平台发布，他可以同步Chrome、Android和Google+里的所有游戏数据、用户排名，还可以和好友一起游戏。国内的应用商不少是修改了原版游戏的应用，并自建了排名系统，但还无法做到进度的多平台同步。Google这么做，将秒杀一切国内篡改行为，也将更好的支持原版游戏的发展。但如果封杀过度也是不行的，至少国内的不少汉化作品就值得称赞，且看未来产品的试用效果再作定论。
Google Store
19、Google会开类似Apple Store的实体店，销售Chromebook、Android手机、Google TV和各种纪念品。国内暂不指望了，不知道香港有没有这样的店？
20、Chrome Web Store的应用可被Android直接运行。Chrome上的运行一直不太稳定，或许是受服务器不在国内的影响，不知道Android上的Web Store是否也会这样？
Google 硬件设备
21、基于ARM的Chromebook和Google TV，比以前更便宜，且更成功。上个月突然发现长虹上海的旗舰店挂出主楼拍卖横幅？具体情况没有深究。三星、索尼都发布了Google TV战略，国内呢？难道也是在忙着举办拍卖会？
22、继三星之后，摩托罗拉将推出首款Google品牌的手机和平板。阿里推出首款QQ品牌的手机，戴尔推出首款百度品牌的手机，国产其实一直在努力。只不过Google是迈着大步前进，国产一直跟在他人的屁股后面，拾掇着前人落下的麦穗。
英文原文：Google Operating System:Predictions for Google's 2012（需翻墙）
中文翻译：sealango ，中文译文。
由拖库攻击谈口令字段的加密策略 阅读原文»
编者按：本文作者肖新光，网络ID江海客，安天实验室首席技术架构师，研究方向为反病毒和计算机犯罪取证等。如果有读者想要就安全问题和作者探讨，可以在微博@江海客。
我不得不惨痛地写在前面的是，这是一个安全崩盘的时代。过去一年，已经证实的遭遇入侵、并导致关键数据被窃或者被泄露的公司，包括索尼、世嘉这样的大型游戏设备厂商；包括花旗银行这样的金融机构，也包括了RSA这样的安全厂商。
这些事件中最令业界瞠目的是RSA被入侵，这直接导致多家工业巨头遭遇连锁的攻击，很多安全企业本身也使用RSA的令牌。比RSA弱小很多的荷兰电子认证公司DigiNotar已经在被入侵后，宣告破产。
就在2011年上半年，我们还是站在旁观者的立场讨论这些事情。但随即我们就遭遇了CSDN、多玩和天涯等等的数据泄露，其中最为敏感的，一方面是用户信息，另一个当然就是用户口令。由于身份实名、口令通用等情况影响，一时间人人自危。各个站点也陷在口水当中。
但实际上根据推断，这些入侵都是一些过去时，也就是说这些库早就在地下流传。同时流出，也许就是一个集体性的心理效应。
这种针对数据库记录的窃取，被一些攻击者称为"拖库"，于是有了一个自然而谐音的戏称"脱裤"。只是攻击者日趋不厚道，从前只是偷了人家的裤子，现在还要晾在大街上，并贴上布告说，"看，丫裤子上还有补丁呢"。
如果拖库是很难避免的，那么采用合理的加密策略，让攻击者拿到库后的影响降低到更小就是必要的。
明文存放口令的时代肯定是要结束了，但加密就安全么？
那些错误的加密策略
明文的密码固然是不能接受的，但错误的加密策略同样很糟糕。让我们看看下列情况。
简单使用标准HASH
我想起了一个90年代黑客笑话，有人进入一台UNIX主机，抓到了一个shadow文档，但破解不了。于是，他用自己的机器做了一个假的现场，故意留下这个shadow，最后看看别人用什么口令来试，最后再用这些口令与渗透原来的主机。遗憾的是，那时我们都把这个当成一个Joke，充其量回复一句"I服了you!"，而没有反思使用标准算法的问题。
目前来看，在口令保存上，使用最为广泛的算法是标准MD5 HASH。但实际上，很长时间，我们都忽略了HASH设计的初衷并不是用来加密，而是用来验证。系统设计者是因为HASH算法具有不可逆的特点所以"借"用其保存密码的。但其不可逆的前提假设，是明文集合是无限大的。但放到口令并不一样，口令的长度是受限的，同时其可使用的字符也是受限的。我们可以把口令的总数看正一个事实上的有限集（很难想象有人用100个字符作为口令）。
比如一个人的密码是"123456"，那么任何采用标准MD5加密的网站数据库中，其存放的都是这样一个MD5值：E10ADC3949BA59ABBE56E057F20F883E
由于密文均相同，加之HASH算法是单向的，因此攻击者较早使用的方法就是"密文比对+高频统计"后生成密文字典来攻击，由于绝大多数网站和系统的加密实现，都是相同明文口令生成相同的密文，因此，那些有高频密文的用户就可能是使用高频明文口令的用户。攻击者一方面可以针对标准算法来制定高频明文的对应密文档来查询，另一方面，对于那些非标准算法，高频统计攻击的方法也非常常见。
但查表攻击迅速压倒高频统计的原因，正是从2000年开始陆续有网站规模性明文口令泄漏事件开始的。在过去每一次明文的密码泄漏事件，攻击者都会把使用MD5、SHA1等常见HASH算法加工成的口令与那些采用HASH值来保存的库进行应对。
随着超算资源的廉价、GPU的普及、存储能力的增长，一个不容忽视的威胁开始跃上桌面，那就是，这些巨大的HASH表已经不仅仅是基于泄漏的密码和常见字符串字典来制作，很多攻击者通过长期的分工协作，通过穷举的方式来制作一定位数以下的数字字母组合的口令串与多种算法加密结果的映射结果集，这些结果集从百GB到几十TB，这就是传说中的彩虹表。
HASH的单向性优势在此已经只有理论意义，因为HASH的单向性是靠算法设计保证的，使用一个有限集来表示一个无限集，其必然是不可逆的。但攻击者是从查表来完成从HASH到口令明文的还原的。因此其算法的单向性也就失去了意义。
联合使用HASH
一些人误以为，HASH不够安全是因为HASH算法的强度问题，因此把MD5或者SHA1联合使用，其实这是毫无价值的（只是徒耗了存储资源）。如上面所说，HASH的不安全性在于大量口令与其HASH值的对应关系早已经被制作成彩虹表。只要你联合使用HASH的算法其中之一在彩虹表中，自然就可以查到了。
同理，那种采用"MD5的头+SHA的尾"之类的，或者采用其他的混合两个值的方法，也一样是没有意义的。因为攻击者可以很容易的观察到这种组合方法的规律，经过拆解后继续按照查表法破解。
自己设计算法
我一向认为，既然我们不是一个密码学家，而是工程师、程序员，那么放着现成的好东西不用，自己开发加密算法是相当愚蠢的事情。我相信很多程序员都遇到过挖空心思想到了一个"新算法"，然后发现早在某篇20世纪80年代的数学论文里，早就提出了相关算法的情况。
况且在开源时代，很多算法不仅被实现和发布了，而且还经历了长期的使用推敲。这些都是自己设计、自己实现无法比拟的。
关于自主设计的算法的不安全性，有一个事情深达我脑海。记得我在证券系统工作时，由于刚刚接手收购来的营业部，需要把一个clipper编译的柜台系统进行迁移，但原来的开发商已经联系不到了，当时我们制定了两条路，一位高手李老师负责，进行数据破解，看看是否能还原明文，而我则负责破解算法，如果李老师那边走不通，则我需要解出算法，把000000～999999之间的数字全部加密，然后用密文做碰撞（那时证券都是柜台操作，没有网上炒股，密码都是柜台用数字键盘输入的）。
由于原来的开发者加了一点花活，我这边还没有眉目，那边旁观李老师的工程师，已经发出了惊叹之声，我跑过去，只见李老师根据构造的几个密码的加密结果，在纸上汇出了长得非常像杨辉三角的东西。不到半个小时，李老师已经连解密程序一起做好了。
上面故事的目的是说明，自己设计算法无论怎么自我感觉良好，看看美国官方遴选算法的PK过程大家就明白了，我们无法和全球数学家的智慧组合对抗。
因此自己设计实现算法，并不是一个好主意。这其中也包括，在实现上会不会有类似输入超长字符串会溢出一类的Bug。
单独使用对称算法
在标准HASH安全破灭后，又看到有人呼吁用AES，其实这不是一个好建议。AES这些对称算法，都不具备单向性。网站被攻击的情况是复杂的，有的是只有数据库被拖，有的则整个环境沦陷。而后者AES密钥一旦被拿到，密码就会被还原出来，这比被查表还要坏。
当然我们还看到一种把AES当HASH用的思想，就是只保留一部分的AES加密结果，只验证不还原。但其实这样的AES并不见得比HASH有优势。比如即使攻击者没有拿到密钥，也只拖了库，但攻击者自己在拖库之前注册了足够多的帐号，并使用大量不同的短口令。那么就拿到了一组短明文和对应密文。而此时密钥是完全有可能被分析出来的。
而使用DES、AES一类的算法，还是使用标注HASH，还是自己设计算法，如果不解决不同用户相同口令密文相同的统计性缺陷，那么攻击者即使拿不到密钥，也都可以先把一些高频口令用于帐号注册，拖库后进行密文比对。就可以锁定大量的采用常见口令的用户。
加"一粒盐"
其实很多同仁都指出了哈希加盐法（HASH+SALT），是问题的解决之道，所谓加盐（SALT）其实很简单，就是在生成HASH时给予一个扰动，使HASH值与标准的HASH结果不同，这样就可以抗彩虹查表了。
比如说，用户的密码是123456，加一个盐，也就是随机字符串"1cd73466fdc24040b5"，两者合到一起，计算MD5，得到的结果是6c9055e7cc9b1bd9b48475aaab59358e。通过这种操作，即便用户用的弱密码，也通过加盐，使实际计算哈希值的是一个长字符串，一定程度上防御了穷举攻击和彩虹表攻击。
但从我们审计过的实现来看，很多人只加了"一粒盐"。也就是说，对同一个站点，不同用户使用同一个密码，其密文还是相同的。这就又回到了会遭遇高频统计攻击，预先注册攻击等问题。
口令的安全策略
在传统密码学家眼中只有一种加密是理想的，那就是"一次一密"，当然事实上这是不可能的。但如果我们套用这种词法，我们也可以说，口令安全策略的理想境界，我们可以称为单向、一人一密、一站一密。
单向：标准HASH算法的价值尽管在这个场景下，已经被推倒，但其单向性的思想依然是正确的，口令只要是能还原的，就意味着攻击者也能做到这一点，从而失去了意义，因此使用单向算法是必须的。
一人一密：同一个站点设置同样口令的不同用户，加密生成的密文内容并不相同。这样就能有效的应对结果碰撞和统计攻击。采用字典的攻击的方法基本是不收敛的。
一站一密：仅仅保证一人一密是不够的，还要保证使用同样信息、同样口令去注册不同网站的用户，在不同站点的口令加密结果是不同的。鉴于有大量用户用同样的信息、同样的口令去注册不同网站，如果能做到这一点，流失出的库信息会进一步打折扣。而攻击者基本会放弃生成密文字典的尝试。
实现这些说起来很简单，依然是HASH+SALT，关键在于每个站点要有不同的SALT，每个用户要有不同的盐。
但如果攻击者不是只获得了库，而且也获得了相关的加密参数和密钥，我们就要看到攻击者依然可以自己通过相关参数和密钥调用算法，使用常见密码对每个用户生成一遍密文，然后是否有匹配。当然我们可以看到由于"每人一粒盐"的策略，攻击者所需要的计算代价已经变化了，如果过去只需要生成一次的话，那么假如使用100个常见的口令来做，那么只要口令没有碰撞到，对每个用户都要做100次加密操作。但这也是不容小觑的威胁。因为有太多用户喜欢使用那些常见口令。
因此，设定一个密码禁用表，让用户避免使用常见口令，可以进一步让破解者付出更大的代价，从而最终导致计算资源不收敛而放弃，也可以是一个可以考虑的策略。但也需要提醒WEB开发者的是，这样会增大你的用户忘记口令的风险。
另外，用户是否有把密码设置为123456的自由呢，我想只要不是国防、航天、涉密系统和有安全要求的企业环境，如果只是潜潜水、骂骂街，网站或许提醒用户就好，但也许并不需要做成强制策略。
具体的实现
了这么多，怎么来具体实现一站一密、一人一密的策略呢，2011年12月23号，我们想到与其空洞的说教算法原理和策略，不如提供一些非常直接的示例程序和文档。
因此同事们写了一份名为Antiy Password Mixer（安天密码混合器）的开源代码，当然这没有什么技术含量，也不是"自有知识产权的国产算法"，有的只是对实现较好的流行开源算法包的示范性使用而已，目前的Python版本，也只有三百行代码，在其中封装了RSA和HASH+SALT使用，并给出了具体的在初始化、注册和认证时如何使用的范例文档。
大家可以在这里找到这个东西：http://code.google.com/p/password-mixer/
当然，就像我们惋惜很多应用开发者缺乏对安全的重视一样，其实我们并不懂应用开发，所以这些代码和文档对于应用开发者看来可能非常丑陋。尽管可能被鄙视，我们还是要打开门，证明安全团队并不保守。
而同时，我们必须与应用走得更近，因为我们也在使用着这些自认为违反了某种安全原则的应用，却因为不是其开发者而无法改造它们。
过去的10余年，
