TWI394420B

TWI394420B - 用於線上交易的ｉｐ位址安全多通道認證

Info

Publication number: TWI394420B
Application number: TW98129595A
Authority: TW
Inventors: Paul Lin
Original assignee: F2Ware Inc
Priority date: 2009-09-02
Filing date: 2009-09-02
Publication date: 2013-04-21
Also published as: TW201110652A

Description

用於線上交易的IP位址安全多通道認證

本發明涉及IP位址安全多通道認證方法，更具體地說，涉及用於使用應用伺服器和認證伺服器的用戶的多因素認證方法。

包括金融交易和其他機密交易的線上交易長期被應用于允許兩方進行商務活動。在典型的線上交易中，用戶(例如像銀行客戶)使用電腦上的用戶端瀏覽器來與應用伺服器(例如像由銀行操作的銀行業務(banking)伺服器)建立一個會話並實現所希望的交易(例如像將金錢從一個帳戶轉移到另一個帳戶)。因為線上交易經常通過網際網路來進行，而網際網路是由路由器、服務器、中繼線等組成的全球公共網路，所以安全總是首要問題。

線上交易安全的風險包括未經授權的第三方可能能夠獲得認證資訊(例如用戶標識和密碼)，而且隨後可能能夠進行對用戶不利的欺詐交易的風險。例如，如果從任意電腦登錄到銀行只需要用戶標識和密碼，那麼獲取用戶的用戶標識和密碼的第三方將可以從任何地方登錄並執行用戶可以執行的任意交易，例如包括在未經授權的第三方的控制下將金錢轉移到一個帳戶。

用戶標識和密碼的竊取可以通過例如木馬(通常是指駐留于用戶端的應用程式，所述應用程式在用戶標識和密碼被用戶鍵入時監聽用戶標識和密碼並將所述用戶標識和密碼轉發給欺詐者)的技術來實現。另一種技術涉及網路仿冒(phishing)。在示例網路仿冒的情景中，用戶可能接收一封電子郵件，其具有請求用戶登錄聲稱屬於一個用戶之前與其進行過商務活動的商人的網站(例如，XYZ銀行)的消息。所述電子郵件包含要由用戶啟動的鏈結。如果用戶啟動由網路仿冒電子郵件提供的鏈結，那麼一個網站被呈現給用戶，所述網站具有與真網站(例如，XYZ銀行)幾乎相同的外觀和感覺。然而，該網站實際上屬於欺詐者。用戶輸入到模仿真網站的外觀和感覺的欺詐者的網站中的資訊將被記錄，並隨後被用於對用戶實施欺詐。舉例說明，欺詐者可以利用所輸入的用戶標識和密碼來登錄用戶的帳戶並執行未經授權的金錢轉移。

一種防止像木馬或網路仿冒這樣的欺詐的方法涉及使用第二因素認證，其中認證需要附加資訊。由於起第一認證因素的作用的用戶標識/密碼，應用伺服器(例如，銀行應用)也需要基於正用於訪問的裝置或用戶擁有的硬體的附加認證。例如，第二因素認證可能需要硬體權標(token)或ATM卡。軟體也可以被用作第二因素認證。

上面提到的僅僅觸及一些寬泛的類別的線上交易風險。還有當前存在的其他風險，但它們是公知的並且在此將不作過多的說明。此外，技術被不斷地發展以防止線上欺詐。相應地，欺詐者不斷發展技術以戰勝包括認證方案在內的新實現的安全措施。

鑒於當前存在的和/或回應於安全措施而顯現出來的交易風險，需要改進的認證技術。

因此，本發明提供用於使用應用伺服器和認證伺服器的用戶的多因素認證的方法，來解決上述問題。

根據本發明的一個方面，提供用於使用應用伺服器和認證伺服器的用戶的多因素認證的電腦實現方法，所述用戶與所述應用伺服器和所述認證伺服器相互作用，所述用戶利用用戶瀏覽器程式與所述應用伺服器和所述認證伺服器中的至少一個進行通信，所述方法包括：利用所述應用伺服器使用第一因素認證證書認證所述用戶；從所述應用伺服器向所述認證伺服器提供所述用戶之第一源IP位址，其中該第一源IP位址係為所述用戶向所述認證伺服器提交所述認證請求時與所述第一因素認證證書一併傳送的關聯資訊；指示所述用戶在所述用戶瀏覽器程式和所述認證伺服器之間建立獨立通信通道以執行附加認證；比較所述第一源IP位址和與利用所述獨立通信通道的、從所述用戶到所述認證伺服器的通信相關聯的第二源IP位址；以及如果所述第一源IP地址與所述第二源IP地址不匹配，則所述用戶的認證失敗。

