<![CDATA[Messages posted by "choc_"]]> /hvaonline/posts/listByUser/188897.html JForum - http://www.jforum.net Re: Thuật toán mã hóa Diffie Hellman /hvaonline/posts/preList/29005/178797.html#178797 /hvaonline/posts/preList/29005/178797.html#178797 GMT Re: Thuật toán mã hóa Diffie Hellman /hvaonline/posts/preList/29005/178781.html#178781 /hvaonline/posts/preList/29005/178781.html#178781 GMT Re: Các cách xác thực người dùng bằng mật khẩu /hvaonline/posts/preList/28909/178573.html#178573 /hvaonline/posts/preList/28909/178573.html#178573 GMT Các cách xác thực người dùng bằng mật khẩu

Protocol 1 wrote:
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.  
Protocol này có những vấn đề gì? Mình thử làm xem nha: vấn đề lớn nhất là plaintext password của User bị truyền đi mà không có bất kỳ sự bảo vệ nào. Nhiều bạn sẽ tranh luận là nếu dùng HTTPS thì sẽ không sao, nhưng như mình đã nói ngay từ đầu, giả thuyết đường truyền luôn có người theo dõi là một giả thuyết cần thiết trong môi trường Internet nhiều nguy cơ và phức tạp như bây giờ. Ví dụ như vừa rồi, ở BlackHat có người làm một cái demo ssl-mitm. Câu hỏi là: sửa protocol của HVAOnline lại thế nào để giải quyết được vấn đề plaintext password này? Mình thử revise lại một chút, ra một protocol như sau:

Protocol 2 wrote:
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.  
Protocol 2 này giải quyết được (một phần) vấn đề plaintext password được truyền trên đường truyền. Và trên Internet cũng có nhiều website thưc hiện cái protocol 2 này để xác thực người dùng. Câu hỏi là: protocol 2 này có những vấn đề gì? Mình cũng đưa ra đây lại protocol mà MrNothing đề xuất:

Protocol 3 wrote:
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.  
Câu hỏi vẫn là: Protocol 3 này có những vấn đề gì? Mời các bạn phân tích các protocol này cho vui. Hoặc là mô tả protocol mà bạn đang sử dụng để mọi người tham khảo, nhất là các bạn lập trình viên đó. PS: mặc dù đã có nhiều protocol hay hơn, nhưng mình nghĩ cứ từng bước đã, tìm hiểu những vấn đề của các protocol đang được bạn sử dụng, thì từ đó mới có thể xây dựng các protocl khác an toàn hơn.]]>
/hvaonline/posts/preList/28909/178192.html#178192 /hvaonline/posts/preList/28909/178192.html#178192 GMT
Re: [Thắc mắc] Bảo mật site chứng khoán /hvaonline/posts/preList/28690/178191.html#178191 /hvaonline/posts/preList/28690/178191.html#178191 GMT Re: Thiết kế giao thức trao đổi khóa giữa Alice và Bob đã chia sẻ password /hvaonline/posts/preList/28899/178135.html#178135 /hvaonline/posts/preList/28899/178135.html#178135 GMT Re: Tìm tài liệu Cơ chế format và phục hồi trên đĩa cứng sử dụng FAT32 /hvaonline/posts/preList/28890/178109.html#178109 /hvaonline/posts/preList/28890/178109.html#178109 GMT Re: Tìm tài liệu Cơ chế format và phục hồi trên đĩa cứng sử dụng FAT32 /hvaonline/posts/preList/28890/178107.html#178107 /hvaonline/posts/preList/28890/178107.html#178107 GMT Re: Lại một câu hỏi thú vị về mạng /hvaonline/posts/preList/28875/178017.html#178017 /hvaonline/posts/preList/28875/178017.html#178017 GMT Re: Programming và Security /hvaonline/posts/preList/28827/177921.html#177921 /hvaonline/posts/preList/28827/177921.html#177921 GMT Re: Những cuốn sách bạn đang đọc ? /hvaonline/posts/preList/28765/177917.html#177917 /hvaonline/posts/preList/28765/177917.html#177917 GMT Re: Những cuốn sách bạn đang đọc ? /hvaonline/posts/preList/28765/177880.html#177880 /hvaonline/posts/preList/28765/177880.html#177880 GMT Re: Kiểm tra checksum, thay đổi checksum /hvaonline/posts/preList/28731/177411.html#177411 /hvaonline/posts/preList/28731/177411.html#177411 GMT Re: Kiểm tra checksum, thay đổi checksum

