Úi, thế nhưng mà cái token đâu có link đến server đâu mà vẫn gen đc OTP mà bác COMALE?

Thế này, em ví dụ, KH A sẽ có mã KH là KH123 chẳng hạn.

Thế thì trên server dựa vào mã KH đó theo 1 thuật toán nào đó cứ 1 phút SINH OTP 1 lần.

Tương tự, client ( ctrinh JAVA trên mobile ) cũng sinh 1 phút 1 lần bằng đúng thuật toán của server và cũng dựa vào Mã KH, như vậy là nếu KH cầm ĐT thì sẽ có mật khẩu OTP giống với trên server còn ko cầm ĐT thì không có được.

OTP từ client không cần gửi lên server làm gì cả, KH sẽ nhập cái OTP hiện trong client vào trang web, submit lên, server sẽ kiểm tra OTP do người dùng nhập với OTP sinh ra trên máy chủ ứng với KH đó, nếu giống thì okie, khác thì từ chối giao dịch.

Em nghĩ thế, sai thì các bác góp ý ah! 

Khi bạn cài chương trình java lên ĐT di động, có cần phải nhập thông tin như password hay thông tin đặc biệt nào khác không?
 

Hix, nhưng cái cục TOKEN cũng là "key generation 2 phía client / server như nhau" mà. Nhưng sao cả thế giới họ gọi TOKEN này là 2FA hả bác COMALE? bác giải thích giúp em với! 

nguoisanhdieu wrote:

Hix, nhưng cái cục TOKEN cũng là "key generation 2 phía client / server như nhau" mà. Nhưng sao cả thế giới họ gọi TOKEN này là 2FA hả bác COMALE? bác giải thích giúp em với! 

2FA là:

1) Username + password (cái người dùng biết).
2) Một cái gì khác (cái người dùng có).

Trong trường hợp này, cái người dùng có là cái SIM.

Nếu nhà băng tin tưởng cái SIM đó... bất tử, không mất, không bị giả mạo --> 2FA đã có.

Tuy nhiên, 2FA kiểu này yếu vì nó không cần verification gì cả. TOKEN tạo ra ở phía client (mobile) là xong.

2FA vững hơn là cần xác định một cái gì người dùng có (SIM) và nó phải generate 1 cái gì đó để server xác thực xem đó là đồ xịn hay đồ giả mạo. 

conmale wrote:

nguoisanhdieu wrote:

Hix, nhưng cái cục TOKEN cũng là "key generation 2 phía client / server như nhau" mà. Nhưng sao cả thế giới họ gọi TOKEN này là 2FA hả bác COMALE? bác giải thích giúp em với! 

2FA là:

1) Username + password (cái người dùng biết).
2) Một cái gì khác (cái người dùng có).

Trong trường hợp này, cái người dùng có là cái SIM.

Nếu nhà băng tin tưởng cái SIM đó... bất tử, không mất, không bị giả mạo --> 2FA đã có.

Tuy nhiên, 2FA kiểu này yếu vì nó không cần verification gì cả. TOKEN tạo ra ở phía client (mobile) là xong.

2FA vững hơn là cần xác định một cái gì người dùng có (SIM) và nó phải generate 1 cái gì đó để server xác thực xem đó là đồ xịn hay đồ giả mạo. 

Ơ bác COMALE ơi, theo em không phải MOBILE TOKEN là theo cái SIM vì theo em biết thì Java J2ME không được quyền truy xuất đến cái SIM ấy nên không thể có được thông tin của cái SIM để làm token. Mặt khác, khi kích hoạt MOBILE TOKEN thì kết nối từ client --> server là qua GPRS ( chỉ kết nối 1 lần duy nhất, sau đó thì tháo SIM ra thì cái ĐT đó vẫn dùng để làm TOKEN vô tư). 

Symbol Represents
-------------------------------------------------------------------
C 8-byte counter value, the moving factor. This counter
MUST be synchronized between the HOTP generator (client)
and the HOTP validator (server).

K shared secret between client and server; each HOTP
generator has a different and unique secret K.

T throttling parameter: the server will refuse connections
from a user after T unsuccessful authentication attempts.
 

In this scenario, the composite shared secret K is constructed during
the provisioning process from a random seed value combined with one
or more additional authentication factors. The server could either
build on-demand or store composite secrets -- in any case, depending
on implementation choice, the token only stores the seed value. When
the token performs the HOTP calculation, it computes K from the seed
value and the locally derived or input values of the other
authentication factors.
 

Hiện tại, có nhiều cách để tạo giá trị token bằng application trên điện thoại, có cả open-source làm cái này nữa...

Mình xin đưa ra một trong các thuật toán phổ biến HOTP để giải thích cho cách hoạt động của chương trình.

HOTP = HMAC-Based One-Time Password
Bạn tham khảo trang RFC của HOTP:
http://www.rfc-editor.org/rfc/rfc4226.txt

1/ Bạn kéo xuống [Page 4], sẽ thấy phần HOTP Algorithm.
Kéo xuống xíu nữa sẽ thấy có 3 symbol tham gia vào quá trình tạo giá trị token - C, K và T.
Trong đó K là shared secret giữa server và client. K này có thể xem là password giữa server và client.
Các giá trị khác bạn có thể đọc để tham khảo thêm.

Symbol Represents
-------------------------------------------------------------------
C 8-byte counter value, the moving factor. This counter
MUST be synchronized between the HOTP generator (client)
and the HOTP validator (server).

K shared secret between client and server; each HOTP
generator has a different and unique secret K.