根據本發明的另一方面，提供用於使用應用伺服器和認證伺服器的用戶的多因素認證的電腦實現方法，所述用戶利用用戶瀏覽器程式與所述應用伺服器和所述認證伺服器中的至少一個相互作用，所述方法包括：從所述應用伺服器接收與從所述用戶瀏覽器程式到所述應用伺服器的認證請求相關聯的第一源IP位址；從所述用戶瀏覽器程式接收請求以利用獨立通信通道來在所述用戶瀏覽器程式和所述認證伺服器之間執行附加認證，所述獨立通信通道與被用於在所述應用伺服器和所述認證伺服器之間進行通信的通信通道獨立；比較所述第一源IP位址和與在所述認證伺服器和所述用戶瀏覽器程式之間執行所述附加認證的所述請求相關的第二源IP位址；以及如果所述第一源IP地址與所述第二源IP地址不匹配，則所述用戶的認證失敗。

現在將參照如附圖中所舉例說明的幾個實施例來詳細描述本發明。在下面的描述中，為了提供對本發明的全面理解而詳盡地解釋大量的具體細節。然而對本領域技術人員來說顯而易見的是，可以實踐本發明而不用這些具體細節中的某些或全部。在其他情況下，為了避免不必要地使本發明模糊不清，沒有詳細地描述公知的處理步驟和/或結構。

以下描述各種實施例，包括方法和技術。應該記住，本發明也可以涵蓋包括存儲用於執行創造性技術的實施例的電腦可讀指令的電腦可讀介質的製造產品。例如，電腦可讀介質可以包括半導體、磁、光磁、光或者其他形式的用於存儲電腦可讀代碼的電腦可讀介質。進一步地，本發明還可以涵蓋用於實踐本發明的實施例的裝置。這種裝置可以包括專用於和/或可編程用於執行與本發明實施例有關的任務的電路。這種裝置的例子包括在適當編程情況下的通用電腦和/或專用計算設備，並且可以包括適合於與本發明實施例有關的各種任務的電腦/計算設備和專用/可編程電路的組合。

在多通道認證方案中，用戶不僅需要訪問應用伺服器(例如，上面提到的XYZ銀行)，還需要為了認證自己的目的在獨立通信***問認證伺服器。簡單來說，多通道認證方案包含三方：用戶、應用伺服器和認證伺服器。

總的來說，用戶首先登錄應用伺服器(例如，XYZ銀行)並建立他的第一因素認證證書(例如，用戶標識和密碼)。一旦滿足第一因素認證證書，應用伺服器就聯繫認證伺服器來確定用戶是否是多通道認證服務的訂戶。如果用戶是多通道認證服務的訂戶，那麼認證伺服器(經由應用伺服器)給用戶提供HTML指令，來指示用戶的用戶端瀏覽器(例如，使用AJAX技術)建立與認證伺服器的獨立通信通道。在該獨立通信通道中的通信可以通過使用將如稍後討論的加密技術來使其安全。在該獨立第二通道上的用戶的瀏覽器和認證伺服器之間的安全通道執行附加認證。

在一個實施方案中，用戶端瀏覽器和認證伺服器都知道一個共用秘密。所述共用秘密的一部分在這裏被稱為“已知事實”或KF，其為認證伺服器和用戶端瀏覽器兩者所知。所述已知事實可以是由認證伺服器和用戶端瀏覽器彼此都指明為“已知的”任意資料、資訊或事實。例如，已知事實可以是由商人指明為用於附加認證的共用秘密的某特殊資料欄位(例如，帳號或電話號碼)。

在認證伺服器和用戶端瀏覽器之間的認證是一種雙向加密認證。如果用戶端瀏覽器可以利用共用秘密(其為認證伺服器和用戶端瀏覽器兩者所知)向認證伺服器驗證自己，並且如果認證伺服器可以利用共用秘密向用戶端瀏覽器驗證自己，那麼認證被認為是成功的。為了交流所述已知事實，通過在用戶最初向多通道認證系統註冊時的啟動過程(用於每個裝置的一次性處理)。

