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)
 

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).