使用ifttt背后的巨大风险
ifttt，是一个新生的网络服务平台，通过不同其他平台的条件来决定是否执行下一条命令。ifttt基于任务的条件触发，类似编程语言，让用户可以根据他们设计的流程设计一些小程序，让网络服务能够对某些行为作出反应。
ifttt 是一项创造性的应用，但是我和我的朋友们必须重视其背后隐藏的风险。
一、什么是 ifttt
如果这样就那样。this 称为 trigger，而 that 称为 action。每条 ifthisthenthat 称为 task。
ifttt 可以实现多种互联网应用的协同工作。（更多关于 ifttt 的介绍请访问其网站或 Google。）
为了实现 ifttt 的功能，ifttt 必须获得授权。
二、什么是授权
授权在此处指允许被授权的第三方应用获得一定的访问你的其它应用的权限。
例如，授权 ifttt访问 Gmail：第三方即 ifttt，而被授权访问的其它应用即 Gmail。
授权主要有 2 种方式：直接授权和 OAuth授权。
1、什么是直接授权
直接授权即直接向第三方提供用户名和密码。
以 eBuddy为例，为了在 eBuddy上使用 Gtalk等，必须直接在 eBuddy上输入用户名和密码。
这种方式的缺点显而易见，第三方在取得授权的同时获得了用户名和密码。
2、什么是 OAuth 授权
OAuth授权避免了将密码提供给第三方的缺陷。
以 Stack Overflow 为例，OAuth授权步骤如下：
1） 用户选择以 Google 账户登录。
2） 用户向 Google提供用户名和密码登录 Google 账户。如果已经登录，则自动跳过本步。
3） 用户查看并接受授权。
4） 登录成功。
3、OAuth 不是银弹
OAuth授权在原始应用中完成，因此第三方应用不会获得密码，然而，第三方应用仍然切实获得了被授予的所有权限。如果第三方应用被攻陷则攻击者也将获得相同的权限。
三、ifttt要求极其巨大的权限
作为参照，Stack Overflow 仅要求获得 Google 账户的电子邮件地址。
事实上，这几乎是 OAuth登录可以要求的最小权限。因为无论如何，若要将你和其他用 Google 账户登录的用户区分开来，必须获得你的Google 账户的唯一标识符，即电子邮件地址。如果 Stack Overflow 被攻陷，攻击者唯一所能获得的就是大量有效的电子邮件地址（可以用于发送垃圾邮件，但也仅此而已）。
ifttt要求 Gmail 的访问权。（从 ifttt可以实现的功能来看，该权限实际上为完全访问权，包括但不限于发送/接收/删除邮件，访问/修改通讯录等。） Google 也作出了更为谨慎的建议，但是对于非专业人员而言还是过于轻描淡写了。
ifttt的 Facebook 授权可以更直观的显示 ifttt 所要求的权限之大。
也就是说，ifttt为了实现与 Gmail 相关的 Task 必须获得 Gmail 的完全访问权限。这意味着如果 ifttt不幸被攻陷则我的 Gmail 账户也将同时沦陷。这意味着我必须将 Gmail 账户的安全从坚不可摧的 Google 转移到 ifttt。
更可怕的是，为了实现 ifttt的协同工作，我必须将我的 Facebook，Twitter，LinkedIn 在内的大量在线账户都交给 ifttt。
鸡蛋现在都在同一个篮子里，而且这个篮子还不一定牢靠。
以 ifttt用户协议中关于自身责任的段落作结。
文章来源：月光博客 转载请注明出处链接