期間利用帶外(out-of-band)通信通道(例如，電子郵件、電話等)增強安全性。例如，電子郵件可以被發送給用戶來將對於用戶的已知事實的字母數位串提供給用戶，以將所述用戶綁定到他的證書。

儘管多通道認證技術可以提供針對某些形式的安全風險的附加安全措施，但是被稱為中間人(man-in-the-middle，MITM)的攻擊形式已經帶來了挑戰。中間人攻擊指的是欺詐者使用連接到用戶端並連接到應用伺服器的裝置，通過中繼請求和回應，來竊取資料和/或裝作代表用戶端瀏覽器以實現欺詐的目的。換句話說，中間人裝置可以看到所有的通信(traffic)並執行可以由用戶端瀏覽器所執行的大部分或所有的動作，例如包括修改SSL協定資訊。

因此，即使使用多通道認證方案，在用戶端瀏覽器成功地實現與認證伺服器的附加認證之後，也仍然可能洩露機密的通信，因為中間人裝置嵌入在用戶端瀏覽器和應用伺服器(例如，XYZ銀行)之間的通信中。在本發明的一個或多個實施例中，提出了IP位址安全多通道認證(IPAS-MCA)技術和裝置。一般而言，AS-MCA技術檢測在用戶端瀏覽器和應用伺服器之間用於通信的IP源位址與在安全認證通道上的在用戶端瀏覽器和認證伺服器之間用於通信的源IP位址是否相同。如果兩個IP位址不同，則懷疑有未被授權的中間人裝置，並且認證將失敗。

參考附圖和下述的討論，可以更好地理解本發明的特徵和優點。圖1示出了典型的多通道認證方案，其中用戶端瀏覽器102利用應用伺服器104和認證伺服器106兩者來進行認證。首先，用戶端瀏覽器102聯繫應用伺服器104以請求認證(130)。在這一階段，像傳統上那樣，認證一般使用用戶標識和密碼組合。如果根據用戶標識/密碼認為用戶是有效用戶，則確定用戶端瀏覽器102的用戶是否是多通道認證系統的訂戶。可以由認證伺服器106通過例如針對它的訂戶資料庫核對用戶的身份(其被應用伺服器104轉發(132)到認證伺服器106)來做出決定。

如果確定用戶是多通道認證系統的訂戶，那麼為了執行進一步的認證的目的，認證伺服器106經由應用伺服器104來向用戶端瀏覽器102發送(134)指令(例如以HTML代碼的形式)以指示用戶端瀏覽器102建立與認證伺服器106的安全通信通道。

利用由認證伺服器106提供的指令(其被經由應用伺服器104發送給用戶端瀏覽器102)，用戶端瀏覽器102接著建立到認證伺服器106的安全通信通道(136A/136B)。經由安全通信通道，用戶端瀏覽器102和認證伺服器106可以執行進一步的認證。認證一般是雙向的，用戶端瀏覽器向認證伺服器驗證自己，反之亦然。

一般說來，附加認證可能需要只有用戶知道的和/或對於向多通道認證系統註冊為屬於用戶並被授權執行交易的通信裝置特定的資訊。因此，即使用戶標識和密碼被竊取，欺詐者仍然不能完成認證，因為與認證伺服器的附加認證需要對於用戶和/或被授權的用戶裝置特定的附加資訊。

圖2示出了中間人裝置110的存在，所述中間人裝置110已經由欺詐者為了對用戶實施欺詐的目的而實現。通常，欺詐者試圖誘使用戶基於某個藉口來進行到中間人裝置110的連接。一旦基於某個似乎真實的藉口進行了連接，欺詐者的中間人裝置110接著就代表用戶的瀏覽器102提供到應用伺服器104的連接，欺詐者的中間人裝置110位於在用戶端瀏覽器裝置102和應用伺服器104之間的通信中間。因此，在用戶端瀏覽器連接中間人裝置之後，所述中間人裝置接著連接到應用伺服器，就像兩個連接一樣。每個連接都具有來自于請求方的源IP位址。

因為中間人裝置中繼在用戶端瀏覽器和認證伺服器之間的消息，所以瀏覽器102的第一因素認證(利用用戶的用戶標識和密碼)將會成功。此外，在獨立安全通道上的瀏覽器102和認證伺服器106之間的第二因素認證也將會成功。那麼，洩露了在用戶端瀏覽器102和應用伺服器104之間的任意後續通信，並且因為中間人裝置110幾乎可以代表用戶端瀏覽器102執行任意動作，例如包括SSL協定資訊修改，所以欺詐的風險仍然存在。

