第四幕
第二天早上在Euripides的办公室。Athena来敲门。
Euripides: 你今早有黑眼圈了。
Athena: 好了，你知道的。又是一个漫漫长夜。
Euripides: 你解决了重演的问题了吗?
Athena: 我想是的。
Euripides: 请坐。
她坐下了。
Athena: 照旧，我重申一下问题。票是可重用的，在一个限定的时间内(八小时)。如果谁偷了你的票并在它失效之前使用，我们毫无办法。
Euripides: 确实如此。
Athena: 我们可以把这个问题理解为设计一种别人无法重用的票。
Euripides: 但这样的话你每次用新服务时都要取一张新票。
Athena: 对。但那是很笨的解决办法。(稍顿。)啊，我怎样继续我的讨论呢?(她沉思了一会儿)。
好的，我要重述一个问题，看有什么必须条件。网络服务必须能够证明使用票的人就是票上所申明的人。 我来顺着认证的过程再走一遍，这样我就可以演示我的解决方案。 我现在想用一个网络服务。我通过启动工作站上的客户端来使用它。客户端送三样东西给服务器:我的名字，我的工作站的网络地址，适当的服务票据。 这张票包含了申请这张票的人的名字和他(她)申请时所使用的工作站的地址。它也包含了票的有效期和时间戳。所有这些信息都被服务的密码加密了。
我们现在的认证模式基于以下的测试:
服务能对票解密吗?
票在有效期以内吗?
票中的名字和地址与申请者的名字和地址匹配吗?
这些测试证明了什么?
第一个测试证明了票是不是来自Charon.如果票不能被适当的解密，说明票不是来自真正的Charon.真正的Charon会用服务的票来加密票。Charon和服务是唯一知道服务密码的两个实体。如果票被成功的解密，服务知道它来自于真的Charon.这个测试防止了有人伪造假票。
第二项测试检查票是否在有效期以内。如果过期，服务拒绝。这项测试阻止使用旧票，因为票可能是偷来的。
第三项测试检查票的用户名和地址是否匹配请求者的用户名和地址。如果测试失败，说明使用者使用了别人的票。这张票当然被拒绝。如果名字和地址匹配，这个测试证明了什么?什么也没有。票可以被偷走，用户名和网络地址都可以被改变，如果需要的话。正如我昨天指出的那样，票可以在有效期内被盗用。因为服务不能确定票的发送者是不是合法用户。
服务之所以无法判断是因为它没有与用户共享一个秘密。这样看。假如我正在埃尔斯诺尔(哈姆雷特中的城堡)值勤，你打算来和我换班。但除非你说出正确的口令，否则我不会与你换班的。我们共享了一个秘密。它可能是某人为所有值勤的人所设的。
于是昨晚我就在想，为什么Charon不能为合法用户与服务之间设一个口令呢?Charon发一份口令给服务，同时发一份给用户。当服务从用户那里收到一张票，它可以用这个口令检验用户的合法性。
Euripides: 等一下。Charon如何同时发两份口令?
Athena: 票据的拥用者从Charon的回应中得到口令，像这个样子:
她在黑板上写下了:
Charon的回应-[口令票]
服务从票中获取口令。票的格式如下:
票-{口令:用户名:地址:服务名:有效期:时间戳｝
当你要请求服务时，客户端程序生成一个‘验证器’。验证器包含了你的名字和你工作站的地址。客户端用口令把这些信息加密，口令是你请求票据时得到的。
验证器-{用户名:地址｝用口令加密。
生成验证器以后，客户端把它和票一起送给服务。因为服务没有口令，所以它不能解密
验证器。口令在票中，于是服务先解开票。
解开票以后，服务得到以下的东西:
票的有效期和时间戳;
票的拥有者的名字;
票拥有者的网络地址。
口令。
服务检查票是否过期。如果一切正常，服务就用口令去解验证器。如果解密没有问题，服务将会得到一个用户名和网络地址。服务用它们去和票里的用户名和网络地址去匹配，如果正确，那么服务认为票的发送者确实是票的真实拥有者。
Athena暂停了一下，清了清喉咙，喝了点咖啡。
我认为口令验证器的机制解决了盗用的问题。
Euripides: 也许。但我想。。。攻击这个系统我必须有验证器。
Athena: 不。你必须同时拥有验证器和票。没有票，验证器是没有用的。解开验证器必须要有口令，服务必须解开票才会有口令。
Euripides: 好，我明白了，你是说当客户程序联系服务时，它同时送上票和验证器?
Athena: 是的，我就是这个意思。
Euripides: 如是真是这样，什么可以阻止我把票和验证器都偷走呢?我可以写一个程序，如果我拥有了票和验证器，我就可以一直使用它至有效期结束。我只需改变我的用户名和工作站的地址。不是吗?
Athena: (咬了咬她的嘴唇)是的。多沮丧啊。
Euripides: 等等，等等，等等!这不难解决。票在有效期内是可重用的，但那并不意味着验证器是可重用的。假设我们设计了验证器只可以被用一次。这可以吗?
Athena: 好，也许。我样来想一下，客户端程序生成验证器，然后把它和票一起送给服务。真的票和验证器比你拷贝的要先到。如果验证器只能被用一次，你的拷贝就失效了。 啊，这就对了。我样现在需要做的就是发明一和方法使得验证器只能被用一次。
Euripides: 没问题。我们把有效期和时间戳放在上面。假设每个验证有两分钟的有效期。当你想用一个服务时客户端生成验证器，标上当前的时间，把它和票一起送给服务。 服务器收到了票和验证器，服务器解开验证器，它检查验证器的时间戳和有效期。如果验证器还没失效，所有其它的检查都通过了，那么服务器就认为你通过了认证。 假设我通过网络拷贝了一份验证器和票，我必须改变我的工作站的网络地址和我的用户名，这差不多要用几分钟。那是非常苛刻的要求，我不认为是可能的，除非。。。 嗯，有一个潜在的问题。假设不是在网络的转输中拷贝到票和验证器，我拷贝了一份原始的从Charon而来的包，这个包是你向Charon请求时的回应。 这个包，有两个口令在里面:一个是你的，一个是服务的。服务的口令隐藏在票中，我取不到，但另一个呢?那个你用来生成验证器的? 如果我得到了口令，我就用它来建自已的验证器，如果我能建自已的验证器，我就能攻破你的系统。
Athena: 这就是我昨晚所想的，但是当我顺着票的处理过程一想，发现那样偷走验证器是不可能的。
你在一台工作站坐下，用kinit程序得到你的票据授权票。kinit要求输入用户名，你输入以后，kinit把它送给Charon.Charon用你的名字查找你的口令，然后生成一张票据授权票。作为处理的一部分，Charon生成了一个你与票据授权服务共享的口令。Charon把口令和票据授权票一起送给你，并且在发关之前用你的口令将它加密。
Charon送出了包。某人取得了这个包，但他们无能为力因为它是用你的口令加过密的。特别是，无人可以偷走票据授权服务的口令。 kinit收到了票据包并要求你输入你的口令。如果你输入正确的口令，kinit解开包取出了口令。 现在你注意kinit的处理，你去取你的邮件。你打开邮件客户端。这个程序查找一张邮件服务的票但没有找到(你还没取过你的邮件)。客户端用票据授权票去申请一张邮件服务的票。 客户端为票据授权的过程生成了一个验证器，并用票据授权的口令把验证器加密。客户端把验证器送给了Charon，票据授权票，你的名字，你的工作站的地址，邮件服务的名字。票据授权服务收到了这些东西，并通过了认证检查。如果一切都通过，票据授权服务将会得到那个与你共享的口令。现在票据授权服务为你生成了一张邮件服务的票，在这个过程中生成了一个你与邮件服务共享的口令。票据授权服务把这些东西打成包送给你的工作站。包里有票和口令。在送包之前，票据授权服务用票据授权的口令把包加密。做完以后，包被送出去。 这样邮件服务票的包通过网络被送了出来。假设网络上的某人将它复制了一份。他不幸的发现包是用票据认证的口令加过密的。既然无法解密，他就不能得到邮件口令。没有口令，他就不能使用任何在网络上传送的邮件服务的票。 现在我觉得我们是安全的。你认为呢?
Euripides: 也许吧。
Athena: 也许!你就只会说这个吗!
Euripides: (大笑)别在意。你现在应该知道我处理问题的方式了。我猜我和你昨晚都工作到了半夜。
Athena: 哼!
Euripides: 好的，大半夜。实际上，这个系统似乎是完全可行的。口令的方案解决了我
昨晚想到的一个问题:相互验证的问题。
稍顿。
我说一下好吗?
Athena: (有点冷淡)请便。
Euripides: 你真好。(Euripides清了清自已的嗓子)昨晚，当口令和验证器在我脑子里转的时候，我想去找出这个系统新的问题，我想我发现了一个很严重的问题。我下面就演示一下。
