一種驗證方法及裝置制造方法
【專利摘要】本發(fā)明的實施方式提供了一種驗證方法。例如，該方法可以包括：接收支付請求，判斷支付請求涉及的支付金額是否落入第一預設數(shù)額范圍內(nèi)，如果是，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼，否則，展示第二類型密碼的輸入界面供用戶輸入用于支付驗證的第二類型密碼。根據(jù)支付金額所落入的數(shù)額范圍不同，分別展示不同類型密碼的輸入界面，從而對于較大數(shù)額的支付來說，可以展示密碼較為復雜的密碼輸入界面，對于較小數(shù)額的支付來說，可以展示密碼較為簡單的密碼輸入界面，既保證了電子支付的安全性，又提高了支付操作的便捷性，為用戶帶來了更好的體驗。此外，本發(fā)明的實施方式提供了一種驗證裝置。
【專利說明】_種驗證方法及裝置

【技術領域】
[0001]本發(fā)明的實施方式涉及電子支付領域，更具體地，本發(fā)明的實施方式涉及一種驗證方法及裝置。

【背景技術】
[0002]本部分旨在為權利要求書中陳述的本發(fā)明的實施方式提供背景或上下文。此處的描述不因為包括在本部分中就承認是現(xiàn)有技術。
[0003]隨著智能手機、PDA等電子終端的普及，電子支付已成為人們?nèi)粘Ｉ钪袕V泛使用的支付方式。電子支付，是指通過電子終端發(fā)出支付指令，實現(xiàn)貨幣支付與資金轉移的行為。
[0004]通常來說，電子支付的支付平臺會要求用戶設置較為復雜的支付密碼。這樣，在用戶進行電子支付時，支付平臺將用戶輸入的支付密碼與之前設置的復雜支付密碼進行比對，如果一致，則可以繼續(xù)完成支付，從而保證用戶賬戶資金安全。


【發(fā)明內(nèi)容】

[0005]但是，總是要求用戶輸入復雜的支付密碼對用戶操作帶來一定不便，降低了用戶支付的便捷性。
[0006]因此，在現(xiàn)有技術中，如何使用戶可以更加安全、便捷地進行支付是非常令人煩惱的問題。
[0007]為此，非常需要一種改進的驗證方法，以使用戶可以更加安全、便捷地進行支付。
[0008]在本上下文中，本發(fā)明的實施方式期望提供一種驗證方法及裝置。
[0009]在本發(fā)明實施方式的第一方面中，提供了一種驗證方法。例如，該方法可以包括:接收支付請求，判斷所述支付請求涉及的支付金額是否落入第一預設數(shù)額范圍內(nèi)，如果是，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼，否則，展示第二類型密碼的輸入界面供用戶輸入用于支付驗證的第二類型密碼。
[0010]在本發(fā)明實施方式的第二方面中，提供了一種驗證裝置。例如，該裝置可以包括:支付接收單元，可以配置用于接收支付請求。判斷單元，可以配置用于判斷所述支付請求涉及的支付金額是否落入第一預設數(shù)額范圍內(nèi)。第一密碼輸入單元，可以配置用于如果所述判斷單元判定為是，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼。第二密碼輸入單元，可以配置用于如果所述判斷單元判定為否，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼。
[0011]根據(jù)本發(fā)明實施方式的驗證方法及裝置，可以在接收用戶的支付請求后，根據(jù)用戶支付請求所涉及的支付金額所落入的數(shù)額范圍的不同，分別展示不同類型密碼的輸入界面供用戶輸入用于支付驗證的密碼，從而對于較大數(shù)額的支付來說，可以展示密碼較為復雜的密碼輸入界面，對于較小數(shù)額的支付來說，可以展示密碼較為簡單的密碼輸入界面，從而既保證了電子支付的安全性，又提高了支付操作的便捷性，為用戶帶來了更好的體驗。

【專利附圖】