圖3示出了根據本發明一個實施例的IP位址安全多通道認證(IPAS-MCA)的示意圖。在圖3的實例中，描述了IPAS-MCA技術的步驟，儘管在圖3的實例中不存在欺詐的中間人裝置。這裏，存在中間人裝置的情況將聯繫的圖4進行討論。

回來參照圖3，首先用戶端瀏覽器302聯繫(330)應用伺服器304以請求認證。在這一階段，認證一般又使用常規的用戶標識和密碼組合。此外，應用伺服器304也注意接收的分組(package)的源IP位址。記錄所述源IP位址。在圖3的實例中，因為沒有中間人裝置，所以源IP位址將是用戶端瀏覽器302的IP地址。

如果根據第一因素認證用戶被認為是有效用戶，則確定用戶端瀏覽器302的用戶是否是多通道認證系統的訂戶。可以由認證伺服器306通過例如針對它的訂戶資料庫核對用戶的身份(其被應用伺服器304轉發(332)到認證伺服器306)來做出決定。此外，由應用伺服器304記錄的源IP位址資訊被傳遞(332)到認證伺服器306。

如果確定用戶是多通道認證系統的訂戶，那麼為了執行進一步的認證的目的，認證伺服器306經由應用伺服器304來向用戶端瀏覽器302發送(334)指令(例如以HTML代碼的形式)，以指示用戶端瀏覽器302建立與認證伺服器306的安全通信通道。

利用由認證伺服器306提供的指令(其被經由應用伺服器304來發送給用戶端瀏覽器302)，用戶端瀏覽器302接著(使用例如AJAX技術或相似的技術)建立(336A/336B)到認證伺服器306的通信通道。經由該附加通信通道，用戶端瀏覽器302和認證伺服器306可以執行進一步的認證。

一般說來，附加認證可能需要只有用戶知道的和/或對於向多通道認證系統註冊為屬於用戶並被授權執行交易的通信裝置特定的資訊。如所提到的那樣，即使洩露了用戶標識和密碼，欺詐者仍然不能完成認證，因為與認證伺服器的附加認證需要對於用戶和/或被授權的用戶裝置特定的附加資訊。

此外，認證伺服器306檢查來自從用戶端瀏覽器302接收到的資料分組的源IP位址，以確定在用戶端瀏覽器302和認證伺服器306之間的安全通信會話中，在從用戶端瀏覽器302接收到的資料分組中的IP位址是否與由應用伺服器304轉發的IP地址(其反映在用戶端瀏覽器302和應用伺服器304之間的第一因素認證期間由應用伺服器304所接收的資料分組中的源IP位址)相匹配。如果這兩個IP地址匹配，則將像圖3的實例中的情況那樣，因為沒有中間人裝置，所以認證被認為是成功的。

圖4示出了根據本發明一個實施例的IP位址安全多通道認證 (IPAS-MCA)的示意圖。在圖4的實例中，中間人裝置420欺騙性地***在用戶端瀏覽器402和應用伺服器404之間的通信流中。一般說來，中間人裝置420可以首先使用例如像網路仿冒這樣的技術來建立與用戶端瀏覽器402的通信，以哄騙用戶端瀏覽器402的用戶相信用戶端瀏覽器402的用戶正在與應用伺服器404進行通信。一旦建立了用戶端瀏覽器402和中間人裝置420之間的通信，則中間人裝置420聯繫應用伺服器404並打開一個通信通道。

在用戶端瀏覽器402和應用伺服器404之間的後續通信由中間人裝置420中繼。

應用伺服器404請求用戶端瀏覽器402的認證，而所述請求被中間人裝置420中繼到用戶端瀏覽器402。如所提到的那樣，在這一階段，像傳統上那樣，認證一般再次使用用戶標識和密碼組合。在中間人裝置420中繼所述請求之後，用戶端瀏覽器402以用戶標識/密碼組合來回應所述請求。中間人裝置420將用戶標識/密碼中繼到應用伺服器404。

應用伺服器404還注意接收到的分組的源IP位址。因為資料分組從中間人裝置420到達，所以記錄了與中間人裝置420相關聯的源IP位址。

