Tui move trash với lý do:
+ Không có algorithm cho việc dịch ngược chuỗi hash, chỉ có thể brute force.
+ HVA không cổ vũ "tấn công vào csdl của 1 site"  

Sorry chắc chữ "hash" là hơi sai, nếu bạn biết một thuật toán mã hóa thì bạn có thể đọc nó và viết thuật toán giải mã được và ở đây là mã hóa 2 chiều!
HVA không cổ vũ tấn công vào csdl của 1site, tôi cũng thế! phần đầu để nói về hoàn cảnh lịch sử thôi! Không lẽ tôi nên edit lại chữ "tấn công" bằng chữ "xem", rồi post tiếp?
Cái tôi muốn hỏi và thảo luận ở đây là:

Vậy có ai có kinh nghiệm về Encrypt với Decrypt thì help em vài hướng đi với ah. Hoặc ai đã từng gặp trường hợp tương tự thì... tốt quá  

 

bài cũ của em ở đây:
/hvaonline/posts/list/19423.html#quick 

nếu bạn biết một thuật toán mã hóa thì bạn có thể đọc nó và viết thuật toán giải mã được 

em ko có quyền reply nhưng cái ô Quick Reply nó vẫn mở và khi em post qua đấy nó .. chẳng ra cái gì cả. Và em mất thời gian gõ vào đấy :d  

em ko có quyền reply nhưng cái ô Quick Reply nó vẫn mở và khi em post qua đấy nó .. chẳng ra cái gì cả. Và em mất thời gian gõ vào đấy :d  

Vậy thì lỗi ở đây là gì? 

Dựa vào đâu bồ khẳng định đây là 2 chiều?
 

Bồ có biết người ta dùng thuật toán gì không mà đòi decrypt. Thuật toán 2 chiều có 1 đống, và giải mã 1 cái cũng đủ mất thời gian rồi.  

Nếu không biết được code thì đừng mong decrypt nổi. 

(cùng input thì nó có cùng output, input thay đổi nhỏ thì output thay đổi nhiều)  

Thì dựa vào hoàn cảnh lịch sử đã nêu rồi đó, bác FaiL đọc chẳng cẩn thận gì cả, y như 1 filter thấy thấy vài từ lung tung là move vào trash, close lun vậy. và khi là 2-chiều, thì bác biết thuật toán mã hóa chắc sẽ viết được đoạn giải mã ngay thui? 

Cũng ko fai 1 đống lắm đâu mà, hơn nữa khi người ta viết thuật toán mã hóa (2 chiều), người ta cũng viết luôn thuật toán giải mã. Cũng giống như mọi sự phức tạp đều bắt nguồn từ những nguyên tắc đơn giản vậy. Hơn nữa ở đây mình muốn hỏi xem ai có "kinh nghiệm" và hướng đi... Lúc bạn quan sát về đặc điểm của thuật toán cũng đã nói lên vài điều, cũng như khi bạn thấy output luôn có 32 ký tự, bạn nghĩ đến md5, bạn thấy output tăng kích thước lên so với input, bạn nghĩ đến base64, bạn thấy có 1 ít ký tự % lẫn lẫn vào, bạn nghĩ đến url_encode; bạn thấy output chẳng ra gì thì nghĩ đến phép XOR... 

Nếu không biết được code thì đừng mong decrypt nổi. 

Câu này em nghĩ là sai hoàn toàn.
Up phát nào
 

Lỗi chức năng gì? Quick Reply có bị gì đâu? 

Quanh đi quẩn lại là bồ ko có chứng cớ khẳng định nó là 2 chiều, cũng không có thuật toán mã hoá nó. Vậy thì phải làm sao bây giờ? Liệt kê hết tất cả thuật toán mã hoá để thử à? Có đáng move trash ko???
Vả lại:

(cùng input thì nó có cùng output, input thay đổi nhỏ thì output thay đổi nhiều)  

Đọc thêm về hash coi đi bồ! 

Vậy thử đi. Bản thân tôi thì cho rằng bất cứ ai dù thông minh đến đâu cũng không thể giải mã 1 thông điệp mà không biết nó được mã hóa bằng cách nào. Nói thật, ngay cả biết chính xác nó được mã hóa cách nào thì việc giải mã đã rất khó rồi. 

Commale wrote:

Lỗi chức năng gì? Quick Reply có bị gì đâu? 

