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 :D. 

Ở 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ể.  

1. Lấy pass qua con đường khác thì thôi khỏi nói smilie, chết chắc rồi 2. Nếu mất pass thì chỉ lộ PU, chứ không lộ PR. 3. Đồng ý. Biết session key sk và nonce thì chỉ việc vét cạn pw tìm xem PU nào tương ứng có E(PU_dự_đoán,sk||nonce)= E(PU_thật,sk||nonce), tuy nhiên kiểu gì chả có cơ chế vượt qua cái này, sửa protocol 5 một tí là xong.  

1. Đâu có bạn, strong password protocol thì phải giải quyết được vấn đề verifier không phải lưu trữ plaintext-equivalent password. Vẫn có protocol làm được đó, bất chấp nhìn vào database của verifier cũng không thể tìm được password. Thậm chí mục tiêu họ đặt ra còn là thứ mà verifier lưu trữ là thông tin public luôn. Mình không nhớ là có protocol nào làm được hay không.  

Vẫn có protocol làm được đó, bất chấp nhìn vào database của verifier cũng không thể tìm được password  

1. Alice tạo (PR_Alice,cPU_Alice), và gửi Bob:M1= Symmetric_encryption(pw,PU_Alice)
2. Bob tạo (PR_Bob, PU_Bob), và gửi Alice: M2= Asymmetric_encryption(PU_Alice, PU_Bob)
3. Alice gửi Bob: M3=Asymmetric_encryption(PU_Bob, sk||nonce)
4. Bob gửi Alice: M4=Symmetric_encryption(sk,nonce)

1. Verifier lưu trữ là thông tin public luôn giả sử nó là U. Giả sử attacker có giải thuật verify+ cái verify lưu trữ. Thế thì vấn đề sẽ là khó có thể tạo ra cái được nào được verify bới verifier và U. Nguyên lý này giống hàm một chiều nhỉ? Lại thành hệ Public Key rồi.  

The server stores user credentials as 5-tuples of the form: {<username>, <password verifier>, <salt>, g, N} <salt> = random() x = SHA(<salt> | SHA( <username> | ":" | <raw password> ) ) <password verifier> = v = g^x % N N = prime modulus; g = generator

 

Tấn công server lấy file chứa bộ {<username>, <password verifier>, <salt>, g, N} rồi giả mạo client thì sao nhỉ? hoặc đổi file này nữa?  

trong đó Bob chứa func(pw, salt), còn Alice chứa pw: 1. Bob ---> Alice: salt Alice tính h=func(pw,salt) 2. Alice ---> Bob: E(h,PU) 3. Bob ---> Alice: E(PU, sk||nonce) 4. Alice ---> Bob: E(sk, nonce || pw)  

Cân bằng giữa giá trị và lợi ích mang lại sẽ là giải pháp được thực tế chấp nhận. Nếu cần bảo mật hơn nữa, đừng tìm kiếm giải pháp xác thực nào khác với password mà cần nâng lên PKI, công nghệ sẵn có, giá thành sẽ rẻ hơn nhiều đưa ra 1 loạt các scheme mới, chưa chắc đã chứng minh được tốt hơn, mà giá thành lại cao. Tất nhiên tranh cãi lý thuyết thì vẽ con voi nó có mấy vòi cũng được, nhưng ... tốn thời gian. 

@myquartz: Hình như bạn còn chưa đọc kĩ và hiểu rõ về mục đích của topic, tức là thảo luận về authentication schemes, chứ không phải là về implementation. RFC 2617 chính là nói về protocol 1 và 2 ngay trong post đầu tiên, cùng với những vấn đề của chúng. Còn nếu nói về implementation, mình thật nghĩ không ra cái javascript của bạn chống được MitM attack kiểu gì.  

Nếu chỉ thảo luận lý thuyết, không dùng (hoặc không thể) triển khai thì bên dưới mình đã nói là nó sẽ phí thời gian. Sẽ giống như phát minh lại cái bánh xe, vì người ta đã có cái scheme đủ tốt để thực hiện rồi, chính nó là PKI.  