如果根據用戶標識/密碼組合用戶被認為是有效用戶，則確定用戶端瀏覽器402的用戶是否是多通道認證系統的訂戶。可以由認證伺服器406通過例如針對它的訂戶資料庫核對用戶的身份(其被應用伺服器404轉發(432)到認證伺服器406)來做出決定。此外，將由應用伺服器404記錄的源IP位址資訊(在該實例中其反映來自於通信 430B的中間人裝置420的IP位址)傳遞(參見引用箭頭432)到認證伺服器406。

如果確定用戶是多通道認證系統的訂戶，那麼為了執行進一步的認證的目的，認證伺服器406經由應用伺服器404來向用戶端瀏覽器402發送(434A)指令(例如以HTML代碼的形式)以指示用戶端瀏覽器402建立與認證伺服器406的安全通信通道。這些指令由中間人裝置420中繼(434B)到用戶端瀏覽器402。

利用由認證伺服器406提供的指令(其被經由應用伺服器404發送給用戶端瀏覽器402)，用戶端瀏覽器402接著建立到認證伺服器406的通信通道(436A/436B)。經由該通信通道，用戶端瀏覽器402和認證伺服器406可以執行進一步的認證。注意，來自於認證伺服器406的指令可以包括中間人裝置420不能回應的問詢(challenge)/回應，因為中間人裝置420不具有共用秘密。在這種情況下，中間人裝置420將來自於認證伺服器406的指令傳遞到用戶端瀏覽器402，以允許用戶端瀏覽器402回答所述問詢/回應。用戶端瀏覽器402接著按照指示來建立與認證伺服器406的通信通道。

此外，認證伺服器406檢查來自從用戶端瀏覽器402(來自於由附圖標記436A所指定的通信)接收到的資料分組的源IP位址，以確定在用戶端瀏覽器402和認證伺服器406之間的安全通信會話中，在從用戶端瀏覽器402接收到的資料分組中的IP位址是否與由應用伺服器404轉發的IP地址(其反映在用戶端瀏覽器402和應用伺服器404之間的第一因素認證期間由應用伺服器404所接收(430B)的資料分組中的源IP位址)相匹配。

因為由應用伺服器404記錄並傳遞到認證伺服器406的IP位址反映中間人裝置420的IP位址，所以該IP位址與用戶端瀏覽器的IP位址不匹配，所述用戶端瀏覽器的IP地址由認證伺服器406從用戶端瀏覽器402和認證伺服器406之間的通信中獲得。在這種情況下，認證將失敗。

如從上述內容中所能理解的那樣，本發明的實施例通過進一步實現針對中間人攻擊的防護，擴展了多通道認證技術所提供的安全性。如果用戶標識/密碼組合被竊取，那麼多通道認證方案可以阻止欺詐者的後續認證，因為欺詐者不可能擁有在獨立安全通道上的第二認證所需的資訊(無論是由用戶明確地提供還是由用戶通過其執行線上交易認證的授權的通信裝置自動地提供)。更重要地，如果中間人裝置被欺騙性地***在用戶端瀏覽器和應用服務器之間的通信路徑中，則IPAS-MCA技術可以通過比較IP位址來檢測這種欺詐的中間人裝置的存在並阻止認證和後續的欺詐交易。

這裏通過引用合併的進一步資訊由這裏的權利要求來提供。

雖然已經根據幾個優選實施例來描述了本發明，但仍存在落入本發明範圍內的修改、置換和等效物。也應該注意到，存在許多可供選擇的實施本發明的方法和裝置的替代方法。雖然這裏提供了多個實例，但是其意圖是：這些實例關於本發明是說明性的而非限制性的。

102‧‧‧用戶端瀏覽器

104‧‧‧應用伺服器

106‧‧‧認證伺服器

302‧‧‧用戶端瀏覽器

304‧‧‧應用伺服器

306‧‧‧認證伺服器

332‧‧‧來自於330通信的IP地址

402‧‧‧用戶端瀏覽器

404‧‧‧應用伺服器

406‧‧‧認證伺服器

432‧‧‧來自於430B通信的IP地址

圖1示出了典型的多通道認證方案，其中用戶端瀏覽器利用應用伺服器和認證伺服器兩者來進行認證。

圖2示出了中間人(man-in-the-middle)裝置的存在，所述中間人裝置已經由欺詐者為了對用戶實施欺詐的目的而實現。

圖3示出了根據本發明一個實施例的IP位址安全多通道認證(IPAS-MCA)情景的示意圖。