rongchaua wrote:
Không hiểu là ý bạn choc_ đang nói đến integrity của message hay reliability của message? Bởi vì bạn có nói với Z0rr0 là "mình chưa thấy ai sử dụng checksum như là một cách để bảo vệ Integrity cả." nên mình không hiểu lắm. Integrity là chỉ tính toàn vẹn của dữ liệu. Tức là nó dùng để kiểm tra dữ liệu có thay đổi trên đường truyền hay không? Như bạn choc_ cũng đã nói là khi thay đổi dữ liệu thì md5sum thay đổi thì sau khi dữ liệu đến máy của mình thì mình so lại sẽ thấy md5sum thay đổi thì mình biết dữ liệu đã bị thay đổi trên đường truyền. Tức là mình là dùm checksum để kiểm tra tính Integrity. Vậy nếu không dùng checksum để kiểm tra tính Integrity thì mình cũng không biết có cách nào khác để kiểm tra nữa.  
Câu hỏi là thế này: làm sao bạn có thể chắc chắn là cái md5sum ban đầu mà bạn nhận được không phải là md5sum đã bị attacker thay đổi rồi? Nếu bạn đã có một kênh truyền dữ liệu (ở đây là truyền cái md5sum ban đầu) an toàn, thì cứ sử dụng kênh truyền ấy để truyền file. Nhưng mà vấn đề là kênh truyền của bạn không an toàn, bởi có một thằng active attacker nó đang lắng nghe trên đó và sẵn sàng sửa dữ liệu theo nhu cầu của nó. Ví dụ như bạn vào website www.hvaonline.net, trên đó hiện lên link đến một file X, và một câu thông báo file X này có checksum là A. Nếu có một thằng active attacker ở giữa bạn và máy chủ HVA, thì ngay tại thời điểm đó, nó có thể vẫn để link đến X, nhưng đã đổi cái checksum thành một cái A' nào đó. Khi bạn click vào X, nó sẽ đưa cho bạn X', mà checksum của X' là A'. Nên mình nói là checksum không thể nào là biện pháp để đảm bảo tính Integrity của dữ liệu được cả. Nó có thể là một phần (rất nhỏ) của giải pháp mà thôi. Nếu bạn muốn tìm hiểu giải pháp thì xem thử MAC và digital signature. Rộng hơn là tìm hiểu giải pháp xây dựng một cái secure communication channel, mà mình đã nói từ đầu rồi đó. @MrNothing: sorry nhưng bài của bạn trình bày rối quá, mình không đọc, nên không thể thảo luận với bạn được. Cập nhật: mình muốn nói thêm một chút về Integrity (mình dịch là toàn vẹn) trong khung cảnh an toàn thông tin. Mình thấy nhiều bạn có vẻ như hiểu chưa đúng cái khái niệm này. Đảm bảo integrity của dữ liệu không phải là đảm bảo việc dữ liệu không bị thay đổi. Hiểu như thế là hiểu chưa đúng. Đảm bảo được integrity của dữ liệu là đảm bảo dữ liệu không bị thay đổi bởi những người không có quyền. Nói cách khác, cho phép một số người có quyền thay đổi dữ liệu, và ngăn chặn những người không có quyền thực hiện việc đó. Đây cũng là tác dụng chính của cryptography: cho một số người làm được một số việc, và ngăn chặn tất cả những người còn lại làm những việc đó. Trong cuốn Practical Cryptography, các tác giả so sánh nó giống như cái ổ khóa, ai có chìa khóa thì vào, không có thì ở ngoài. Rất khác với bức tường, khi người ta dựng bức tường lên, thì người ta mong muốn là tất cả mọi người đều phải ở ngoài bức tường đó (trừ khi người đó có cái vòng đi xuyên tường của ĐôReMon). Trở lại với checksum, nếu chỉ có checksum, thì ai cũng có quyền đổi dữ liệu và tạo ra checksum cho dữ liệu mới. Ai cũng làm được việc này và không ai có thể có cách nào phát hiện ra được dữ liệu đã bị thay đổi bởi những người không có quyền. Với MAC, nó cho phép một số người (giữ key) có quyền thay đổi dữ liệu, và ngăn cản những người không có quyền (không có key) làm việc đó. Nó cũng cung cấp cơ chế để bên nhận dữ liệu có thể phát hiện khi dữ liệu bị thay đổi bởi những người không có quyền. Đó là sự khác biệt cơ bản giữa checksum và MAC. Đó cũng là lý do mà mình nói là checksum không bao giờ được dùng để đảm bảo Integrity.]]>
/hvaonline/posts/preList/28731/177404.html#177404 /hvaonline/posts/preList/28731/177404.html#177404 GMT
Re: Kiểm tra checksum, thay đổi checksum