Bạn myquartz ơi, ở đây người ta đang nói đến việc làm sao có một cơ chế xác thực tốt mà chỉ dựa vào mật khẩu của người dùng thôi. Đây là một hướng nghiên cứu với nhiều công trình của cryptography, chứ không phải là vấn đề đã được giải quyết rốt ráo rồi đâu bạn ơi. Tự dưng bạn lôi PKI ra, thế bạn thử nói xem một công ty bình thường, muốn xác thực khách hàng qua Internet, thì triển khai PKI thế nào? Mình chẳng biết công ty nào mà lại đi làm cái việc đó cả. Hình như cái này mình đã có nói một lần ở trên đây, bữa nay nói lại, gọi là mrro's law nha: hễ mà nói về bảo mật hay xác thực, thì không sớm thì muộn sẽ có người kêu phải triển khai PKI thôi. 

Theo quan điểm của tớ, giới nghiên cứu không tiếp tục đổ công sức thêm vào authentication scheme vì hiện đã có quá nhiều rồi.  

RFC 2617 không phải là protocol 2, nó mạnh hơn nhiều, vì không phải chỉ là salt, nó còn thêm nonce, nonceCount, clientNonce... Nó có khả năng chống MitM nếu sử dụng full option, nghĩa là HA2 gồm cả digest của method, URI và nội dung cần gửi đi. Kiểu Digest này chỉ yếu khi nó bị trình duyệt/MitM fail-back về RFC2096 (giống protocol 2). Tất nhiên RFC 2617 client không xác thực server, không phải là 2-way (mutual) authentication, đó không phải là mục tiêu của nó. Mình chỉ thấy rằng nó có thể triển khai thực tế để bảo vệ các web site NON-SSL thôi. 

Theo quan điểm của tớ, giới nghiên cứu không tiếp tục đổ công sức thêm vào authentication scheme vì hiện đã có quá nhiều rồi.  

Password Authenticated Key Exchange (PAKE) is one of the central topics in cryptography. It aims to address a practical security problem: how to establish secure communication between two parties solely based on their shared password without requiring a Public Key Infrastructure (PKI). The solution to the above problem is very useful in practice — in fact, so useful that it spawns a lot “fights” over patents. Many techniques were patented, including the well-known Encrypted Key Exchange (EKE) and Simple Password Exponential Key Exchange (SPEKE). A secondary problem is technical; both the EKE and SPEKE protocols have subtle but worrying technical limitations (see the paper for details). At the 16th Workshop on Security Protocols held in April 2008, Cambridge, UK, I presented a new solution (joint work with Peter Ryan) called Password Authenticated Key Exchange by Juggling (or J-PAKE). The essence of the protocol design inherits from the earlier work on solving the Dining Cryptographers problem; we adapted the same juggling technique to the two-party case to solve the PAKE problem. To our best knowledge, this design is significantly different from all past PAKE solutions.  

Giao thức của bạn StarGhost vẫn chưa đủ rồi. Nếu salt chỉ loanh quanh luẩn quẩn ở các hàm cơ bản thì khó. Phải đưa lên dạng hàm một chiều one way function cơ, như x và g^x. Cái 4 còn vi phạm lỗi lớn là gửi đi password. 

@StarGhost: mình nghĩ bước số 4 này lại làm phát sinh một vấn đề

StarGhost wrote:

4. Alice ---> Bob: E(sk, nonce || pw) 

Attacker mà có func(pw, salt), thì hắn chỉ cần lắng nghe một cái session giữa Alice và Bob là hắn tìm được pw, khỏi phải brute-force chi nữa. Ngoài ra thêm cái số 4 này, có thể ngăn attacker giả mạo Alice, nhưng không thể ngăn attacker giả mạo Bob, một khi hắn đã có (salt, func(pw, salt)).  

1. Nếu attacker có func(pw,salt) thì vẫn không thể dò ra được pw bằng việc sniff. 2. Mình không nghĩ rằng tồn tại một protocol nào có thể ngăn chặn attacker giả mạo Bob một khi hắn đã nắm trong tay tất cả các secrets của Bob, trong trường hợp này là func(pw,salt).