1、網銀動態口令卡 工作原理
動態口令也稱一copy次性口令，動態口令是變動的口令，其變動來源於產生口令的運算因子是變化的。
動態口令的產生因子一般都採用雙運算因子：
其一，為用戶的私有密鑰。
它是代表用戶身份的識別碼，是固定不變的。
其二，
為變動因子。
正是變動因子的不斷變化，才產生了不斷變動的動態口令。採用不同的變動因子，
形成了不同的動態口令認證技術：基於時間同步認證技術、基於事件同步認證技術和挑戰
應答方式的非同認證技術。
①客戶請求接入應用伺服器；
②應用伺服器請求認證伺服器對客戶的身份的合法性和真實性進行認證；
③客戶終端彈出身份認證對話框；
④客戶激活動態口令令牌，生產動態口令；
⑤客戶將帳號和口令鍵入終端的身份認證對話框；
⑥客戶終端將帳號和口令通過網路傳輸給認證伺服器；
⑦認證伺服器調用客戶信息，產生與客戶信息和時間相關的隨機序列，並與客戶輸入的口令進行比對，判別客戶身份的合法性和真實性；
⑧認證伺服器將認證結果報告給應用伺服器；
⑨應用伺服器根據客戶身份的合法性和真實性反饋給客戶終端，並決定可以提供服務或拒絕服務。
2、網上銀行動態口令生成器原理是什麼？怎麼和伺服器通信的？需要電池嗎？
我想應該是和伺服器採用一種相同的運算方法
例如 生成器的運算方內法：用戶名+密碼+時間
伺服器的容運算方法：用戶名+密碼+時間
兩者運算方法都是隨時間變化的相同運算，所以最後得出的密碼也相同，也就是不用通過和伺服器通信都知道兩者生成的密碼是一致的
手動打的 ，望採納
3、動態口令牌 如何保證與伺服器的時間同步?3年時間中如何保持分秒不差?
解決IIS5 HTTP500內部錯誤
作者：佚名 來源：InterNet 加入時間：2004-12-19
一.錯誤表現
IIS5的HTTP 500內部伺服器錯誤是我們經常碰到的錯誤之一，它的主要錯誤表現就是ASP程序不能瀏覽但HTM靜態網頁不受影響。另外當錯誤發生時，系統事件日誌和安全事件日誌都會有相應的記錄。
具體如下：
(一)IE中的表現
當瀏覽以前能夠正常運行的asp頁面時會出現如下的錯誤:
網頁無法顯示
您要訪問的網頁存在問題，因此無法顯示。
請嘗試下列操作：
打開 ;;主頁，尋找指向所需信息的鏈接。
單擊刷新按鈕，或者以後重試。
HTTP 500 - 內部伺服器錯誤
Internet 信息服務
技術信息（支持個人）
詳細信息：
Microsoft 支持
或者是:
Server Application Error
The server has encountered an error while loading an application ring the processing of your request. Please refer to the event log for more detail information. Please contact the server administrator for assistance.
(二)安全日誌記錄(2條)
事件類型: 失敗審核
事件來源: Security
事件種類: 登錄/注銷
事件 ID: 529
日期: 2001-9-9
事件: 11:17:07
用戶: NT AUTHORITY\SYSTEM
計算機: MYSERVER
描述:
登錄失敗:
原因: 用戶名未知或密碼錯誤
用戶名: IWAM_MYSERVER
域: MYDOM
登錄類型: 4
登錄過程: Advapi
身份驗證程序包: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
工作站名: MYSERVER
事件類型: 失敗審核
事件來源: Security
事件種類: 帳戶登錄
事件 ID: 681
日期: 2001-9-9
事件: 11:17:07
用戶: NT AUTHORITY\SYSTEM
計算機: MYSERVER
描述:
登錄到帳戶: IWAM_MYSERVER
登錄的用戶: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
從工作站: MYSERVER
未成功。錯誤代碼是: 3221225578
(三)系統日誌中的記錄(2條)
事件類型: 錯誤
事件來源: DCOM
事件種類: 無
事件 ID: 10004
日期: 2001-9-9
事件: 11:20:26
用戶: N/A
計算機: MYSERVER
描述:
DCOM 遇到錯誤「無法更新密碼。提供給新密碼的值包含密碼中不允許的值。 」並且無法登錄到 .\IWAM_MYSERVER 上以運行伺服器:
事件類型: 警告
事件來源: W3SVC
事件種類: 無
事件 ID: 36
日期: 2001-9-9
事件: 11:20:26
用戶: N/A
計算機: MYSERVER
描述:
伺服器未能轉入應用程序 ''/LM/W3SVC/4/Root''。錯誤是 ''RunAs 的格式必須是<域名>\<用戶名>或只是<用戶名>''。
若要獲取關於此消息的更多的信息，請訪問 Microsoft 聯機支持站點: ;;。
二.原因分析
綜合分析上面的錯誤表現我們可以看出，主要是由於IWAM賬號（在我的計算機即是IWAM_MYSERVER賬號）的密碼錯誤造成了HTTP 500內部錯誤。
在詳細分析HTTP500內部錯誤產生的原因之前，先對IWAM賬號進行一下簡要的介紹：IWAM賬號是安裝IIS5時系統自動建立的一個內置賬號，主要用於啟動進程之外的應用程序的Internet信息服務。IWAM賬號的名字會根據每台計算機NETBIOS名字的不同而有所不同，通用的格式是IWAM_MACHINE，即由「IWAM」前綴、連接線「_」加上計算機的NETBIOS名字組成。我的計算機的NETBIOS名字是MYSERVER，因此我的計算機上IWAM賬號的名字就是IWAM_MYSERVER，這一點與IIS匿名賬號ISUR_MACHINE的命名方式非常相似。
IWAM賬號建立後被Active Directory、IIS metabase資料庫和COM+應用程序三方共同使用，賬號密碼被三方分別保存，並由操作系統負責這三方保存的IWAM密碼的同步工作。按常理說，由操作系統負責的工作我們大可放心，不必擔心出錯，但不知是BUG還是其它什麼原因，系統的對IWAM賬號的密碼同步工作有時會失敗，使三方IWAM賬號所用密碼不統一。當IIS或COM+應用程序使用錯誤IWAM的密碼登錄系統，啟動IIS Out-Of-Process Pooled Applications時，系統會因密碼錯誤而拒絕這一請求，導致IIS Out-Of-Process Pooled Applications啟動失敗，也就是我們在ID10004錯誤事件中看到的「不能運行伺服器 」（這里 是IIS Out-Of-Process Pooled Applications的KEY），不能轉入IIS5應用程序，HTTP 500內部錯誤就這樣產生了。
三.解決辦法
知道了導致HTTP 500內部錯誤的原因，解決起來就比較簡單了，那就是人工同步IWAM賬號在Active Directory、IIS metabase資料庫和COM+應用程序中的密碼。
具體操作分三步,均需要以管理員身份登錄計算機以提供足夠的操作許可權（IWAM賬號以IWAM_MYSERVER為例）。
（一）更改Active Directory中IWAM_MYSERVER賬號的密碼
因IWAM賬號的密碼由系統控制，隨機產生，我們並不知道是什麼，為完成下面兩步的密碼同步工作，我們必須將IWAM賬號的密碼設置為一個我們知道的值。
1、選擇「開始」->「程序」->「管理工具」->"Active Directory用戶和計算機"，啟動「Active Directory用戶和計算機」管理單元。
2、單擊「user」，選中右面的「IWAM_MYSERVER」，右擊選擇「重設密碼(T)...」，在跳出的重設密碼對方框中給IWAM_MYSERVER設置新的密碼，這兒我們設置成「Aboutnt2001」（沒有引號的），確定，等待密碼修改成功。
（二）同步IIS metabase中IWAM_MYSERVER賬號的密碼
可能因為這項改動太敏感和重要，微軟並沒有為我們修改IIS metabase中IWAM_MYSERVER賬號密碼提供一個顯式的用戶介面，只隨IIS5提供了一個管理腳本adsutil.vbs，這個腳本位於C:\inetpub\adminscripts子目錄下（位置可能會因你安裝IIS5時設置的不同而有所變動）。
adsutil.vbs腳本功能強大，參數非常多且用法復雜，這里只提供使用這個腳本修改IWAM_MYSERVER賬號密碼的方法:
adsutil SET w3svc/WAMUserPass Password
"Password"參數就是要設置的IWAM賬號的新的密碼。因此我們將IIS metabase中IWAM_MYSERVER賬號的密碼修改為「Aboutnt2001」的命令就是：
c:\Inetpub\AdminScripts>adsutil SET w3svc/WAMUserPass "Aboutnt2001"
修改成功後，系統會有如下提示：
WAMUserPass: (String) "Aboutnt2001"
（三）同步COM+應用程序所用的IWAM_MYSERVER的密碼
同步COM+應用程序所用的IWAM_MYSERVER的密碼，我們有兩種方式可以選擇:一種是使用組件服務MMC管理單元，另一種是使用IWAM賬號同步腳本synciwam.vbs。
1、使用組件服務MMC管理單元
（1）啟動組件服務管理單元：選擇「開始」->「運行」->「MMC」，啟動管理控制台,打開「添加/刪除管理單元」對話框,將「組件服務」管理單元添加上。
（2）找到「組件服務」->「計算機」->「我的電腦」->「COM+應用程序」->「Out-Of-Process Pooled Applications」，右擊「Out-Of-Process Pooled Applications」->「屬性」。
（3）切換到「Out-Of-Process Pooled Applications」屬性對話框的「標志」選項卡。「此應用程序在下列賬戶下運行」選擇中「此用戶」會被選中，用戶名是「IWAM_MYSERVER」。這些都是預設的，不必改動。在下面的「密碼」和「確認密碼」文本框內輸入正確的密碼「Aboutnt2001」，確定退出。
（4）系統如果提示「應用程序被一個以上的外部產品創建。你確定要被這些產品支持嗎？」時確定即可。
（5）如果我們在IIS中將其它一些Web的「應用程序保護」設置為「高（獨立的）」,那麼這個WEB所使用的COM+應用程序的IWAM賬號密碼也需要同步。重復（1）-（4）步，同步其它相應Out of process application的IWAM賬號密碼。
2、使用IWAM賬號同步腳本synciwam.vbs
實際上微軟已經發現IWAM賬號在密碼同步方面存在問題，因此在IIS5的管理腳本中單獨為IWAM賬號密碼同步編寫了一個腳本synciwam.vbs，這個腳本位於C:\inetpub\adminscripts子目錄下（位置可能會因你安裝IIS5時設置的不同而有所變動）。
synciwam.vbs腳本用法比較簡單：
cscript synciwam.vbs [-v|-h]
「-v」參數表示詳細顯示腳本執行的整個過程(建議使用)，「-h」參數用於顯示簡單的幫助信息。
我們要同步IWAM_MYSERVER賬號在COM+應用程序中的密碼，只需要執行「cscript synciwam.vbs -v」即可，如下：
cscript c:\inetpub\adminscripts\synciwam.vbs -v
Microsoft (R) Windows Script Host Version 5.6
版權所有(C) Microsoft Corporation 1996-2000。保留所有權利。
WamUserName:IWAM_MYSERVER
WamUserPass:Aboutnt2001
IIS Applications Defined:
Name, AppIsolated, Package ID
w3svc, 0,
Root, 2,
IISHelp, 2,
IISAdmin, 2,
IISSamples, 2,
MSADC, 2,
ROOT, 2,
IISAdmin, 2,
IISHelp, 2,
Root, 2,
Root, 2,
Out of process applications defined:
Count: 1
Updating Applications:
Name: IIS Out-Of-Process Pooled Applications Key:
從上面腳本的執行情況可以看出，使用synciwam.vbs腳本要比使用組件服務的方法更全面和快捷。它首先從IIS的metabase資料庫找到IWAM賬號"IWAM_MYSERVER"並取出對應的密碼「Aboutnt2001」，然後查找所有已定義的IIS Applications和Out of process applications，並逐一同步每一個Out of process applications應用程序的IWAM賬號密碼。
使用synciwam.vbs腳本時，要注意一個問題，那就是在你運行synciwam.vbs之前，必須保證IIS metabase資料庫與Active Directory中的IWAM密碼已經一致。因為synciwam.vbs腳本是從IIS metabase資料庫而不是從Active Directory取得IWAM賬號的密碼，如果IIS metabase中的密碼不正確，那synciwam.vbs取得的密碼也會不正確，同步操作執行到「Updating Applications」系統就會報80110414錯誤，即「找不到應用程序」。
好了，到現在為止，IWAM賬號在Active Directory、IIS metabase資料庫和COM+應用程序三處的密碼已經同步成功，你的ASP程序又可以運行了！
4、動態口令如何實現同步？
根據時間或者其他唯一性因素，裡面有個演算法。
--------------------
第一個疑問是客戶端與服務版器端難道有通信聯系？還權是事前就編好了演算法。
第二個疑問，如果事前就編好了演算法，那怎樣保證在很長的時期內時間都能同步。
第三個疑問，銀行有這么多客戶端，難道銀行的伺服器每分鍾都會把所有的客戶埠令算一遍嗎？
---------------------
第一個問題：肯定是事先已經設計好了演算法
第二個：客戶端比如你的U盾 的晶元裡面簽入了和銀行伺服器相對應的演算法 你這邊輸入動態口令的提交到伺服器驗證的時候那邊只計算你的 因為他知道是你在請求賬戶登錄因為你有卡號啊 跟那邊能吻合上，客戶端和伺服器端演算法是否一致沒研究過
第三個：肯定會找到一個唯一的因素或者幾個因素組合在一起 最終肯定是一個唯一的因素 或者說在那個時間段重復的概率是基本不存在的 很小的那種。
你可以研究下軟體的加密解密 能更好的理解甚至破解 哈哈
5、銀行的那種動態口令是通過什麼機制實現付款的?
時間同步基於令牌和伺服器的時間同步，通過運算來生成一致的動態口令，基於時間同步的令牌，一般更新率為60秒，每60秒產生一個新口令，但由於其同步的基礎是國際標准時間，則要求其伺服器能夠十分精確的保持正確的時鍾，同時對其令牌的晶振頻率有嚴格的要求，從而降低系統失去同步的幾率，從另一方面，基於時間同步的令牌在每次進行認證時，伺服器端將會檢測令牌的時鍾偏移量，相應不斷的微調自己的時間記錄，從而保證了令牌和伺服器的同步，確保日常的使用，但由於令牌的工作環境不同，在磁場，高溫，高壓，震盪，浸水等情況下易發生時鍾脈沖的不確定偏移和損壞。故對於時間同步的設備進行較好的保護是十分必要的，對於失去時間同步的令牌，目前可以通過增大偏移量的技術（前後10分鍾）來進行遠程同步，確保其能夠繼續使用，降低對應用的影響，但對於超出默認（共20分鍾）的時間同步令牌，將無法繼續使用或進行遠程同步，必須送回伺服器端另行處理。同樣，對於基於時間同步的伺服器，應較好地保護其系統時鍾，不要隨意更改，以免發生同步問題，從而影響全部基於此伺服器進行認證的令牌。事件同步基於事件同步的令牌，其原理是通過某一特定的事件次序及相同的種子值作為輸入，在演算法中運算出一致的密碼，其運算機理決定了其整個工作流程同時鍾無關，不受時鍾的影響，令牌中不存在時間脈沖晶振，但由於其演算法的一致性，其口令是預先可知的，通過令牌，你可以預先知道今後的多個密碼，故當令牌遺失且沒有使用PIN碼對令牌進行保護時，存在非法登陸的風險，故使用事件同步的令牌，對PIN碼的保護是十分必要的。同樣，基於事件同步的令牌同樣存在失去同步的風險，例如用戶多次無目的的生成口令等，對於令牌的失步，事件同步的伺服器使用增大偏移量的方式進行再同步，其伺服器端會自動向後推算一定次數的密碼，來同步令牌和伺服器，當失步情況經非常嚴重，大范圍超出正常范圍時，通過連續輸入兩次令牌計算出的密碼，伺服器將在較大的范圍內進行令牌同步，一般情況下，令牌同步所需的次數不會超過3次。但在極端情況下，不排出失去同步的可能性，例如電力耗盡，在更換電池時操作失誤等。此時，令牌仍可通過手工輸入由管理員生成的一組序列值來實現遠程同步，而無需返回伺服器端重新同步