banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Forum Index Thảo luận bảo mật Cơ chế xác thực mật khẩu an toàn nếu không có SSL  XML
  [Question]   Cơ chế xác thực mật khẩu an toàn nếu không có SSL 11/05/2014 15:59:50 (+0700) | #1 | 280596
[Avatar]
quangteospk
Member

[Minus]    0    [Plus]
Joined: 20/10/2009 04:05:30
Messages: 123
Offline
[Profile] [PM]
Giả sử một website ko có SSL, vậy cơ chế nào để người dùng đảm bảo rằng password của tôi đi trên đường truyền không bị sniff.

Các mã nguồn mở như vBB, Xenforo mình thấy việc băm password đều thực hiện ở phía server, nghĩa là password truyền đi từ Client tới Server là ở dạng plaintext. Vậy với hầu hết các website thì ko phải website nào cũng đủ chi phí để mua SSL -> chấp nhận rủi ro cho người dùng?

Mình có biết SRP protocol, nhưng đọc một số bài thì giao thức này khá cũ, ra đời năm 1997, và cũng chẳng ai dùng cả. Vậy câu hỏi là trước khi SSL ra đời, ngta làm cách nào để bảo vệ password truyền đi, và hiện tại, nếu ko thể mua SSL thì làm sao để bảo vệ password truyền đi.
Jazz
[Up] [Print Copy]
  [Question]   Cơ chế xác thực mật khẩu an toàn nếu không có SSL 11/05/2014 23:41:30 (+0700) | #2 | 280600
StarGhost
Elite Member

[Minus]    0    [Plus]
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
[Profile] [PM]
Ngoài việc gửi password theo dạng plaintext thì client có thể hash password trước rồi mới gửi (xem thêm về challenge-response authentication), hoặc sử dụng PAKE. Tuy nhiên dù là cách nào thì cũng gặp phải 2 vấn đề: 1) entropy của password là rất thấp và 2) nếu giải pháp chỉ bảo vệ password thì hầu như không có ý nghĩa, vì kết nối hoàn toàn có thể bị compromised.

TLS/SSL là giải pháp toàn diện, và hiện tại chi phí mua certificate cũng không quá cao, đặc biệt là với các dịch nhạy cảm như e-commerce. Trước đây khi chưa có TLS/SSL thì căn bản là không có giải pháp an ninh hoàn hảo.
Mind your thought.
[Up] [Print Copy]
  [Question]   Cơ chế xác thực mật khẩu an toàn nếu không có SSL 12/05/2014 08:05:39 (+0700) | #3 | 280601
[Avatar]
quangteospk
Member

[Minus]    0    [Plus]
Joined: 20/10/2009 04:05:30
Messages: 123
Offline
[Profile] [PM]
@StartGhost: Thực ra lúc đầu em nghĩ việc hash ở client mới là chính xác (lúc đầu nghĩ là chỉ cần hash ở client hoặc server thôi). Vì nghĩ nếu chỉ
hash ở server thì password truyền đi trên đường truyền cũng đã là ở dạng plaintext rồi.

Tuy nhiên theo em nghĩ nếu hash ở client sẽ gặp 1 số vấn đề như sau:

- Hash bằng JS thì cũng chỉ làm đc cái việc đó là attracker ko thể thấy password dễ dàng, về bản chất attracker sniff đc password
đã hash thì vẫn có thể edit JS (remove hash func) và submit đi bình thường.
- Không phải trình duyệt nào cũng hỗ trợ JS, chưa kể nhiều người tắt JS đi vì mục đích an toàn.

Còn việc hash ở client, nghĩa là trên server phải lưu một chuỗi là hash(hash(password) đúng ko anh? (tạm bỏ qua salt) cho đơn giản,
em ko nhớ chính xác nhưng hình như việc hash 2 lần một chuỗi không được khuyến khích thì phải.

Hiện nay có SSL thì ko nói, nhưng em vẫn tò mò trước đây ko có thì coi như ngta chấp nhận sự rủi ro? Và theo quan điểm của cá nhân anh, đối
với các website thông thường ko có SSL làm sao để user có thể tự bảo vệ chính mình (nhiều ng có thói quen dùng chung user/pass và truy cập wifi public tự do)
Jazz
[Up] [Print Copy]
  [Question]   Cơ chế xác thực mật khẩu an toàn nếu không có SSL 12/05/2014 17:30:09 (+0700) | #4 | 280611
StarGhost
Elite Member

[Minus]    0    [Plus]
Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline
[Profile] [PM]
Việc hash password thường không phải diễn ra qua JS, mà là qua HTTP authentication. Tuy nhiên vì không có server authentication nên sẽ bị tấn công man-in-the-middle như bạn nói. Nếu chỉ là hash mà không có salt, thì server chỉ cần phải lưu hash(password) và so sánh với hash nhận được. Nếu có salt (challenge-response) thì server phải lưu chính xác password.

Còn về mặt lý thuyết, việc hash n lần theo dạng h^n(m) sẽ làm tăng khả năng tạo ra collisions nếu hash function không phải injective khi ánh xạ image đến image. Trên thực tế chỉ có encryption primitives thoả mãn điều kiện này. Tuy nhiên các hash functions hiện tại, kể cả MD5, đủ tốt để phục vụ cho việc hash nhiều lần.

Về chuyện xảy ra thời tiền SSL, thì mời bạn tham khảo sách giáo khoa lịch sử. Đại khái là SSL được tạo ra không lâu sau HTTP nên giai đoạn ở giữa chỉ là khoảng đệm. Đối với tình hình hiện tại nếu có website đòi hỏi login mà không có SSL thì người dùng khó có cách nào bảo vệ chính mình ngoài việc đơn giản là không login.
Mind your thought.
[Up] [Print Copy]
[digg] [delicious] [google] [yahoo] [technorati] [reddit] [stumbleupon]
Go to: 
 Users currently in here 
1 Anonymous

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|