Xin cho biết , các phương thức mã hoá mật khẩu như SHA, SSHA, MD5, SMD5, CRYPT
- Chúng có tác dụng , chức năng, công dụng, ứng dụng như thế nào ?
- Trên phương diện bảo mật thì phương thức mã hoá mật khẩu nào (ở trên) tốt nhất .
+ MD5 là tốt nhất
- Hiện tại có cách nào "đọc" được nội dung bên trong, một khi sử dụng các phương thức mã hoá trên ?
+ tool Passwordspro
- Các phương thức mã hoá mật khẩu ở trên thực tế chúng được áp dụng cho những phần mềm nào trên server, xin cho một vài ví dụ những phần mềm áp dụng phương thức mã hoá mật khẩu này cho phần mềm A nhưng không áp dụng được phương thức mã hoá mật khẩu cho phần mềm B .
+ MD5 thường dùng cho mã nguồn WEB PHP
Cám ơn anh em đã đọc nội dung này  

msdn wrote:

Xin cho biết , các phương thức mã hoá mật khẩu như SHA, SSHA, MD5, SMD5, CRYPT
- Chúng có tác dụng , chức năng, công dụng, ứng dụng như thế nào ?
- Trên phương diện bảo mật thì phương thức mã hoá mật khẩu nào (ở trên) tốt nhất .
+ MD5 là tốt nhất
- Hiện tại có cách nào "đọc" được nội dung bên trong, một khi sử dụng các phương thức mã hoá trên ?
+ tool Passwordspro
- Các phương thức mã hoá mật khẩu ở trên thực tế chúng được áp dụng cho những phần mềm nào trên server, xin cho một vài ví dụ những phần mềm áp dụng phương thức mã hoá mật khẩu này cho phần mềm A nhưng không áp dụng được phương thức mã hoá mật khẩu cho phần mềm B .
+ MD5 thường dùng cho mã nguồn WEB PHP
Cám ơn anh em đã đọc nội dung này  

Mình chỉ trả lời đc vậy :-D 

Mình đã dùng Paswordspro để giải mã hoá 1 chuỗi MD5 trong forum VBB và đã thành công với 1 PASS số 8 ký tự
Tuy nhiên cái tool này dò PASS số nhanh hơn dò pass chữ nhiều
Dò PASS chữ mình chờ lâu quá nên bỏ cuộc :-D
Dò pass số thì khoang 4-5 ph gì đó là OK :-D 

Xin cho biết , các phương thức mã hoá mật khẩu như SHA, SSHA, MD5, SMD5, CRYPT
- Chúng có tác dụng , chức năng, công dụng, ứng dụng như thế nào ?
- Trên phương diện bảo mật thì phương thức mã hoá mật khẩu nào (ở trên) tốt nhất .
- Hiện tại có cách nào "đọc" được nội dung bên trong, một khi sử dụng các phương thức mã hoá trên ?
- Các phương thức mã hoá mật khẩu ở trên thực tế chúng được áp dụng cho những phần mềm nào trên server, xin cho một vài ví dụ những phần mềm áp dụng phương thức mã hoá mật khẩu này cho phần mềm A nhưng không áp dụng được phương thức mã hoá mật khẩu cho phần mềm B .

Cám ơn anh em đã đọc nội dung này  

Các phương thức mã hoá mật khẩu ở trên thực tế chúng được áp dụng cho những phần mềm nào trên server, xin cho một vài ví dụ những phần mềm áp dụng phương thức mã hoá mật khẩu này cho phần mềm A nhưng không áp dụng được phương thức mã hoá mật khẩu cho phần mềm B .  

Dạ, đúng . Em cài đặt OpenLDAP, Postfix, SAMBA thành công, trong phần OpenLDAP em thấy có các khái niệm mã hóa mật khẩu như SHA, SSHA, MD5, SMD5, CRY hầu như khá .... mơ hồ với em .
 

Các phương thức mã hoá mật khẩu ở trên thực tế chúng được áp dụng cho những phần mềm nào trên server, xin cho một vài ví dụ những phần mềm áp dụng phương thức mã hoá mật khẩu này cho phần mềm A nhưng không áp dụng được phương thức mã hoá mật khẩu cho phần mềm B .  