圖4示出了根據本發明一個實施例的藉以挫敗中間人攻擊的IP位址安全多通道認證(IPAS-MCA)情景的示意圖。

102‧‧‧用戶端瀏覽器

104‧‧‧應用伺服器

106‧‧‧認證伺服器

Claims

一種用於使用應用伺服器和認證伺服器的用戶的多因素認證的電腦實現方法，所述用戶與所述應用伺服器和所述認證伺服器相互作用，所述用戶利用用戶瀏覽器程式與所述應用伺服器和所述認證伺服器中的至少一個進行通信，所述方法包括：利用所述應用伺服器使用第一因素認證證書認證所述用戶；從所述應用伺服器向所述認證伺服器提供與對使用所述第一因素認證證書的所述認證的請求相關聯的第一源IP位址；指示所述用戶在所述用戶瀏覽器程式和所述認證伺服器之間建立獨立通信通道以執行附加認證；比較所述第一源IP位址和與利用所述獨立通信通道的、從所述用戶到所述認證伺服器的通信相關聯的第二源IP位址；以及如果所述第一源IP地址與所述第二源IP位址不匹配，則所述用戶的認證失敗。
如權利要求1所述的方法，其中所述第一因素認證證書至少包括用戶標識和密碼。
如權利要求1所述的方法，進一步包括在指示所述用戶在所述用戶瀏覽器程式和所述認證伺服器之間建立所述獨立通信通道以執行附加認證之前，確定所述用戶是否是多因素認證服務的訂戶。
如權利要求1所述的方法，其中所述附加認證包括在所述認證伺服器和所述用戶瀏覽器程式之間利用共用秘密來進行認證。
如權利要求4所述的方法，其中所述共用秘密包括已知事實。
如權利要求5所述的方法，其中所述已知事實由所述用戶在註冊期間利用帶外通信通道來提供。
如權利要求6所述的方法，其中所述帶外通信通道包括話音呼叫。
如權利要求1所述的方法，其中所述附加認證被加密執行。
如權利要求1所述的方法，其中所述附加認證是在所述認證伺服器和所述用戶瀏覽器程式之間的雙向認證。
如權利要求1所述的方法，其中所述指示所述用戶在所述用戶瀏覽器程式和所述認證伺服器之間建立所述獨立通信通道以執行附加認證涉及AJAX技術。
如權利要求1所述的方法，其中所述指示所述用戶在所述用戶瀏覽器程式和所述認證伺服器之間建立所述獨立通信通道使用HTML。
一種用於使用應用伺服器和認證伺服器的用戶的多因素認證的電腦實現方法，所述用戶利用用戶瀏覽器程式與所述應用伺服器和所述認證伺服器中的至少一個相互作用，所述方法包括：從所述應用伺服器接收與從所述用戶瀏覽器程式到所述應用伺服器的認證請求相關聯的第一源IP位址；從所述用戶瀏覽器程式接收請求以利用獨立通信通道來在所述用戶瀏覽器程式和所述認證伺服器之間執行附加認證，所述獨立通信通道與被用於在所述應用伺服器和所述認證伺服器之間進行通信的通信通道獨立；比較所述第一源IP位址和與在所述認證伺服器和所述用戶瀏覽器程式之間執行所述附加認證的所述請求相關的第二源IP位址；以及如果所述第一源IP地址與所述第二源IP地址不匹配，則所述用戶的認證失敗。
如權利要求12所述的方法，其中在所述用戶瀏覽器程式到所述應用伺服器之間的所述認證包括利用第一因素證書的認證。
如權利要求12所述的方法，其中所述第一因素認證證書至少包括用戶標識和密碼。
如權利要求12所述的方法，進一步包括在指示所述用戶在所述用戶瀏覽器程式和所述認證伺服器之間建立所述獨立通信通道以執行所述附加認證之前，確定所述用戶是否是多因素認證服務的訂戶。
如權利要求12所述的方法，其中所述附加認證包括在所述認證伺服器和所述用戶瀏覽器程式之間利用共用秘密來進行認證。
如權利要求16所述的方法，其中所述共用秘密包括已知事實。
如權利要求17所述的方法，其中所述已知事實由所述用戶在註冊期間利用帶外通信通道來提供。
如權利要求12所述的方法，其中所述附加認證是在所述認證伺服器和所述用戶瀏覽器程式之間的雙向認證。
如權利要求12所述的方法，其中所述附加認證被加密執行。