T throttling parameter: the server will refuse connections
from a user after T unsuccessful authentication attempts.
 

2/ Thuật toán tạo giá trị token được tóm tắt trong phần
5.3. Generating an HOTP Value

3/ Bạn kéo tiếp xuống dưới đến [Page 13]
8. Composite Shared Secrets
Tại đây, bạn sẽ biết cái shared secret được tạo ra như thế nào.
Shared secret sẽ được tạo từ nhũng thông tin liên quan đển ĐT của bạn (ví dụ số IMEI, số di động - trong trường hợp theo bạn nói thì SIM không cần, nên có thể OCBC không dùng số ĐT, số PIN ...)

In this scenario, the composite shared secret K is constructed during
the provisioning process from a random seed value combined with one
or more additional authentication factors. The server could either
build on-demand or store composite secrets -- in any case, depending
on implementation choice, the token only stores the seed value. When
the token performs the HOTP calculation, it computes K from the seed
value and the locally derived or input values of the other
authentication factors.
 

Kết luận:
Theo ý mình, khi bạn kích hoạt cái ứng dụng bằng cách nhập username và password, một quá trình trao đổi thông tin để tạo ra shared secret sẽ diễn ra giữa client (ĐT) và server.
Tất nhiên nếu bạn reverse cái application thì có thể biết rõ về thuật toán sinh ra giá trị token.
Nhưng bạn cần clone thông số hardware nữa thì bạn mới hoàn toàn duplicate thành công.

Như vậy, sau khi activate cái application, application của bạn đã có đầy đủ thông tin để tạo ra shared secret, và không cần kết nối đến server nữa.

Thân

 

Trời, cao thủ là đây chứ đâu, bác thật là đại cao thủ, bác ứng ử làm MOD đi bác ah! thế này quá xứng đáng làm MOD, hihi! 

nguoisanhdieu wrote:

Trời, cao thủ là đây chứ đâu, bác thật là đại cao thủ, bác ứng ử làm MOD đi bác ah! thế này quá xứng đáng làm MOD, hihi! 

Tôi thấy bồ quá lạc đề. Bồ đưa ra một tình huống ứng dụng và muốn hỏi nó an toàn hay không. Đó là mục tiêu của vấn đề bồ đặt ra. Thế nhưng có ai đưa ra một giải pháp (không phải là ứng dụng bồ đang dùng) thì bồ lại cho đó là giải pháp giải quyết cho ứng dụng của bồ đang có. Lại còn chít chát, cảm thán trong chủ đề kỹ thuật nữa.

Đề nghị rút kinh nghiệm và tránh tạo những post như thế này.

Cám ơn. 

conmale wrote:

nguoisanhdieu wrote:

Trời, cao thủ là đây chứ đâu, bác thật là đại cao thủ, bác ứng ử làm MOD đi bác ah! thế này quá xứng đáng làm MOD, hihi! 

Tôi thấy bồ quá lạc đề. Bồ đưa ra một tình huống ứng dụng và muốn hỏi nó an toàn hay không. Đó là mục tiêu của vấn đề bồ đặt ra. Thế nhưng có ai đưa ra một giải pháp (không phải là ứng dụng bồ đang dùng) thì bồ lại cho đó là giải pháp giải quyết cho ứng dụng của bồ đang có. Lại còn chít chát, cảm thán trong chủ đề kỹ thuật nữa.

Đề nghị rút kinh nghiệm và tránh tạo những post như thế này.

Cám ơn. 

Okie, em sẽ rút kinh nghiệm vấn đề này.

Tuy nhiên em thấy có một số vấn đề sau:

1. Em chat chit, cảm thán --> em xin lỗi và hứa sẽ không tái phạm.

2. Cái câu này "Thế nhưng có ai đưa ra một giải pháp (không phải là ứng dụng bồ đang dùng) thì bồ lại cho đó là giải pháp giải quyết cho ứng dụng của bồ đang có" <--em nói là em có cái ứng dụng nào đâu nhỉ, em đang hỏi về ứng dụng của OCBC cơ mà.

3. Mục tiêu chính của em là tại sao OCBC lại tự tin khi đưa ra ứng dụng như thế, vì em nghĩ nó không an toàn, em mới hỏi các cao thủ trên này, và bác 4hfoo đã trả lời em , và em biết tại sao OCBC tự tin rồi.


Có thế thôi, em chẳng thấy lạc đề gì cả? Bác CONMALE nếu có lock hay ban nick em thì giải thích cho em ý 2 và 3, còn nếu lock vì ý 1 thì em xin chịu ah!

Cảm ơn! 

Theo ý mình, khi bạn kích hoạt cái ứng dụng bằng cách nhập username và password, một quá trình trao đổi thông tin để tạo ra shared secret sẽ diễn ra giữa client (ĐT) và server.
Tất nhiên nếu bạn reverse cái application thì có thể biết rõ về thuật toán sinh ra giá trị token.
Nhưng bạn cần clone thông số hardware nữa thì bạn mới hoàn toàn duplicate thành công.

Như vậy, sau khi activate cái application, application của bạn đã có đầy đủ thông tin để tạo ra shared secret, và không cần kết nối đến server nữa.

Thân

 

@tuandinh: xưa như trái đất. đâu cần phải kết nối được với nhau thì mới sync được dữ liệu với nhau đâu.

tui kô làm cái hardware token, hao tiền quá mà cũng chẳng an toàn hơn bao nhiêu. tui làm một cái khác đơn giản hơn, và rẻ hơn rất nhiều. sắp có rồi, đợi vài tuần nữa đi :-p.

--m 

Vấn đề là why Verisign ?