【附圖說明】
[0012]通過參考附圖閱讀下文的詳細描述，本發(fā)明示例性實施方式的上述以及其他目的、特征和優(yōu)點將變得易于理解。在附圖中，以示例性而非限制性的方式示出了本發(fā)明的若干實施方式，其中:
[0013]圖1示意性地示出了根據(jù)本發(fā)明實施方式的客戶端界面示意圖；
[0014]圖2示意性地示出了根據(jù)本發(fā)明實施方式的驗證方法流程示意圖；
[0015]圖3示意性地示出了根據(jù)本發(fā)明實施方式的驗證裝置結構示意圖；
[0016]在附圖中，相同或?qū)臉颂柋聿幌嗤驅(qū)牟糠帧?br>
【具體實施方式】
[0017]下面將參考若干示例性實施方式來描述本發(fā)明的原理和精神。應當理解，給出這些實施方式僅僅是為了使本領域技術人員能夠更好地理解進而實現(xiàn)本發(fā)明，而并非以任何方式限制本發(fā)明的范圍。相反，提供這些實施方式是為了使本公開更加透徹和完整，并且能夠?qū)⒈竟_的范圍完整地傳達給本領域的技術人員。
[0018]本領域技術技術人員知道，本發(fā)明的實施方式可以實現(xiàn)為一種系統(tǒng)、裝置、設備、方法或計算機程序產(chǎn)品。因此，本公開可以具體實現(xiàn)為以下形式，即:完全的硬件、完全的軟件(包括固件、駐留軟件、微代碼等)，或者硬件和軟件結合的形式。
[0019]根據(jù)本發(fā)明的實施方式，提出了一種驗證方法及裝置。
[0020]在本文中，需要理解的是，附圖中的任何元素數(shù)量均用于示例而非限制，以及任何命名都僅用于區(qū)分，而不具有任何限制含義。
[0021]下面參考本發(fā)明的若干代表性實施方式，詳細闡釋本發(fā)明的原理和精神。
[0022]發(fā)曰月概沐
[0023]本發(fā)明人發(fā)現(xiàn)，可以對用戶支付請求所涉及的支付金額所落入的范圍進行判斷，根據(jù)落入范圍的不同，分別展示不同類型密碼的輸入界面，供用戶輸入用于支付驗證的密碼，從而對于較大數(shù)額的支付來說，可以展示密碼較為復雜的輸入界面供用戶輸入較為復雜的密碼，對于較小數(shù)額的支付來說，可以展示密碼較為簡單的輸入界面供用戶輸入較為簡單的密碼，從而既保證了電子支付的安全性，又提高了支付操作的便捷性，為用戶帶來了更好的體驗。
[0024]在介紹了本發(fā)明的基本原理之后，下面具體介紹本發(fā)明的各種非限制性實施方式。
[0025]應用場景總覽
[0026]首先參考圖1，為應用本發(fā)明實施例提供的驗證方法的客戶端界面示意圖。例如，在用戶開啟“小額支付”手勢密碼功能之后，如果用戶發(fā)出的支付請求的支付金額落入小額范圍，則客戶端可以展示九宮格手勢密碼輸入界面101，供用戶輸入用于支付驗證的九宮格手勢密碼，如未落入小額范圍，則客戶端可以展示文本密碼輸入界面102，供用戶輸入用于支付驗證的文本密碼。
[0027]示例性方法
[0028]下面結合圖1的應用場景，參考圖2來描述根據(jù)本發(fā)明示例性實施方式的驗證方法。需要注意的是，上述應用場景僅是為了便于理解本發(fā)明的精神和原理而示出，本發(fā)明的實施方式在此方面不受任何限制。相反，本發(fā)明的實施方式可以應用于適用的任何場景。
[0029]例如，參見圖2，為本發(fā)明實施例提供的一種應用于客戶端的驗證方法流程示意圖。如圖2所示，該方法可以包括:
[0030]S210、接收支付請求。
[0031]需要說明的是，客戶端接收支付請求的方式不限。例如，一些可能的實施方式中，客戶端可以提供有用于發(fā)出支付請求的界面，用戶可以在該界面上輸入支付金額，并相應點擊支付按鈕以發(fā)出支付請求?？蛻舳丝梢皂憫谥Ц栋粹o被按下，接收到用戶發(fā)出的支付請求并從該用于發(fā)出該支付請求的界面獲取用戶輸入的支付金額。
[0032]S220、判斷所述支付請求涉及的支付金額是否落入第一預設數(shù)額范圍內(nèi)。
[0033]例如，所述第一預設數(shù)額范圍可以為小于等于一個小額支付閾值的范圍。當支付請求涉及的支付金額小于等于小額支付閾值時，可以判定支付請求涉及的支付金額落入第一預設數(shù)額范圍內(nèi)。當支付請求涉及的支付金額大于小額支付閾值時，可以判定支付請求涉及的支付金額未落入第一預設數(shù)額范圍內(nèi)。
[0034]再例如，所述第一預設數(shù)額范圍可以為落入兩個指定數(shù)額閾值之間的范圍，如100?200等。當支付請求涉及的支付金額落入兩個指定數(shù)額閾值之間時，可以判定付請求涉及的支付金額落入第一預設數(shù)額范圍內(nèi)。當支付請求涉及的支付金額未落入兩個指定數(shù)額閾值之間時，可以判定支付請求涉及的支付金額未落入第一預設數(shù)額范圍內(nèi)。
[0035]S230、如果是，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼。
[0036]S240、否則，展示第二類型密碼的輸入界面供用戶輸入用于支付驗證的第二類型密碼。
[0037]其中，所述第一類型密碼以及第二類型密碼可以為復雜度不同的密碼。例如，第一類型密碼的復雜度可以小于第二類型密碼的復雜度。具體地，例如，所述第一類型密碼可以是手勢密碼、4位數(shù)的PIN碼，等等。所述第二類型密碼可以是文本密碼，例如，可以為至少由6位母和/或數(shù)字組成的文本密碼。
[0038]一些可能的實施方式中，客戶端所展示的第一類型密碼的輸入界面，可以為輸入操作更加簡單、快捷的觸摸手勢密碼輸入界面。例如，所述第一類型密碼的輸入界面可以為包含如圖1所示的九宮格的九宮格手勢密碼輸入界面。
[0039]一些可能的實施方式中，客戶端所展示的第二類型密碼的輸入界面，可以為輸入操作較為復雜的文本密碼輸入界面。例如，所述第二類型密碼的輸入界面可以為包含如圖1所示的文本密碼輸入框的文本密碼輸入界面。
[0040]可見，在客戶端應用本發(fā)明實施例提供的方法，可以使客戶端在接收用戶的支付請求后，根據(jù)用戶支付請求所涉及的支付金額所落入的數(shù)額范圍的不同，分別展示不同類型密碼的輸入界面供用戶輸入用于支付驗證的密碼，從而對于較大數(shù)額的支付來說，可以展示密碼較為復雜的輸入界面供用戶輸入較為復雜的密碼，對于較小數(shù)額的支付來說，可以展示密碼較為簡單的輸入界面供用戶輸入較為簡單的密碼，從而既保證了電子支付的安全性，又提高了支付操作的便捷性，為用戶帶來了更好的體驗。
[0041]下面，以本發(fā)明實施例所述的手勢密碼為九宮格手勢密碼為例，對本發(fā)明實施例手勢密碼的設置以及驗證進行詳細說明。其中，所述九宮格手勢密碼，是由用戶在按九點宮格方式布置觸摸節(jié)點的界面上，觸摸各個觸摸節(jié)點的觸摸順序所確定的手勢密碼。其中，各個觸摸節(jié)點，例如可以分別由數(shù)字標識，例如，九宮格的第一排觸摸節(jié)點可以是1-3，第二排觸摸節(jié)點可以是4-6，第三排觸摸節(jié)點可以是7-9，等。因此，一個九宮格手勢密碼可以對應一個數(shù)字串。
[0042]大多數(shù)用戶為了便利性，多會設置較為簡單的九宮格手勢密碼。但是，越短的密碼，越容易被破解，因此，為了加強安全性，本發(fā)明實施例對用戶設置的九宮格手勢密碼進行了混淆以及SHA-1加密處理。
[0043]例如，本發(fā)明實施例的客戶端可以提供用于設置九宮格手勢密碼的九宮格手勢密碼設置界面。其中，所述客戶端可以在用戶主動觸發(fā)手勢密碼設置功能時展示九宮格手勢密碼設置界面，也可以在用戶支付請求涉及的支付金額首次落入第一預設數(shù)額范圍內(nèi)時展示九宮格手勢密碼設置界面。當所述客戶端展示所述九宮格手勢密碼設置界面后，可以接收用戶在九宮格手勢密碼設置界面上設置的九宮格手勢密碼。依次對與所述設置的九宮格手勢密碼對應的數(shù)字串進行混淆、SHA-1 (安全散列算法)加密。將所述加密后的九宮格手勢密碼存儲在所述客戶端和/或與所述客戶端無線通信的服務器中。
[0044]其中，對九宮格手勢密碼對應的數(shù)字串進行混淆的【具體實施方式】不限。例如，可以按照預設算法，以一定規(guī)律在九宮格手勢密碼對應的數(shù)字串中加入若干位字符。例如，預設算法可以設置為在第I位，第3位，第4位后面分別加字符串“a”、“*A”、“37”，則九宮格手勢密碼對應的數(shù)字串“ 1236”經(jīng)過混淆處理后，可以變?yōu)椤?la23*A637”。
[0045]其中，所述SHA-1加密，是一種安全哈希算法?？梢詫σ欢蚊魑纳梢粋€不可逆的結果，這個結果相當于一個指紋。每一段不同的明文，生成的SHA-1結果都是不一樣的，從而起到了加密的作用。對于SHA-1結果，是無法反推出明文的，這也是SHA-1加密算法的一個優(yōu)點?？梢詫︻A先設置的密碼加密后的SHA-1結果和當前請求驗證的密碼加密后的SHA-1結果進行比對，以驗證當前請求的密碼是否正確。由于SHA-1不可逆性，提高了密碼的安全性。
[0046]另外，如果所述設置的九宮格手勢密碼對應的數(shù)字串長度未到達安全長度，還可以提示用戶重新設置。
[0047]在客戶端接收到用戶的支付請求后，如果支付請求涉及的支付金額落入第一預設數(shù)額范圍內(nèi)，則可以展示九宮格手勢密碼輸入界面，以供用戶輸入用戶支付驗證的九宮格手勢密碼。在得到用戶輸入的九宮格手勢密碼之后，可以依次對用戶輸入的第一類型密碼，即九宮格手勢密碼對應的數(shù)字串進行混淆、SHA-1加密，得到加密后的第一類型密碼。
[0048]例如，可以將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。
[0049]再例如，可以向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。
[0050]又例如，可以將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。
[0051]上述三種驗證方式中，僅在客戶端或服務器端驗證，驗證環(huán)節(jié)少，支付效率較高，既在客戶端又在服務器端驗證，安全性更好。具體選擇哪一種驗證方式，可以根據(jù)實際需要進行設置，本發(fā)明對此并不進行限制。
[0052]本發(fā)明上述實施方式將對九宮格手勢密碼對應的數(shù)字串混淆以及SHA-1加密進行結合，使得混淆與加密后的密碼數(shù)據(jù)更長，更加復雜，而且不可逆，從而提高了九宮格手勢密碼存儲的安全性。
[0053]示例件設各
[0054]在介紹了本發(fā)明示例性實施方式的方法之后，接下來，參考圖3對本發(fā)明示例性實施方式的驗證裝置進行詳細介紹。
[0055]例如，參見圖3，為本發(fā)明實施例通過的一種驗證裝置的結構示意圖。如圖3所示，該裝置可以包括:
[0056]支付接收單元310，可以配置用于接收支付請求。判斷單元320，可以配置用于判斷所述支付請求涉及的支付金額是否落入第一預設數(shù)額范圍內(nèi)。第一密碼輸入單元330，可以配置用于如果所述判斷單元判定為是，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼。第二密碼輸入單元340，可以配置用于如果所述判斷單元判定為否，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼。
[0057]可見，在客戶端配置本發(fā)明實施例提供的裝置，可以由判斷單元320在支付接收單元310接收用戶的支付請求后，對用戶支付請求所涉及的支付金額所落入的數(shù)額范圍進行判斷，由第一密碼輸入單元330或第二密碼輸入單元340分別展示不同類型密碼的輸入界面供用戶輸入用于支付驗證的密碼，從而對于較大數(shù)額的支付來說，可以展示密碼較為復雜的輸入界面，對于較小數(shù)額的支付來說，可以展示密碼較為簡單的輸入界面，從而既保證了電子支付的安全性，又提高了支付操作的便捷性，為用戶帶來了更好的體驗。
[0058]一些可能的實施方式中，所述第一類型密碼可以是手勢密碼。所述第二類型密碼可以是文本密碼。
[0059]下面，以本發(fā)明實施例所述的手勢密碼為九宮格手勢密碼為例，對本發(fā)明實施例手勢密碼的設置以及驗證進行詳細說明。
[0060]例如，如圖3所示，本發(fā)明實施例提供的裝置還可以包括:設置接收單元350，可以配置用于接收用戶在九宮格手勢密碼設置界面上設置的九宮格手勢密碼。設置加密單元351，可以配置用于依次對與所述設置的九宮格手勢密碼對應的數(shù)字串進行混淆、SHA-1加密。密碼保存單元352，可以配置用于將所述加密后的九宮格手勢密碼存儲在所述客戶端和/或與所述客戶端無線通信的服務器中。
[0061]再例如，如圖3所示，本發(fā)明實施例提供的裝置還可以包括:驗證加密單元360，可以配置用于依次對用戶輸入的第一類型密碼對應的數(shù)字串進行混淆、SHA-1加密，得到加密后的第一類型密碼。另外，該裝置還可以包括:雙重驗證單元361，可以配置用于將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。或者，服務器驗證單元362，可以配置用于向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。或者，客戶端驗證單元363，可以配置用于將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。
[0062]由于小于一定長度的手勢密碼不安全，該裝置還可以包括:提示單元370，可以配置用于如果所述設置的九宮格手勢密碼對應的數(shù)字串長度未到達安全長度，提示用戶重新設置。
[0063]本發(fā)明上述實施方式將混淆以及SHA-1加密進行結合，使得混淆與加密后的九宮格手勢密碼對應的密碼字符串更長，更加復雜，而且不可逆，從而提高了九宮格手勢密碼存儲的安全性。
[0064]需要注意的是，本發(fā)明實施例所述設置接收單元350、設置加密單元351、密碼保存單元352、提示單元370、雙重驗證單元361、服務器驗證單元362、客戶端驗證單元363在圖3中以虛線繪制，以表示這些單元不是本發(fā)明實施例提供的驗證裝置的必要單元。
[0065]應當注意，盡管在上文詳細描述中提及了驗證裝置的若干單元，但是這種劃分僅僅并非強制性的。實際上，根據(jù)本發(fā)明的實施方式，上文描述的兩個或更多單元的特征和功能可以在一個單元中具體化。反之，上文描述的一個單元的特征和功能可以進一步劃分為由多個單元來具體化。
[0066]此外，盡管在附圖中以特定順序描述了本發(fā)明方法的操作，但是，這并非要求或者暗示必須按照該特定順序來執(zhí)行這些操作，或是必須執(zhí)行全部所示的操作才能實現(xiàn)期望的結果。附加地或備選地，可以省略某些步驟，將多個步驟合并為一個步驟執(zhí)行，和/或?qū)⒁粋€步驟分解為多個步驟執(zhí)行。
[0067]雖然已經(jīng)參考若干【具體實施方式】描述了本發(fā)明的精神和原理，但是應該理解，本發(fā)明并不限于所公開的【具體實施方式】，對各方面的劃分也不意味著這些方面中的特征不能組合以進行受益，這種劃分僅是為了表述的方便。本發(fā)明旨在涵蓋所附權利要求的精神和范圍內(nèi)所包括的各種修改和等同布置。
【權利要求】
1.一種驗證方法，應用于客戶端，所述方法包括: 接收支付請求； 判斷所述支付請求涉及的支付金額是否落入第一預設數(shù)額范圍內(nèi)； 如果是，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼； 否則，展示第二類型密碼的輸入界面供用戶輸入用于支付驗證的第二類型密碼。
2.根據(jù)權利要求1所述的方法，其中， 所述第一類型密碼是手勢密碼； 所述第二類型密碼是文本密碼。
3.根據(jù)權利要求2所述的方法，進一步包括: 接收用戶在九宮格手勢密碼設置界面上設置的九宮格手勢密碼； 依次對與所述設置的九宮格手勢密碼對應的數(shù)字串進行混淆、SHA-1加密； 將所述加密后的九宮格手勢密碼存儲在所述客戶端和/或與所述客戶端無線通信的服務器中。
4.根據(jù)權利要求3所述的方法，進一步包括:依次對用戶輸入的第一類型密碼對應的數(shù)字串進行混淆、SHA-1加密，得到加密后的第一類型密碼； 且，還包括: 將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過； 或者， 向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過； 或者， 將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。
5.根據(jù)權利要求3所述的方法，進一步包括: 如果所述設置的九宮格手勢密碼對應的數(shù)字串長度未到達安全長度，提示用戶重新設置。
6.一種驗證裝置，配置于客戶端，所述裝置包括: 支付接收單元，配置用于接收支付請求； 判斷單元，配置用于判斷所述支付請求涉及的支付金額是否落入第一預設數(shù)額范圍內(nèi)； 第一密碼輸入單元，配置用于如果所述判斷單元判定為是，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼； 第二密碼輸入單元，配置用于如果所述判斷單元判定為否，展示第一類型密碼的輸入界面供用戶輸入用于支付驗證的第一類型密碼。
7.根據(jù)權利要求6所述的裝置，其中， 所述第一類型密碼是手勢密碼； 所述第二類型密碼是文本密碼。
8.根據(jù)權利要求7所述的裝置，進一步包括: 設置接收單元，配置用于接收用戶在九宮格手勢密碼設置界面上設置的九宮格手勢密碼； 設置加密單元，配置用于依次對與所述設置的九宮格手勢密碼對應的數(shù)字串進行混淆、SHA-1加密； 密碼保存單元，配置用于將所述加密后的九宮格手勢密碼存儲在所述客戶端和/或與所述客戶端無線通信的服務器中。
9.根據(jù)權利要求8所述的裝置，進一步包括: 驗證加密單元，配置用于依次對用戶輸入的第一類型密碼對應的數(shù)字串進行混淆、SHA-1加密，得到加密后的第一類型密碼； 且，還包括: 雙重驗證單元，配置用于將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過； 或者， 服務器驗證單元，配置用于向服務器發(fā)端送所述加密后的第一類型密碼，以便服務器將所述加密后的第一類型密碼與存儲在服務器端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過； 或者， 客戶端驗證單元，配置用于將所述加密后的第一類型密碼與存儲在客戶端的九宮格手勢密碼進行比對，如果一致，確定支付驗證通過。
10.根據(jù)權利要求8所述的裝置，進一步包括: 提示單元，配置用于如果所述設置的九宮格手勢密碼對應的數(shù)字串長度未到達安全長度，提示用戶重新設置。
【文檔編號】G06Q20/38GK104504569SQ201410821370
【公開日】2015年4月8日 申請日期:2014年12月24日 優(yōu)先權日:2014年12月24日
【發(fā)明者】宋正旺, 王磊 申請人:網(wǎng)易寶有限公司