Messages posted by: choc_

hehehe để mình thử liệt kê mấy chỗ sai nha:

1. tiêu đề là "Thuật toán mã hóa Diffie Hellman" --> lẽ ra phải là "giao thức Diffie-Hellman trong mật mã học". (Whitfield) Diffie và (Martin) Hellman là tên của hai ông giáo sư, chứ không phải là tên của một ông. Diffie-Hellman nên được xem là giao thức hơn là thuật toán. cái sai này chấp nhận được, vì "sự phong phú của tiếng Việt".

2. "tuy nhiên vấn đề mình gặp phải là do đây là mã hóa bí mật nên Phải mã hóa Key cua nó." --> cái này lẽ ra phải là "tuy nhiên mình gặp vấn đề là do đây là mã hóa đối xứng nên phải tìm cách thống nhất key giữa hai bên". cái sai này là không chấp nhận được, vì nó không còn là "sự phong phú của tiếng Việt" nữa, mà là sai về kiến thức. Diffie-Hellman không phải là để mã hóa key, mà là để tạo key.

tóm lại: nếu là người chưa tìm hiểu về cryptography thì có thể châm chước được, nhưng nếu đang làm luận văn về cryptography thì...đáng báo động về kiến thức cơ bản.

Không hiểu bạn phudaica8 học hành ra sao khi làm tới mức luận văn rồi, vậy mà chỉ viết một đoạn rất ngắn về crypto thôi nhưng đã sai quá trời. Mình nghĩ là bạn nên dành nhiều thời gian hơn để mà học lại cho tốt về crypto trước khi làm luận văn về nó.

Anyway, muốn đọc về Diffie-Hellman thì cứ đọc ngay cái paper 1976 của hai ông này: www.eecs.berkeley.edu/~christos/classics/diffiehellman.pdf. Muốn tham khảo thêm các tài liệu khác liên quan thì lên Wikipedia: http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

hơ hơ hay quá. mình bận việc nên không lên HVA mấy ngày không ngờ là có nhiều tranh luận sôi nổi vậy.

nhìn lướt qua một lượt, thấy cái nào cũng có vấn đề hết trơn. mấy hôm nay lúc rảnh, mình ngồi suy nghĩ, thấy có vẻ như thiết kế được một cái protocol như vậy, với yêu cầu là đường truyền luôn có người rình mò theo dõi chỉnh sửa, dường như là bất khả thi hay sao áh.

ví dụ như nếu mình dùng AJAX để thực hiện phía client side cho protocol, thế lỡ attacker nó sửa cái javascript của mình lại, thay vì H(P) rồi mới gửi đi, thì nó cứ gửi P đi luôn. nhưng cứ để xem sao.

giờ đặt cục gạch trước, tí nữa có thời gian mình sẽ thử *đào xới* mấy cái protocol của các bạn xem sao.

Chào các bạn,

Trong topic của MrNothing (thật ra topic này cũng giống topic kia thôi, nhưng mình viết lại cho nó dễ nắm bắt hơn), mình có nói bài toán mà MrNothing đặt ra là rất phổ biến, tự vì nó là một dạng tổng quát hơn của bài toán làm thế nào xác thực được người dùng bằng mật khẩu.

Mình thấy bây giờ mọi người nhào nhào làm two-factor authentication, rồi multi-factor authentication, nhưng hình như cái cách xác thực đơn giản nhất là xác thực bằng mật khẩu vẫn chưa được làm đúng cách.

Ví dụ, site HVAOnline.net này nha (mình chỉ đưa ra ví dụ cho nó dễ thấy thôi, chứ một website như HVAOnline thì kô cần phải làm cái gì khác hơn). Có hai form xác thực, một là xuyên qua HTTP, hai là xuyên qua HTTPS. Mình không quan tâm đến tầng transportation ở đây, bởi mình đưa ra một yêu cầu là: luôn có người theo dõi trên đường truyền. Nói cách khác, protocol phải an toàn bất kể kênh truyền như thế nào. Nên tính ra thì HVAOnline chỉ có một protocol như sau:

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.

Có cách nào đo mức độ an toàn thông tin của một tổ chức không chỉ? Đo thật đó, chứ không phải kiểu cảm tính là "tôi có vài người giỏi hay lên HVAOnline.net nên tôi thấy tôi an toàn hơn". Có cách nào so sánh hai hệ thống, xem hệ thống nào an toàn hơn không?