rongchaua wrote:
Cho mình hỏi bạn choc_ ở đoạn này. Ý bạn choc_ là có thể "làm lại" cái file để nó có lại cái checksum như cũ sau khi sửa chữa? Ví dụ là mình cần 1 file từ 1 nguồn tin cậy. Tuy nhiên mình không download được file mà chỉ có md5 của file đó. Bạn mình lại có file đó, nó gởi cho mình. Vậy nó có thể thay đổi file đó và tạo lại một checksum md5 y chang như file của nguồn tin cậy? Nếu ý bạn chọc là như vậy thì có thể cho giới thiệu cho mình tên cái tool đó được không. Vì mình chỉ thấy regenerate file để có được checksum CRC32 chứ MD5 thì mình chưa thấy.  
Nếu đã có sự xuất hiện của một active man-in-the-middle rồi thì chẳng có nguồn nào là đáng tin cậy (nếu không có cơ chế kiểm tra chữ ký hay MAC này nọ). Cái ý tưởng attack ở đây là mình đã thay đổi luôn cái md5sum rồi, nên md5sum mà bạn thấy thực ra không phải md5sum ban đầu. Cái dạng tấn công mà các bạn đang nói, là dạng second preimage attack, kiểu như cho X tìm Y (Y <> X), sao cho H(Y) = H(X). Cho đến nay, MD5 vẫn an toàn với loại tấn công này. Tuy nhiên có một dạng tấn công khác đã được triển khai rất thành công trên MD5 là chosen-prefix collision. Đây là dạng tấn công được dùng để tạo ra các rogue ca hồi tháng 11 năm ngoái. Dạng này có thể hiểu nôm na là attacker được quyền chọn 2 cái prefix bất kỳ, rồi họ sẽ có thể chỉnh sửa/padding up chúng để kết quả có 2 certificate (hay 2 binary hay 2 file zip) khác nhau nhưng có cùng md5sum. Xem thêm các nghiên cứu sau đây để hiểu về dạng tấn công kể trên: http://www.win.tue.nl/hashclash/rogue-ca/ http://cryptography.hyperlink.cz/2004/collisions.htm http://www.doxpara.com/md5_someday.pdf Cập nhật: sửa một lỗi typo liên quan đến đoạn nói về second preimage attack.]]>
/hvaonline/posts/preList/28731/177308.html#177308 /hvaonline/posts/preList/28731/177308.html#177308 GMT
Re: In liên tục các chữ số ra mang hình. /hvaonline/posts/preList/28750/177304.html#177304 /hvaonline/posts/preList/28750/177304.html#177304 GMT Re: In liên tục các chữ số ra mang hình. /hvaonline/posts/preList/28750/177193.html#177193 /hvaonline/posts/preList/28750/177193.html#177193 GMT Re: Kiểm tra checksum, thay đổi checksum

Z0rr0 wrote:
An ninh thông tin có 3 mục tiêu quan trọng để đảm bảo: Confidentiality, Integrity, Availability. Trong đó checksum là một biện pháp đóng góp vào mục tiêu Integrity, còn gọi là tính toàn vẹn của thông tin. Tức là nó giúp phía nhận kiểm tra liệu dữ liệu khi nhận được có giống như ban đầu của bên gửi không.  
chắc không bạn Z0rr0? mình chưa thấy ai sử dụng checksum như là một cách để bảo vệ Integrity cả. việc xây dựng một cái secure communication channel, để truyền nhận dữ liệu an toàn bất chấp sự có mặt của một active attacker nhưng vẫn đảm bảo được các tiêu chí CIA không phải là một việc đơn giản, mà checksum chắc chắn không phải là một phần của giải pháp. @zu4er: như StartGhost nói, mấy cái hash hay crc chỉ dùng để phát hiện lỗi thôi. nếu mà attacker muốn, thì họ có thể vừa thay đổi cái file mà bạn download về, vừa tính lại checksum, thì cũng chẳng ai biết. việc này là làm được hoàn toàn, chẳng có gì là ghê ghớm cả.]]>
/hvaonline/posts/preList/28731/177191.html#177191 /hvaonline/posts/preList/28731/177191.html#177191 GMT
Re: Xin ý kiến các anh chị về định hướng cho BKITNS /hvaonline/posts/preList/28590/176573.html#176573 /hvaonline/posts/preList/28590/176573.html#176573 GMT Re: script configure pop3&smtp for outlook /hvaonline/posts/preList/28632/176570.html#176570 /hvaonline/posts/preList/28632/176570.html#176570 GMT Re: Xin ý kiến các anh chị về định hướng cho BKITNS /hvaonline/posts/preList/28590/176566.html#176566 /hvaonline/posts/preList/28590/176566.html#176566 GMT Re: Xin ý kiến các anh chị về định hướng cho BKITNS

