1. User gửi (ID, P) cho Host, trong đó P là plaintext password của User

2. Căn cứ vào ID, Host lấy từ database ra A, là một biến thể của password của User và salt, là một chuỗi ngẫu nhiên gắn liền với ID của user. Host thực hiện một phép tính trên P (thông thường là B = H(P, salt), trong đó H là một hàm băm một chiều nào đó) để tính ra B, rồi so sánh A với B, nếu bằng nhau thì tiếp theo bước 3, không thì tiếp theo bước 4.

3. User được Host xác thực và cấp cho một session_id.

4. Host thông báo lỗi cho User, và yêu cầu làm lại từ bước 1.

 

1. User gửi ID cho Host.

2. Host lấy từ database ra salt của ID, và gửi lại cho User.

3. User thực hiện A = H(P, salt), rồi gửi A cho Host.

4. Host lấy từ database ra B (cũng là B được tính như ở protocol 1) so sánh A và B, nếu bằng nhau thì tiếp tục bước 5, không bằng thì tiếp tục bước 6.

5. User được Host xác thực và cấp cho một session_id.

6. Host thông báo lỗi cho User, và yêu cầu làm lại từ bước 1.

 

1. User gửi ID, C1 = E(P, nonce1) cho Host, trong đó P là mật khẩu của User, nonce là unique message number, thường là random, E(K, M) là symmetric cipher nhận key là K và plaintext là M.

2. Host lấy từ database ra P của ID, rồi thực hiện nonce1' = D(P, C1). Host tính C2 = E(P, nonce1'||nonce2||session_key), trong đó || nghĩa là nối vào, nonce2 và session_key được Host tạo ra ngẫu nhiên. Host gửi lại C2 cho User.

3. User thực hiện X = D(P, C2). Căn cứ vào thoả thuận trước về chiều dài của nonce, mà User sẽ cắt ra nonce1' từ X, rồi so sánh nonce1' với nonce1, nếu không bằng nhau, thì nhảy đến bước 6. Nếu bằng nhau, User sẽ cắt nonce2' và session_key' từ X ra, rồi thực hiện C3 = E(session_key', nonce2'). User gửi C3 lại cho Host.

4. Host thực hiện C4 = E(session_key, nonce2), so sánh C4 và C3, nếu không bằng nhau thì nhảy đến bước 6, nếu bằng nhau thì nhảy đến bước 5.

5. User được Host xác thực và cấp cho một session_id.

6. Host thông báo lỗi cho User, và yêu cầu làm lại từ bước 1.

 

Protocol 2 dùng salt như kiểu challenge theo kiểu one time password. 

@starghost: tớ chưa hiểu ở protocol 3 mà không có mutual authentication thì sẽ bị nguy cơ gì? Bên client và server xác lập sự tin cậy dựa trên một share secret (là password). Giả sử rằng password này không để bên thứ ba biết, thì protocol 3 đã đảm bảo an toàn rồi. 

PS: Web cũng dùng được chứ nhỉ? Tớ thấy AJAX có thể hỗ trợ cái này đấy chứ ? 

Xét protocol 4: lưu dãy H_user+ salt thì có đổ vỡ không? Như nhau thôi. ai có P thì cũng sinh ra được dãy H(P||salt). Ai có H(P||salt) thì cũng xác thực được client.
 

Về mặt nguyên tắc, nắm được password của user không có nghĩa là chứng minh được đó là cái honest server, vì password là thứ dễ bị externalized nhất. Nói đến mutual authentication thì cách thức duy nhất được chấp nhận hiện nay là dùng public key cryptosystem.
 

Về mặt nguyên tắc, nắm được password của user không có nghĩa là chứng minh được đó là cái honest server, vì password là thứ dễ bị externalized nhất. Nói đến mutual authentication thì cách thức duy nhất được chấp nhận hiện nay là dùng public key cryptosystem.
 