Bạn MrNothing này lần nào viết bài cũng hết sức lủng củng, mặc dù bài của bạn cũng có ý đọc được, nhưng do cách trình bày dở quá, thành ra không ai đọc, mà có đọc cũng không hiểu ý bạn muốn nói gì. Mình thấy hình như cái bệnh này khá phổ biến thì phải smilie

.

Ví dụ như đề tài này, bạn chỉ cần viết đơn giản thế này: thiết kế một giao thức để Alice và Bob có thể tạo ra một shared key từ một shared secret.

Đây là một bài toán phổ biến, chẳng hạn như website của HVAOnline và người dùng, thông qua mật khẩu, có thể sử dụng một cái protocol của bài toán này để xác thực lẫn nhau hay là tạo key để mã hóa dữ liệu truyền giữa hai bên.

Hiện tại cũng có nhiều giao thức giải quyết bài toán này, nên mình nghĩ bạn MrNothing chẳng cần phải "đố" đây là giao thức gì, mà nên để mọi người tự thiết kế một giao thức của riêng mình, rồi mọi người sẽ tấn công giao thức của nhau, thế thì hấp dẫn hơn.

Về chứng minh thì không hiểu ý bạn có phải là semantic security proof là cái giao thức an toàn? Mình nghĩ nếu như thế thì ít bạn sẽ làm được, tự vì phải học và làm chuyên sâu về cryptography thì may ra mới có thể viết một chứng minh như vậy, dẫu là cho một giao thức đơn giản. Nên mình cũng đồng ý với StarGhost là kô nên làm.

@starghost: nói hệ điều hành thì đúng là không chính xác lắm, nói là các công cụ đi kèm hệ điều hành thì đúng hơn. ngoài ra cũng có các công cụ không đi kèm hệ điều hành cũng làm được việc này.

ý mình ở đây là có hiểu cách mà FAT hoạt động cũng chưa chắc đã biết được cách mà công cụ nó format ra sao. ví dụ như có công cụ format chỉ đơn giản là chỉnh sửa boot sector, rồi set hết tất cả sector và FAT entries thành unallocated, set các directory entry thành deleted hết nhưng để nguyên dữ liệu, không chạm vào đó. ngược lại cũng có các công cụ, tương tự như "secure delete", thực sự ghi đè (thường là ghi zero) tất cả các sector.

cơ chế format thì tùy thuộc vào thằng hệ điều hành, chứ bản thân thằng file system đâu có quyết định được đâu. muốn biết cách phục hồi thì phải hiểu FAT file system nó bao gồm những phần nào, mỗi phần có ý nghĩa gì, rồi phải hiểu cả loại file muốn phục hồi nó có những tính chất gì, format của nó ra sao.

giới thiệu cho bạn một tài liệu: cuốn "file system forensic" của brian carrier, tác giả "the sleuth kit". còn muốn "mì ăn liền" thì có thể xài foremost.

Mình kô làm về network nhưng phán chơi cho nó máu: cách làm dở hơi này sẽ làm cho đường truyền chậm đi, có khi chậm chỉ bằng mỗi đường truyền cũ thôi.

@newbieITPro: Security Engineering, tác giả Ross Anderson.

Mình nghĩ bạn nên tập trung học lập trình trước. Học lập trình và làm lập trình sẽ cho bạn một hướng phát triển rất *tự nhiên* trong lĩnh vực computer science.

Sao mình nhấn mạnh chữ tự nhiên? Tự vì bạn sẽ rất dễ bị lạc lối, trừ phi bạn là nhà nghiên cứu lỗi lạc :-D, nếu mà tự dưng bạn lại đặt ra các vấn đề không xuất phát từ nhu cầu thực tế của chính bạn (cái này mình gọi là các vấn đề *không tự nhiên*). Nếu bạn làm lập trình, tự dưng bạn sẽ nảy ra nhu cầu phải học và làm về security, rồi từ đó bạn sẽ thấy là nên học cái gì, làm cái gì, mà không cần phải tự *vú ép* mình :-p.

mình thấy nhiều bạn thích cái luận điểm: muốn bảo vệ hệ thống tốt, thì phải biết về các thủ thuật để hack hệ thống đó.

làm thế nào mà biết hết được các thủ thuật, trong khi số lượng potential attacker là vô tận, lại cực kỳ thông minh sáng tạo và nhiều khi có trình độ cao gấp nhiều lần chúng ta nữa?