Trong câu hỏi này em ghi thiếu chi tiết và thông tin khá ít, với 1 server nào đó trong đó được cài đặt OpenLDAP, Postfix, SAMBA sau đó có thể người quản trị cài đặt thêm Squid, Tomcat (hoặc PHP) , mục đích của việc cài đặt Tomcat hay PHP ở đây là người dùng root có thể tạo user dễ dàng thông qua web interface thì theo anh trong OpenLDAP ở thực tế người ta thường dùng phương thức mã hóa nào nhiều nhất ?
 

Trong câu trả lời ở trên của anh có ghi SHA-2 là thuật toán hash vững nhất vì nó chưa "bị" tìm ra collision. vậy thực tế 1 người quản trị OpenLDAP họ có áp dụng thuật toán hash này không ? Anh có thể cho em "xin" vài khái niệm hay ví dụ về thuật toán hash SHA-2 được không anh ?
 

{CRYPT}
The Unix crypt() hash, based on DES. Weaker than the others.
{UNIX}
Synonym for {CRYPT}
{SHA}
SHA-1 based hash.
{SSHA}
Salted SHA-1 based hash.
{MD5}
MD5 based hash.
{SMD5}
Salted MD5 based hash. 

Cám ơn anh giải thích cặn kẻ những điều mà em thắc mắc.  

Tại sao phải hash? Giả sử user A có password là a, password này được application "hash" nó thành 0cc175b9c0f1b6a831c399e269772661 rồi chứa vào CSDL. Khi user A login và dùng password a để đăng nhập, application sẽ hash a và so sánh giá trị vừa hash xong với giá trị đã lưu trong CSDL. Nếu chúng trùng nhau, user A được vào. Nếu hệ thống bị nhân nhượng, kẻ tấn công chỉ thu thập được hashed password và nếu muốn dùng chúng, hắn phải brute force nó (mất thời gian và ít thành công). 

Tại sao phải hash? Giả sử user A có password là a, password này được application "hash" nó thành 0cc175b9c0f1b6a831c399e269772661 rồi chứa vào CSDL. Khi user A login và dùng password a để đăng nhập, application sẽ hash a và so sánh giá trị vừa hash xong với giá trị đã lưu trong CSDL. Nếu chúng trùng nhau, user A được vào. Nếu hệ thống bị nhân nhượng, kẻ tấn công chỉ thu thập được hashed password và nếu muốn dùng chúng, hắn phải brute force nó (mất thời gian và ít thành công). 

Xin "đào mồ" chủ đề này xíu, em đọc thảo luận của các bác cũng sáng ra nhiều vấn đề. Theo em hiểu thì phương pháp hash một dữ liệu (password) thì sẽ giảm khả năng lộ password dạng đọc được trên đường truyền, và người không thẩm quyền cũng chỉ có được một chuỗi kỹ tự loằng ngoằng mà họ không đọc được. Tuy nhiên, cái em thắc mắc là khi đó họ sử dụng trực tiếp luôn cái chuỗi đó chữ không cần dịch lại làm gì cả, vì chuỗi đó là duy nhất mà (tính chất của hàm hash).
Vậy thì hash password, theo em nó chỉ che mắt được chứ không có tác dụng bảo vệ, không biết em nghĩ có sai không. Cảm ơn các bác. 

Ví dụ password đúng là acb. Khi bạn đăng nhập với password acb thì chương trình sẽ hash password của bạn ra thành 1 chuỗi "loằng ngoằng" và nó khớp ( match ) với cái chuỗi "loằng ngoằng" được lưu trong CSDL. Tuy nhiên, bằng 1 cách nào đó bạn lấy được chuỗi loẳng ngoằng này sau đó dùng nó để đăng nhập thì lúc này ứng dụng sẽ hash thành 1 chuỗi "loằng ngoằng mới". Và lúc này thì chuỗi mới không còn khớp (match) với chuỗi nằm trong CSDL nữa.

Kết quả là login bị fail.

Bạn nên đọc kỹ những gì anh conmale viết. 

Mọi người muốn biết hiểu sâu hơn về lịch sử có thể tìm đọc cuốn này .

MẬT MÃ - TỪ CỔ ĐIỂN ĐẾN LƯỢNG TỬ


http://www.vinabook.com/khoa-hoc-kham-pha-mat-ma-tu-co-dien-den-luong-tu-m11i29548.html#


 

thangdiablo wrote:

Ví dụ password đúng là acb. Khi bạn đăng nhập với password acb thì chương trình sẽ hash password của bạn ra thành 1 chuỗi "loằng ngoằng" và nó khớp ( match ) với cái chuỗi "loằng ngoằng" được lưu trong CSDL. Tuy nhiên, bằng 1 cách nào đó bạn lấy được chuỗi loẳng ngoằng này sau đó dùng nó để đăng nhập thì lúc này ứng dụng sẽ hash thành 1 chuỗi "loằng ngoằng mới". Và lúc này thì chuỗi mới không còn khớp (match) với chuỗi nằm trong CSDL nữa.

Kết quả là login bị fail.

Bạn nên đọc kỹ những gì anh conmale viết. 

Cảm ơn bác, tuy nhiên ý em là khi ông không có thẩm quyền đó lấy được cái giá trị hash "loằng ngoằng" đó thì ông ấy chuyển luôn cho máy chủ xác thực (không cho ứng dụng hash tiếp). Vậy thì vẫn hợp lệ chứ ạ.  

Trước tiên nên xác định thế nào là mã hóa (encrypt), giải mã (decrypt) và tạo "băm" một chiều (one-way hashing) để tránh ngộ nhận. Mã hóa có nghĩa là biến a thành b dựa trên một số điều kiện nào đó và có thể chuyển b trở thành a lại (giải mã) dựa trên một số điều kiện nào đó. Trong khi đó, tạo "băm" một chiều có nghĩa là biến x thành y nhưng không thể chuyển y thành x được nữa. Bởi thế mới có cụm "một chiều". 

Hành động brute force các "băm" để dò giá trị nguyên thủy trước khi bị "băm" do thuật toán của nó vẫn có thể bị collision thường bị hiểu lầm là "giải mã". Thật sự brute force không phải là hành động giải mã dựa trên các điều kiện nào đó mà đó là hành động dò. "Brute force" thường mất rất nhiều thời gian (tính theo đơn vị ngày, giờ, tháng hoặc thậm chí năm) vì phải dò. Trong khi đó, "giải mã" chỉ xảy ra trong tích tắc vì đã có sẵn các điều kiện thực thi. 

- Chúng có tác dụng , chức năng, công dụng, ứng dụng như thế nào ?
Trên context LDAP password hashing ở đây: chúng đều tạo hash của pasword. Công dụng của nó (đúng ra là của application dùng nó) để không chứa password ở dạng clear text mà chỉ chứa password ở dạng đã được hash.  

Tại sao phải hash? Giả sử user A có password là a, password này được application "hash" nó thành 0cc175b9c0f1b6a831c399e269772661 rồi chứa vào CSDL. Khi user A login và dùng password a để đăng nhập, application sẽ hash a và so sánh giá trị vừa hash xong với giá trị đã lưu trong CSDL. Nếu chúng trùng nhau, user A được vào. Nếu hệ thống bị nhân nhượng, kẻ tấn công chỉ thu thập được hashed password và nếu muốn dùng chúng, hắn phải brute force nó (mất thời gian và ít thành công).  

Theo em ý bạn ấy là một mật khẩu được hash ra thành "AKNsa2434234234" chẳng hạn mà ai đó bắt được gói tin có chứa cái pass đã hash này thì người ta dùng nó để gửi luôn cái này cho server để xác thực luôn, không cần phải có pasword dạng clear text nữa. Hi theo em hiểu và cũng thắc mắc là thế 

Theo em ý bạn ấy là một mật khẩu được hash ra thành "AKNsa2434234234" chẳng hạn mà ai đó bắt được gói tin có chứa cái pass đã hash này thì người ta dùng nó để gửi luôn cái này cho server để xác thực luôn, không cần phải có pasword dạng clear text nữa. Hi theo em hiểu và cũng thắc mắc là thế 

Không được ở chỗ người dùng vẫn phải đăng nhập mật khẩu và ứng dụng web phải hash cái mât khẩu ấy để so sánh với giá trị có trong CSDL. Ứng dụng web vẫn nhận cái hash đó nhưng nó sẽ "đối xử" cái hash ấy như một password và sẽ hash cái hash rồi so sánh với giá trị có sẵn trong CSDL --> kết quả sẽ sai vì giá trị hash của cái hash không bao giờ là giá trị hash của cái password nguyên thủy. 

conmale wrote:

Không được ở chỗ người dùng vẫn phải đăng nhập mật khẩu và ứng dụng web phải hash cái mât khẩu ấy để so sánh với giá trị có trong CSDL. Ứng dụng web vẫn nhận cái hash đó nhưng nó sẽ "đối xử" cái hash ấy như một password và sẽ hash cái hash rồi so sánh với giá trị có sẵn trong CSDL --> kết quả sẽ sai vì giá trị hash của cái hash không bao giờ là giá trị hash của cái password nguyên thủy. 

Cảm ơn bác, em đã hiểu, như vậy: xét về mặt an toàn trong trường hợp này "ứng dụng web sẽ quyết định tất cả". Và cách để tấn công giả mạo ứng dụng kiểu này em nghĩ là không khó. (Em nghĩ thôi ạ).  

Dựa trên những điểm nào mà bồ "nghĩ" như thế? 

conmale wrote:

Dựa trên những điểm nào mà bồ "nghĩ" như thế? 

Dựa trên một số điểm như là:
1. Các ứng dụng web sẽ rất đa dạng, và không phải cái nào cũng được xây dựng tốt. Nếu tính an toàn của cả hệ thống phụ thuộc vào nó thì sẽ rất khó quản lý vì mỗi ứng dụng có mức độ an toàn khác nhau.
 

2. Nếu xử lý được việc quản lý định danh một cách độc lập (tức là nó không phụ thuộc quá nhiều vào ứng dụng) như vậy sẽ an toàn hơn.
 

3. Thực tế người ta cũng đã làm như vậy: sử dụng one time password, certificate thay cho việc xác thực bằng mỗi password. Nó sẽ đảm bảo an toàn trên cả lý thuyết (các chứng minh toán học,...) và thực tế. Tuy nhiên nó chỉ ứng dụng ở nhưng giao dịch cần bảo mật cao.
 

4. Em không phủ nhận độ an toàn của phương pháp hash password này. Cái em băn khoăn vẫn là bị tấn công bằng cách giả mạo ứng dụng và sử dụng giá trị hash. Có lẽ em hiểu còn cạn nên chưa rõ vấn đề. Mong các bác khai sáng cho bằng một số giải thích cụ thể, chứ đừng phản biện em nhiều quá. (Em đọc cái "đặt câu hỏi thông minh của nhà mình rồi ạ").  

Tính đa dạng của các ứng dụng web không phải là lý do giúp cho "tấn công giả mạo ứng dụng kiểu này em nghĩ là không khó" như bồ đã nhận định. Bồ đi từ chuyện "hash password" ở biên độ khá cụ thể sang chuyện "ứng dụng đa dạng của web application" rồi trải rộng ra "mỗi ứng dụng có mức độ an toàn khác nhau" thì càng xa nữa. Khi nói đến sự "đa dạng của ứng dụng web" bồ phải nói cụ thể là những ứng dụng gì, có tính năng gì, cho mục đích gì và chúng có liên hệ thế nào đến "hash password" thì nó mới đi sát vào chủ đề và đi sát vào câu hỏi tôi đặt ra. 

Câu này quá mơ hồ. Nó liên quan gì đến "password hashing"? "Password hashing" nằm ở đâu trong việc "quản lý định danh"? và nếu nó "phụ thuộc quá nhiều vào ứng dụng" thì nó phụ thuộc cụ thể ở những khía cạnh nào? 

"one time password" có đụng đến "hashing password" không? Nếu có, tại sao loại bỏ hashing password ra và thay thế bằng "one time password"? Nếu không, nó liên quan gì đến chi tiết đang bàn cãi về tính bảo mật của "hashing password" ("có thể tấn công giả mạo ứng dụng" mà bồ đưa ra)? 

PS: tôi không "phản biện" bồ. Bồ dùng từ sai rồi. 

thuật toán của nó vẫn có thể bị collision thường bị hiểu lầm là "giải mã 

collision ở đây là gì anh, khi nào bị? 

@hvthang:
Mình không rành lắm vụ này. Nhưng cũng có ý kiến.
Có lẽ bạn phải toàn quyền được cái server đó rồi mới bắt nó "làm ngơ" để không đem cái pass (đã được băm) bạn đi băm thêm lần nữa .
Chứ hiện tại thì chưa có cách nào đánh lừa server để pass khỏi phải bị băm. (mà theo bạn nói ở trên là dùng ứng dụng liên quan Web Browser) 

OTP về cơ bản thì không cần hashing làm gì cả.
 

Không biết thế nào chứ? Mấy cái mã hóa đó, chúng nó bẻ ngon ơ...