Assuring the security of the MetroCard system is a multi-layered effort encompassing technical solutions and procedures aimed at preventing unauthorized access and detecting unauthorized activities during the course of normal operations. The activity of the system is monitored for unusual behavior at many points in the operation. Procedures are in place to quickly respond to unusual occurrences in ways that not only limit risk, but can lead to immediate remedial action. NYC Transit is in the process of completing an extensive effort to become compliance [sic] with Payment Card Industry (PCI) rules relating to credit/debit transactions. While directly related to the business of accepting bank cards, these rules have also helped NYCT further harden its automated fare collection system against potential unauthorized access to sensitive transaction information by hackers and employees. In regards to your security related questions, which we will not address here in any detail, it is safe to say network environment is constructed in such a way that the serious security implications and vulnerabilities you reference do not exist.

The Wall Street Journal reported how this gambit played out in Colombia:

"The plan had a chance of working because, for months, in an operation one army officer likened to a 'broken telephone,' military intelligence had been able to convince Ms. Betancourt's captor, Gerardo Aguilar, a guerrilla known as 'Cesar,' that he was communicating with his top bosses in the guerrillas' seven-man secretariat. Army intelligence convinced top guerrilla leaders that they were talking to Cesar. In reality, both were talking to army intelligence."

In a man-in-the-middle attack, the attacker inserts himself between two communicating parties. Both believe they're talking to each other, and the attacker can delete or modify the communications at will. The Wall Street Journal reported how this gambit played out in Colombia.

This ploy worked because Cesar and his guerrilla bosses didn't know each other well. They didn't recognize each others' voices, and didn't have a friendship or shared history that could have tipped them off about the ruse. Man-in-the-middle is defeated by context, and the FARC guerillas didn't have any.

And that's why man-in-the-middle, abbreviated MITM in the computer security community, is such a problem online: Internet communication is often stripped of any context. There's no way to recognize someone's face. There's no way to recognize someone's voice. When you receive an e-mail purporting to come from a person or organization, you have no idea who actually sent it. When you visit a website, you have no idea if you're really visiting that website. We all like to pretend that we know who we're communicating with -- and for the most part, of course, there isn't any attacker inserting himself into our communications -- but in reality, we don't. And there are lots of hacker tools that exploit this unjustified trust, and implement MITM attacks.

Even with context, it's still possible for MITM to fool both sides -- because electronic communications are often intermittent. Imagine that one of the FARC guerillas became suspicious about who he was talking to. So he asks a question about their shared history as a test: "What did we have for dinner that time last year?" or something like that. On the telephone, the attacker wouldn't be able to answer quickly, so his ruse would be discovered. But e-mail conversation isn't synchronous. The attacker could simply pass that question through to the other end of the communications, and when he got the answer back, he would be able to reply.

This is the way MITM attacks work against web-based financial systems. A bank demands authentication from the user: a password, a one-time code from a token or whatever. The attacker sitting in the middle receives the request from the bank and passes it to the user. The user responds to the attacker, who passes that response to the bank. Now the bank assumes it is talking to the legitimate user, and the attacker is free to send transactions directly to the bank. This kind of attack completely bypasses any two-factor authentication mechanisms, and is becoming a more popular identity theft tactic.

There are cryptographic solutions to MITM attacks, and there are secure web protocols that implement them. Many of them require shared secrets, though, making them only useful in situations where people already know and trust each other.

The NSA-designed STU-III and STE secure telephones solve the MITM problem by embedding the identity of each phone together with its key. (The NSA creates all keys and is trusted by everyone, so this works.) When two phones talk to each other securely, they exchange keys and display the other phone's identity on a screen. Because the phone is in a secure location, the user now knows who he is talking to, and if the phone displays another organization -- as it would if there were a MITM attack in progress -- he should hang up.

Zfone, a secure VoIP system, protects against MITM attacks with a short authentication string. After two Zfone terminals exchange keys, both computers display a four-character string. The users are supposed to manually verify that both strings are the same -- "my screen says 5C19; what does yours say?" -- to ensure that the phones are communicating directly with each other and not with an MITM. The AT&T TSD-3600 worked similarly.

This sort of protection is embedded in SSL, although no one uses it. As it is normally used, SSL provides an encrypted communications link to whoever is at the other end: bank and phishing site, alike. And the better phishing sites create valid SSL connections, so as to more effectively fool users. But if the user wanted to, he could manually check the SSL certificate to see if it was issued to "National Bank of Trustworthiness" or "Two Guys With a Computer in Nigeria."

No one does, though, because you both have to remember and be willing to do the work. (The browsers could make this easier if they wanted to, but they don’t seem to want to.) In the real world, you can easily tell a branch of your bank from a money changer on a streetcorner. But on the internet, a phishing site can be easily made to look like your bank's legitimate website. Any method of telling the two apart takes work. And that's the first step to fooling you with a MITM attack.

Man-in-the-middle isn't new, and it doesn't have to be technological. But the internet makes the attacks easier and more powerful, and that's not going to change anytime soon.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.

Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.