đọc nhiều nhỉ, toàn sách "hạng nặng" kô nữa. bạn h4x3 viết review đi, đọc rồi thì thấy thế nào, chỗ nào sách viết hay, chỗ nào sách viết dở, chỗ nào nên tập trung vào, chỗ nào có thể đi nhanh, đọc xong thì có được kiến thức gì, có thể làm gì với kiến thức đó, và bạn đã làm gì rồi, theo hướng dẫn của sách hoặc hay hơn là đẩy các kiến thức mà sách cung cấp lên một tầm cao mới.

thế mới có cái để mà thảo luận chứ phải hông? còn mà cứ liệt kê một đống sách, thì giống...khoe hàng quá.

@rongchaua: có lẽ bạn chưa đọc phần sau khi mình cập nhật. Integrity có thể được hiểu theo nhiều cách khác nhau (và cách mà bạn hiểu cũng là một cách), nhưng mà định nghĩa của Integrity trong bối cảnh Information Security là như phần tô đậm mình đã viết ở bài trên. Bạn có thể tìm thêm các tài liệu khác nói về các khái niệm CIA để kiểm chứng.

Mình có thêm một ví dụ để bạn hiểu: thường mà nghĩ đến việc truyền dữ liệu, thì mọi người sẽ nghĩ ngay đến truyền qua không gian, ví dụ truyền từ server đến client và ngược lại. Ngoài dạng đó ra, thì còn có một dạng truyền dữ liệu đó là truyền theo thời gian. Ví dụ như bạn lưu một file trên đĩa cứng, chính là bạn truyền cái file đó theo thời gian cho chính bạn. Giờ làm thế nào để bạn biết rằng file của bạn không bị người khác thay đổi?

Nếu bạn tính checksum, rồi lưu lại xuống ổ cứng (chính là cái communication channel, trong ví dụ này), thì việc này là vô ích, bởi attacker vẫn có thể sửa file, rồi tính lại checksum, lưu checksum đó xuống ổ cứng. Lần tới bạn mở file ra xem, thấy checksum vẫn đúng, nhưng dữ liệu đã bị thay đổi.

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.

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.

@starghost: dạo này mình bị vấn đề gì đó nhỉ, toàn đọc sai smilie

. cảm ơn bạn starghost.

heheh chương trình này mà viết dạng này thì nếu mà mình nhập vào một số nguyên bự tổ chảng thì nó chạy bao giờ xong ta? bạn fanmaytinh00 thử tìm hiểu về primality test.

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

@h4x3: giờ mới thấy cái trả lời của bạn là "học mấy cái trong trường vững rồi". lúc đầu mình có nói, "đừng có giả bộ cầu thị nếu không phải là cầu thị thật". mình biết tỏng là bạn nghĩ bạn cứng lắm rồi, nên mới đi nghiên cứu hacking.

ôi trời ơi học ở trường mỗi môn một học kỳ 3 tháng, mà dám vỗ ngực kêu "tao vững mấy cái này lắm rồi". mình đi làm vài năm rồi mà còn không dám kêu là vững. ờ chắc tại mình ngu hơn bạn h4x3.

giờ có nhận câu hỏi của mình không, mình cũng bon chen hỏi vài câu cho vui.

hơ hơ cái này là ví dụ của ẹcmin dởm, tự làm khó cho mình. sao lại dùng IP nhỉ? sau này mà có đổi server mail một lần nữa thì lại phải chạy đi đổi IP nữa àh? trong khi nếu mà dùng name, ví dụ như smtp.a.com thì chỉ cần chỉnh trên DNS server là xong.

@K4i: hahaha có người đi theo *chơi* như vậy thì quá sướng rồi mà còn kêu, rồi bạn sẽ phải cẩn thận trong từng lời ăn tiếng nói :-p.

@H4x3: học hành tốt ghê, có câu hỏi đơn giản vậy mà cũng trả lời sai bét.

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.

Ơ ở trên kêu không cần chỉ mà? Đi hỏi paper hay research (mình hiểu là paper hay research theo kiểu nghiên cứu khoa học) thì có nghĩa là bạn đếch biết làm chuyên gia bảo mật là làm những việc gì rồi. Ơ mình không tự nhận mình là chuyên gia, cái job title của mình nó là thế thôi, mọi người cũng kêu mình là vậy, thì mình nhận thế vậy.