À cái này thì hiển nhiên, chỉ có điều khó mà standardize được, tức là mỗi website nếu muốn thực hiện thì phải tự implement lấy, chứ không phải như trường hợp của TLS. Còn trong môi trường e-commerce thì hiển nhiên là không chấp nhận được.
 

Theo tớ thấy thì ngay cả cert dùng pub/privkey cũng có thể bị mất, có điều khó mất hơn password thôi: vì attacker sẽ phải nắm được "cái ta có" (là privkey) và "cái ta biết" (là passphrase).

Tóm lại chúng ta đang thảo luận về xác bằng mật khẩu sao cho an toàn, nghĩa là hệ thống hoạt động dựa trên một điểm tin cậy nào đó (ở đây là mật khẩu). Với pubkey cryptosystem, điểm tin cậy là pub/privkey là câu chuyện khác.

 

Với ecommerce thì giờ em thấy họ có ít nhất 3 thứ:
1. Public key (lưu ở usb)
2. Password
3. One Time Password (Một số dùng một miếng giấy in 35 pass rồi mỗi lần giao dịch nó sẽ hỏi, một số dùng Token của RSA, Entrust, Gemato, một số thì chơi kiểu gửi TAN tới máy di động qua SMS. Có vụ đang thu mua Nokia 1100 của Đức cho để ăn cắp TAN thì phải smilie.  

@ mfeng: nếu password của bạn 10 kí tự là bị lộ rồi đấy. Không cần tấn công host chỉ cần vét cạn thôi!  

out of band authentication: khi đó thêm 1 số bí mật nữa được truyền bằng con đường khác, email, sms,...

Khi đó muốn giả mạo thì cần tấn công cả 2 kênh truyền.

Em nghĩ là thêm giả thuyết là database của 2 bên không bị tấn công. Password không bị mất theo kiểu camera theo dõi nhập số, key logger,...


Các giao thức nêu trên vẫn lộ pass, nó cho phép attacker có cơ chế để verify pass đúng hay sai bằng các message nó tóm được mà không cần tấn công để lấy password trên host hoặc client. Trừ khi password đủ dài!

choc_ có link của ssl-mitm ko?
hình như đây có:
http://blog.renchap.com/2009/02/20/blackhat-presentation-about-ssl-mitm 

Topic phát triển nhanh quá! Mới từ xác thực bằng mật khẩu đã chuyển sang public key & out-of-band authentication rồi  

có giải thuật nào nữa không ạ?


Code:

Protocol 5:

1. Alice tạo cặp khóa Public Key  (PR,PU) . Alice gửi M1=E(pw, PU) tới Bob.
2. Bob giải mã M1. Tạo M2= E(PU,sk||nonce) gửi lại Alice
3. Alice gửi E(sk,nonce) cho Bob.

Chi phí tính toán hơi lớn! Đổi lại là an toàn hơn

Thà chia sẻ xừ Public Key từ đầu cho xong . 

Ở Step 1 bạn StarGhost băn khoăn là làm sao Bob hiểu thông tin gì chứa trong PU. Alice và Bob dùng chung một cơ chế giải thuật đã thông báo từ trước chẳng hạn. Nếu thiết kế PU không tốt thì sẽ lộ pass. Ví dụ không nên gửi E(pw, X,PU) với X là một thông tin mà attacker có thể biết như timestamp, ID của Alice hoặc Bob vì khi đó Attacker có thể vét cạn pw để tìm ra pw. 

Protocol 5:
 
 1. Alice tạo cặp khóa Public Key  (PR,PU) . Alice gửi M1=E(pw, PU) tới Bob.
 2. Bob giải mã M1. Tạo M2= E(PU,sk||nonce) gửi lại Alice
 3. Alice gửi E(sk,nonce) cho Bob.

Protocol này hay ở chỗ entropy của các messages không phụ thuộc vào password. Thế nên không quan trọng password dài ngắn ra sao, việc bruteforce password là không thể.