k4i wrote:
Rồi sẽ có lúc các bạn thấy những kiến thức về AI, Data Mining, Machine Learning, Toán rời rạc, Algorithm nó quan trọng đến thế nào và hay ho đến thế thế nào nếu áp dụng vào Information Security  
hơ hơ bạn kêu mình *đao to búa lớn* còn bạn thì vác đại bác ra chơi :-p. Machine Learning bản thân nó là một ngành mới (thậm chí trên thế giới chỉ có một hai trường đại học là có machine learning department). Việc áp dụng Machine Learning vào Information Security lại càng là một hướng nghiên cứu rất mới, bằng chứng là đến tận cuối năm 2006, JMLR, journal hàng đầu về nghiên cứu Machine Learning, mới có một special issue về việc áp dụng các kỹ thuật và công cụ của Machine Learning cho các vấn đề của Computer Security http://www.cs.fit.edu/~pkc/mlsec/). Mà bạn cũng chú ý, đây chỉ là các đề tài nghiên cứu, mình cũng không rõ và chưa thấy các ứng dụng đã được triển khai trong thực tế của Machine Learning vào Information Security là thế nào. Mời bạn K4i chỉ dẫn cho vài đường.]]>
/hvaonline/posts/preList/28590/176498.html#176498 /hvaonline/posts/preList/28590/176498.html#176498 GMT
Re: Xin ý kiến các anh chị về định hướng cho BKITNS /hvaonline/posts/preList/28590/176452.html#176452 /hvaonline/posts/preList/28590/176452.html#176452 GMT Re: Xin ý kiến các anh chị về định hướng cho BKITNS

H4x3 wrote:
Hệ thống là tất cả mọi thứ, từ công cụ đến con người . Nguy cơ là các nhân tố có thể tác động xấu đến hệ thống . Bên ngoài có nghĩa là trừ những cái như nó bị cháy nổ hay chập mạch  
Sai bét.

H4x3 wrote:
Nếu anh đã làm 5 năm sao trên bài post về lỗi C anh lại nói là thầy cho ra bài tập ??  
Ơ thế có luật không được phép đi học tiếp sau khi làm việc vài năm àh? Mà việc mình đang học hay làm gì thì có liên quan gì đến mấy câu hỏi của mình ta :-p. Mình nhớ không lầm thì bạn conmale đã hơn một lần chỉnh các bạn ở chỗ này rồi.]]>
/hvaonline/posts/preList/28590/176450.html#176450 /hvaonline/posts/preList/28590/176450.html#176450 GMT
Re: Xin ý kiến các anh chị về định hướng cho BKITNS

H3x4 wrote:
Là biết cách làm cho một hệ thống được an toàn trước các nguy cơ bên ngoài !  
Hệ thống là gì? An toàn là sao? Nguy cơ là gì, xác định ra sao? Bên ngoài nghĩa là ở đâu?

H3x4 wrote:
Nói như anh choc_ thì em hỏi lại :vậy anh đang học gì ?  
Mình đã làm "chuyên gia bảo mật" theo cái cách mà các bạn mơ ước (nhưng không hiểu là làm gì) được hơn 5 năm rồi bạn ạh.]]>
/hvaonline/posts/preList/28590/176446.html#176446 /hvaonline/posts/preList/28590/176446.html#176446 GMT
Re: Xin ý kiến các anh chị về định hướng cho BKITNS /hvaonline/posts/preList/28590/176441.html#176441 /hvaonline/posts/preList/28590/176441.html#176441 GMT Re: Xin ý kiến các anh chị về định hướng cho BKITNS /hvaonline/posts/preList/28590/176380.html#176380 /hvaonline/posts/preList/28590/176380.html#176380 GMT Re: BKITNS HAX0R Course /hvaonline/posts/preList/28520/175929.html#175929 /hvaonline/posts/preList/28520/175929.html#175929 GMT Re: BKITNS HAX0R Course /hvaonline/posts/preList/28520/175865.html#175865 /hvaonline/posts/preList/28520/175865.html#175865 GMT Re: BKITNS HAX0R Course /hvaonline/posts/preList/28520/175862.html#175862 /hvaonline/posts/preList/28520/175862.html#175862 GMT