Giờ mình đã hiểu tại sao mà không ai thèm chỉ dẫn các bạn. Mình cũng thôi đây, km các bạn. Lolz sao mình nói thế này hoài mà không làm được ta? :-D.

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.

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.

mình thấy có một xu hướng thế này (mà bà con gọi là "bụt chùa nhà không thiên" :-p): ở trường đã có chương trình đào tạo rất rõ ràng, bài bản, và có thầy bà để hỏi luôn, nhưng các bạn sinh viên thì cứ "ui giời ơi, em khốn khổ quá, giờ không biết học gì làm gì hết", rồi lại đi khắp các nơi, góp nhặt các ý kiến vụn vặt, riêng lẽ, và xem cái đó là hướng đi của mình.

nếu các bạn sẽ cãi, "nhưng ở trường không có dạy để trở thành chuyên gia bảo mật!", thì mình có một câu hỏi cho các bạn: làm chuyên gia bảo mật là làm cái gì?

hơ xin ý kiến nữa làm gì nhỉ? cái gì cần nói thì đã nói hết rồi. đừng tỏ ra cầu thị nếu không thật sự cầu thị.

hehehe nếu mà các bạn BKTNS biết tự định hướng thì mình đã không nhào vào *tấn công* làm chi rồi. mà ngộ hen, không hiểu các bạn nghĩ mình phê bình các bạn thì mình được gì ha? các bạn có là cái **** gì đâu.

đừng nghĩ đặt một cái mục tiêu thật dữ dội, kiểu như sống bằng cách bán bug kiếm tiền, thì tự dưng mình cũng sẽ dữ dội. cái cách mà các bạn đang làm (mà thật ra các bạn có *cách* nào đâu, lâu lâu lượm được 1 bài thì làm theo bài đó) thì có 10 năm cũng chẳng đi đến được đâu. dẫu vậy mình sẽ chờ 1 năm nữa xem các bạn có làm được gì ra trò hay không. ơ mà ra trò gì nhỉ? các bạn có mục tiêu gì cụ thể hông? hay là cứ 1 năm, rồi 1 năm nữa?

mình rất mê cá độ, thí dụ giờ các bạn đặt 1 mục tiêu là 1 năm nữa, các bạn sẽ tìm được 1 remote code execution bug và có exploit code luôn của một trong các browser thịnh hành nhất Internet đi (là do các bạn đang nghĩ tìm lỗi với khai thác lỗi là cách bắt đầu tốt, nên mình mới chọn mục tiêu này), rồi mình cá với nhau chơi, xem coi sự thật thế nào. chứ còn cứ đặt một móc thời gian, mà không ghi gì cụ thể hết, thì vài năm sau, mình e sẽ lại thấy bạn Suto kêu gào "sau 5 năm làm việc...", mà rốt cuộc thì bạn và BKTNS không có thành quả nào hết.

mình thấy rất tiếc là có vẻ các bạn không thích nghe những lời khó nghe. ôi trời ơi, khen thì dễ lắm, chỉ cần nói xạo là khen được thôi, chê đúng kìa mới khó và cần thiết. rốt cuộc thì các bạn dở hơn là mình nghĩ.

@bvKim: bạn nói bạn làm trong ngành giáo dục mà cách trình bày một bài viết sao cho dễ đọc cũng không biết sao?

@h4x3: ơ thế àh? thế thì bạn làm một bài phân tích xem sao?

@H4x3: lolz bạn làm mình mắc cười quá. học 2 năm trời (nghe rất là ghê) mà lên forum của bạn, thấy có cái bài return2libc mà bạn cũng không làm được.

còn về việc học của bạn, thì cũng chính bạn thú nhận thôi, mình có nói thêm gì đâu. mà có lẽ bạn đọc những gì mình viết mà bạn không chịu suy nghĩ. đấy là điều đáng tiếc cho bạn. mình cũng mong là các bạn trong team BKTNS nhìn vào đây để biết họ đang noi gương một leader như thế nào mà tự biết cách điều chỉnh lại cho phù hợp hơn.

PS: mình cũng không được học ở lớp KSTN, đó là điều đáng tiếc cho mình. bạn conmale nói một câu rất hay, "Có những việc xảy ra ngay lúc này mình không thấy hoặc không cảm nhận được gì cả. Chỉ có thể thấy và cảm nhận về sau, khi mà mọi sự có thể đã trễ tràng".

mà thôi, nông nỗi là bản chất của tuổi trẻ mà.