Cái này thì... thế này anh nè: nếu em ko đăng nhập thì ko có Quick reply nè. Những chỗ không cần/ ko dc reply thì ko có nè. Nhưng theo cái link kia, mod close bài rồi mà nó vẫn còn ô Quick reply, báo hại làm em ko để ý, gõ bao nhiêu thứ vào đấy, click submit và.. xịt. Mất công em tý thui mà.

....
 

StarGhost wrote:

Vậy thử đi. Bản thân tôi thì cho rằng bất cứ ai dù thông minh đến đâu cũng không thể giải mã 1 thông điệp mà không biết nó được mã hóa bằng cách nào. Nói thật, ngay cả biết chính xác nó được mã hóa cách nào thì việc giải mã đã rất khó rồi. 

Tôi đã lên cục quân báo (phố chùa 1 cột - hn) và nghe mấy bác ở đó kể chuyện về việc giải mã công điện gì gì đó của thailand Và cũng nhận được một chút về lý thuyết cho vấn đề mã hóa + giải mã, anw, tôi sẽ vẫn cố thui! 

@CK:
+ Nếu bồ muốn người khác tôn trọng bồ thì trước hết nên tôn trọng người khác trước đã. Khi trích dẫn cần đúng nguyên văn. Trích không đúng nguyên văn tôi delete ráng chịu.
...
 

+ Đặt vấn đề cần súc tích rõ ràng. Nếu bồ có kiến thức cơ bản về mã hóa hay hash thì đã ko đi cầu cứu linh tinh rồi sau đó cố gắng biện hộ cho sự mơ hồ của mình.
 

Sorry chắc chữ "hash" là hơi sai 

+ Tui cho bồ một hướng:
Tạo password với 1 chữ a, 1 số 1, hoặc password 123, sau đó xem chuỗi đã được "mã hóa" ra thế nào. Copy chuỗi đó, paste vào google, sau đó xem các link xem có manh mối gì không. 

Suy nghĩ kỹ trước khi post bài tiếp theo! Không dưới 3 người nhắc bồ về encrypt, decrypt, hash...
PS: Bỏ cái giọng điệu phán xét "mót" đi. Khi thảo luận nên chú ý vào lập luận và ý kiến của mình.  

Theo tôi có lẽ bồ nên học cách lấy được code cái site gì đó thì nhanh hơn là học giải mã cái database kia. 

Bản thân tôi thấy bồ CK hỏi rất rành mạch rõ ràng và đây cũng là một đề tài thú vị để thảo luận. Bồ StarGhost với FaL cảm thấy không thích thảo luận về nó thì đừng tham gia, còn nếu tham gia thì nên tập trung tìm giải pháp, không nên bàn ra.

Bồ CK đang cần phải triển khai một http://en.wikipedia.org/wiki/Chosen_plaintext_attack (to mfeng:tôi nghĩ đây là chosen-plaintext attack bởi CK có thể chọn plaintext là user, email hay password và quan sát được output). Theo lý thuyết thì nhiệm vụ cuối cùng của cryptanalyst là lấy được key được sử dụng để mã hóa (từ đó giải mã được hết các ciphertext). Tuy nhiên, trong thực tế, nhiệm vụ trước tiên của cryptanalyst phải làm là tìm hiểu thuật toán mã hóa được sử dụng. Nên rõ ràng, vấn đề của CK là rất thực tế và đáng tìm hiểu.

Trong trường hợp này, đánh giá đối tượng mà CK đang tấn công, tôi dự đoán họ chỉ sử dụng những thuật toán mã hóa thông dụng như RC4, DES, TDES hoặc AES (có thể thêm Twofish hoặc Blowfish, nhưng tôi nghĩ xác suất là thấp).

Nếu là tôi, để tìm hiểu xem đối tượng sử dụng thuật toán nào, tôi sẽ:

* Tìm hiểu ngôn ngữ mà họ sử dụng, và xem ngôn ngữ đó, by default, là hỗ trợ những thuật toán mã hóa nào.

* Tìm hiểu phần mềm mà họ đang sử dụng, và xem phần mềm đó, có những module nào hỗ trợ mã hóa, theo những thuật toán nào.

-m 

Tôi thấy một điều kỳ lạ ở đây là tất cả các ciphertext đều là 30 byte - 240 bit, CK có thể confirm lại hay không?
 

Khi em "xem" csdl của 1 site, password, username, email của table user đã bị mã hóa. Tất cả đều có 30 ký tự: (A_Z a_z 1_9 + và /) như dưới đây. Nhưng khi em view profiles của mình thì có username + email, (password thì bằng thủ thuật mới thấy).
 

