Em cũng chẳng biết gì nhiều về cơ chế này nhưng Google thì thấy Một mã nguồn mở code C cho cơ chế One Time Password . Mang lên cho mọi người cùng tham khảo

http://www.cl.cam.ac.uk/~mgk25/otpw.html 

Cho em hỏi. Thuật toán tạo passcode dùng HOTP = HMAC-SHA1 đồng bộ giữa client và server dựa vào 2 yếu tố chính là shared secret và movingFactor.
MovingFactor là đồng bộ về thời gian, thời gian trên server là giờ hệ thống của server, còn thời gian trên client( mobile) là giờ hệ thống của client. Lỡ thời gian giữa 2 cái ko đồng bộ thì sao? Có cách nào giải quyết tốt vấn đề này? Hay phải tự đồng bộ thời gian giữa client và server?

Em đang làm đề tài về vấn đề này. Mong mấy anh giúp đỡ.
Thân. 

Shared secret là một key bí mật cần trao đổi giữa client và server ( em hiểu nôm na là thế).Vậy cho em hỏi cơ chế tạo ra secret là ntn? 

Với cách thứ 1 thì token sẽ hiển thị chuỗi số radom 1 cách liên tục và thời gian đồng bộ giữa token và authentication manager (AM không vượt quá 1 phút.
Với cách thứ 2 thì trên token có 1 nút bấm để tạo ra 1 số radom. Chuỗi số này đống bộ với thuật toán một chiều trên AM.

Với cả 2 cách đều có những thời điểm giữa token và AM không đồng bộ được với nhau về thời gian hoặc sai giá trị về thuật toán.
Khi gặp những trường hợp này thì chúng ta có thể sync ( đồng bộ ) lại giữa token vào AM bằng cách sau khi gõ passcode lần thứ 1, bạn sẽ được yêu cầu gõ passcode lần thứ 2.

 

Giữa AM và agent sẽ được xác thực và mã hóa thông tin với nhau thông qua node secret.
Lần đầu tiên khi Agent có yêu cầu được chứng thực với AM thì nó sẽ gửi tới AM node secret. AM sẽ respond node secret này hợp lệ hay không trong lần authen đầu tiên để đảm bảo agent đó là đáng tin cậy.
Nó giống kiểu SSH bằng pubkey.
Node Seret được tạo ra trên servers và copy sang cho agents. 

Gõ passcode lần thứ 2 có tác dụng ji? Em ko hiểu? Với 2 cách anh nói thì random đều đựa theo thời gian cả. Chỉ là 1 cái 1 khoảng tg nó random còn 1 cái khi người dùng cần thì nó random thôi.Còn client và AM chỉ xác thực 1 lần duy nhất. Vì vậy mốc tg là bên phía mỗi thiết bị. Vậy giã sử tg bên token chậm hơn bên server thì nhập passcode lần 2 để làm ji? Em ko hiểu.
 

Anh có thể giải thích giùm em chơ chế gửi node secret từ client tới server và cơ chế node secret được tạo ra bên server là ntn để nó phân biệt dc các agent của nó?
Thank anh. 

Lúc này khi login vào Windows đương nhiên phải sử dụng UserID + Pin + Passcode. Đến đây nghĩ thấy...bảo mật quá smilie

Nhưng khi mình thử share 1 folder trên windows và từ client mình access vào thư mục share bằng user ID + password.

Nó vẫn vào được bình thường, như vậy có vẻ không ổn lắm nhỉ? Các bạn khác có ý kiến gì không?
 

Mình nghĩ những giải pháp như RSA SecurID chỉ phù hợp với môi trường xác thực khách hàng bên ngoài sử dụng các dịch vụ công mà doanh nghiệp cung cấp như thương mại điện tử hay ngân hàng điện tử.

Dùng RSA SecurID cho các loại hình dịch vụ này thiệt ra cũng chỉ là tô vẽ thêm cho khách hàng an tâm và hơn hết là làm đúng quy định của nhà chức trách thôi, chứ nếu tính toán về chi phí và hiệu quả thì mình không nghĩ dùng RSA SecurID là giải pháp tối ưu cho bài toán xác thực hai yếu tố.



-m 

Mình cũng cho rằng, đem RSA SecurID vào áp dụng cho môi trường doanh nghiệp để xác thực nhân viên sẽ không phù hợp ở chỗ chi nhiều tiền để giải quyết một rủi ro không quá nghiêm trọng. Thử nghĩ xem RSA SecurID khi dùng kèm với Active Directory để làm Windows logon authentication thì giải quyết được những rủi ro gì? Mình sẽ bàn kỹ về vấn đề này trong một post khác nếu có bạn nào muốn thảo luận.  

Mình nghĩ nếu đã muốn xác thực nhân viên, thì nên hướng đến xác thực việc sử dụng dữ liệu, bởi cuối cùng rồi thì dữ liệu của doanh nghiệp, chứ không phải tài khoản của người sử dụng, mới là thứ quý giá cần phải được bảo vệ. Thử nghĩ đến trường hợp nhân viên cố tình phá hoại, vốn luôn là rủi ro hàng đầu của mọi doanh nghiệp, thì chúng ta sẽ thấy giải pháp xác thực nhân viên lúc họ đăng nhập vào máy tính sẽ trở nên không còn có ý nghĩa.
Tương tự như các dịch vụ công, cái cần phải tập trung bảo vệ là các giao dịch tài chính, chứ không phải tài khoản của khách hàng.
 

Tương tự như các dịch vụ công, cái cần phải tập trung bảo vệ là các giao dịch tài chính, chứ không phải tài khoản của khách hàng.