cậu thử forgot password account của cậu, xem cái mail forgot password nó gởi thông tin gì về:
Trường hợp 1: Nếu nó gởi về mail cậu một link để activate account +reset password mới. thì cậu quan sát cái tham số hash truyền trong activate link, sau đó vào database xem cái hash đó nằm ở đâu. Sau đó cậu forgot password admin, rồi vào lại cái database coi cái hash activate của admin sau đó làm giả link activate account rồi click vào rồi reset password admin theo ý cậu.
Trường hợp 2: Nếu cái mail forgot password nó gởi cho cậu về là cái password cũ, điều đó chứng tỏ là thuật toán encrypt password của nó có thể decrypt đc nhé ( mã hóa 2 chiều gì đó).
Trường hợp 3: Nó gởi cho cậu một password mới tinh (nó đã reset sẵn), thì có thêm một hướng khác là cậu tìm thuật toán reset password đôi khi lại đơn giản hơn là thuật toán encrypt password của nó đó.  

Trong trường hợp này, đánh giá đối tượng mà CK đang tấn công, tôi dự đoán họ chỉ sử dụng những thuật toán mã hóa thông dụng như RC4, DES, TDES hoặc AES (có thể thêm Twofish hoặc Blowfish, nhưng tôi nghĩ xác suất là thấp).

Nếu là tôi, để tìm hiểu xem đối tượng sử dụng thuật toán nào, tôi sẽ:

* Tìm hiểu ngôn ngữ mà họ sử dụng, và xem ngôn ngữ đó, by default, là hỗ trợ những thuật toán mã hóa nào.

* Tìm hiểu phần mềm mà họ đang sử dụng, và xem phần mềm đó, có những module nào hỗ trợ mã hóa, theo những thuật toán nào.
 

Theo ý kiến cá nhân, 240 bits để lưu user name, email, password có vẻ hơi ít. Nhóm kí tự trong 240 bits là A-Z,a-z,0-9,+,/ cho thấy bước cuối cùng trước khi lưu vào CSDL có thể là encode BASE64.

Trường hợp đây là mã hóa 2 chiều (mã hóa đối xứng - symmetric encryption), nếu website sử dụng các thuật toán đơn giản hoặc DES, khả năng bạn có thể vét cạn để tìm khóa là khả thi (trong trường hợp này bạn phải biết rõ tên thuật toán mã hóa). Còn với 3DES, IDEA, RC4, RC5, RC6 và nhất là AES, khả năng với một cá nhân tìm ra khóa mã là cực khó.  

Theo suy nghĩ chủ quan của tôi, việc toàn bộ database được mã hóa cho thấy đối tượng đã quan tâm ở một mức độ nhất định nào đó đến encryption, và cũng chứng tỏ một phần về kiến thức cryptography của người phát triển hệ thống. Vì vậy không ngoại trừ khả năng quá trình encryption được thiết kế không đơn giản là chỉ dùng 1 thuật toán. Thậm chí trong quá trình của thuật toán có thể cũng bị thêm thắt để chống những kiểu tấn công phổ biến.  

Base64Chars =	"ABCDEFGHIJKLMNOPQRSTUVWXYZ" & _
			"abcdefghijklmnopqrstuvwxyz" & _
			"0123456789" & _
			"+/"
	'f1,f2,f3,f4 la` cac ha`m so hoc thui
	Public Function base64_encode( byVal strIn )
		Dim c1, c2, c3, w1, w2, w3, w4, n, strOut
		For n = 1 To Len( strIn ) Step 3
			c1 = Asc( Mid( strIn, n, 1 ) )
			c2 = Asc( Mid( strIn, n + 1, 1 ) + Chr(0) )
			c3 = Asc( Mid( strIn, n + 2, 1 ) + Chr(0) )
			w1 = f1() 
			w2 = f2()
			If Len( strIn ) >= n + 1 Then 
				w3 = f3() 
			Else 
				w3 = -1
			End If
			If Len( strIn ) >= n + 2 Then 
				w4 = f4()
			Else 
				w4 = -1
			End If
			strOut = strOut + mimeencode( w1 ) + mimeencode( w2 ) + _
					  mimeencode( w3 ) + mimeencode( w4 )
		Next
		base64_encode = strOut
	End Function

	Private Function mimeencode( byVal intIn )
		If intIn >= 0 Then 
			mimeencode = Mid( Base64Chars, intIn + 1, 1 ) 
		Else 
			mimeencode = ""
		End If
	End Function

Kiến thực của người phát triển hệ thống cũng không nói lên được gì, bằng chứng là nó vẫn có injection với XSS đấy thôi