kiến thức Phân biệt Encrypt và Hashing

bkhoang · 3/6/24

anoldvozer1710.v2 đã nói:
n là 2^256 đấy fence ah, chứ không phải 256 đâu

via theNEXTvoz for iPhone

thì đang nói n là số bit :amazed:

anoldvozer1710.v2 · 3/6/24

bkhoang đã nói:
thì đang nói n là số bit

Thôi ghi là N cho phân biệt vậy :go:

N là không gian đầu ra của hàm băm(output space).
n = 256, N = 2 ^ 256 :angry:

snapdragon0221 · 3/6/24

zzchaolegionzz đã nói:
Sao lại luôn là giá trị cố định bất chấp đầu vào? Chắc thím đang nói nó luôn cho ra output có chiều dài cố định bất chấp độ dài input.

Đúng r thím, output luôn luôn có chiều dài cố định bất chấp chiều dài input.

zzchaolegionzz · 4/6/24

Nhân tiện giới thiệu cho các thím lib hash nhanh nhất thế giới GitHub - Cyan4973/xxHash: Extremely fast non-cryptographic hash algorithm (https://github.com/Cyan4973/xxHash)
Có nhiều bản port qua Go, Rust...
Có thể hash mọi thứ thành một số 32, 64, 128 bit

bkhoang · 4/6/24

anoldvozer1710.v2 đã nói:
Thôi ghi là N cho phân biệt vậy N là không gian đầu ra của hàm băm(output space).
n = 256, N = 2 ^ 256

đừng có mà bắt lú nhá :ah:

lapnickdevaof33 · 4/6/24

Riêng về hàm băm, mình thấy có 1 video bên CyberJutsu làm cũng khá dễ hiểu. Các thím skip đến phần giải thích hàm băm nha:

swetder · 4/6/24

beatvn.truongton đã nói:
bạn lầm rồi, mình chưa thấy công nghệ nào lại đi encrypt password cả
pass "123456" khi bạn encrypt thì sẽ ra "djse989" chẳng hạn, và về mặt khái niệm kỹ thuật thì từ "djse989" sẽ decrypt ra lại thành "123456"
Còn hash thì không có khái niệm giải ngược như vậy đâu nhé, muốn phá thì bạn phải đi "vét cạn", và về mặt lý thuyết thì đây là 1 phương trình có vô số nghiệm, nhưng để tìm ra 1 nghiệm thì là là vô cùng khó

Cốt lõi của nó chính là Hash đó bạn
- Bcrypt tự động thêm một giá trị salt vào mật khẩu trước khi băm để bảo vệ chống lại các cuộc tấn công bằng rainbow table.

Dùng encrypt hay hash lên "password" thì còn phụ thuộc vào yêu cầu và cách mà trường "password" đó được sử dụng nữa chứ bác. Em nghĩ là không có công nghệ nào là hoàn hảo cả. Chỉ là cái nào hợp cho trường hợp nào hơn thôi.
Nếu cần lấy lại giá trị gốc để sử dụng thì phải sử dụng encrypt chứ dùng hash thì sẽ không đáp ứng được việc dịch ngược. Tất nhiên là trường hợp như vậy là không nhiều.

Mà một khi quyền truy cập vào dữ liệu đã bị chiếm thì dữ liệu được hash hay encrypt cũng đều là miếng mồi thôi. Hash cũng chỉ là mất thời gian hơn để kẻ tấn công ăn được miềng mồi này thôi.

anoldvozer1710.v2 · 4/6/24

swetder đã nói:
Dùng encrypt hay hash lên "password" thì còn phụ thuộc vào yêu cầu và cách mà trường "password" đó được sử dụng nữa chứ bác. Em nghĩ là không có công nghệ nào là hoàn hảo cả. Chỉ là cái nào hợp cho trường hợp nào hơn thôi.
Nếu cần lấy lại giá trị gốc để sử dụng thì phải sử dụng encrypt chứ dùng hash thì sẽ không đáp ứng được việc dịch ngược. Tất nhiên là trường hợp như vậy là không nhiều.

Mà một khi quyền truy cập vào dữ liệu đã bị chiếm thì dữ liệu được hash hay encrypt cũng đều là miếng mồi thôi. Hash cũng chỉ là mất thời gian hơn để kẻ tấn công ăn được miềng mồi này thôi.

fence cho mình hỏi có use-case nào cần dùng đến giá trị gốc của password nhỉ. Mình nghĩ phần lớn các hệ thống bây giờ thì đến người quản trị DB cũng ko biết đc giá trị gốc của password luôn chứ nhỉ :big_smile:

swetder · 4/6/24

anoldvozer1710.v2 đã nói:
fence cho mình hỏi có use-case nào cần dùng đến giá trị gốc của password nhỉ. Mình nghĩ phần lớn các hệ thống bây giờ thì đến người quản trị DB cũng ko biết đc giá trị gốc của password luôn chứ nhỉ

case ví dụ:
Dữ liệu lưu trong DB gồm: thông tin truy cập của device như ip, port, user, password,...
1. Khi cần lấy thông tin setting hoặc thay đổi setting thời gian thực của device thì cần submit 1 request. Thời điểm này thì password của device bắt buộc phải quay về trạng thái origin để có thể sử dụng xác thực khi gửi request.
2. Cần connect tới device để sử dụng một số chức năng cũng cần sử dụng mật khẩu gốc để thực hiện xác thực.

Thím có thể gặp trong hệ thống làm việc với IP camera hoặc một số thiết bị đặc thù mà cần sử dụng password gốc để xác thực.

Tất nhiên người quản trị DB không biết được giá trị gốc của password, không ai lại để cái field nhạy cảm như thông tin xác thực lộ liễu quá ra rồi. Thằng xem được dữ liệu thì không biết cách che đậy dữ liệu, thằng tham gia làm che đậy dữ liệu thì không được nhìn thấy dữ liệu thật

Machiko · 5/6/24

trước em gặp bác hỏi về mã băm này =))

bảo vào giải thích giải mã cái mã đấy ra tưởng để làm gì ai ngờ bảo nhờ giải thích để học về tài xỉu. cười vl

aphone · 13/6/24

Duy1122 đã nói:
Hashing là quá trình chuyển đổi dữ liệu từ dạng gốc thành một giá trị băm cố định. Hashing là quá trình một chiều, nghĩa là không chuyển về dữ liệu gốc từ giá trị băm (Khác với Encrypt có thể đổi ngược).
Với một dữ liệu gốc sẽ tạo ra một giá trị băm nhất định, chính vì vậy khi dùng hash mật khẩu lưu vào database thì hacker có thể dùng rainbow table để dò giá trị băm và tìm được dữ liệu gốc. Vì vậy khi thực hiện hash mật khẩu ta cần thêm Salt ngoài ra còn có Pepper, KDF (Key Derivation Function):.

Salt

Salt là một giá trị ngẫu nhiên, được thêm vào mật khẩu trước khi thực hiện băm.

Salt đảm bảo rằng mỗi mật khẩu, ngay cả giống nhau cũng sẽ cho ra giá trị băm khác nhau.

Điều này làm cho rainbow table gần như vô dụng vì hacker phải tạo rainbow table riêng cho mỗi giá trị salt với kích thước vô cùng lớn

Mã:

async function hashPassword(password) { const salt = await bcrypt.genSalt(saltRounds); const hashedPassword = await bcrypt.hash(password, salt); return hashedPassword; }

Pepper

Pepper là một giá trị bí mật, giống như salt, được giữ bí mật và thêm vào mật khẩu trước khi băm.

Pepper thường lưu vào các biến môi trường trên máy chủ.

Mã:

async function hashPassword(password) { const salt = await bcrypt.genSalt(saltRounds); const hashedPassword = await bcrypt.hash(password + pepper, salt); return { salt, hashedPassword }; }

Kỳ thực ko hiểu lắm, dưới góc nhìn 1 người bình thường thì băm password ra để hecker khi thấy dữ liệu cuối ko dò ra được raw password đúng không ?
Nhưng nếu user đăng nhập với mật mã A => hệ thống cũng thực hiện băm password A ra A1', A2' thì nó biết password của user khớp không kiểu gì ?

LmaoSuVuong · 13/6/24

aphone đã nói:
Kỳ thực ko hiểu lắm, dưới góc nhìn 1 người bình thường thì băm password ra để hecker khi thấy dữ liệu cuối ko dò ra được raw password đúng không ?
Nhưng nếu user đăng nhập với mật mã A => hệ thống cũng thực hiện băm password A ra A1', A2' thì nó biết password của user khớp không kiểu gì ?

lội 2 page của thớt theo mình hiểu thì trong password đã hash có chứa salt ở trong đó, lấy salt ngược ra hash lại password là compare dc.
còn A1' với A2' của fen là 2 user có cùng password nhưng trong db hiển thị khác nhau do khác salt.

aphone · 13/6/24

Ọc, vậy nói tựu chung ra là nó 1 cái unique key, bằng cách nào đó cho ra 1 chuỗi giống nhau 2 kết quả khác nhau.
Chỉ phòng được vụ hacker trộm được DB và ko decode được.
Còn hacker nó mà đã leo quyền trộm được salt, DB thì coi như banh luôn ?

rongthhieng2007 · 13/6/24

aphone đã nói:
Ọc, vậy nói tựu chung ra là nó 1 cái unique key, bằng cách nào đó cho ra 1 chuỗi giống nhau 2 kết quả khác nhau.
Chỉ phòng được vụ hacker trộm được DB và ko decode được.
Còn hacker nó mà đã leo quyền trộm được salt, DB thì coi như banh luôn ?

bảo mật nó là 1 cái mảng riêng, đây chỉ nói về mã hoá vs hash, đọc nghe ngứa thật, tránh hacker thì rút mẹ dây điện như Quảng nổ là ok nhất ...
bàn về mã hoá vs hash mà cứ lỗi hacker vào, tụi mày bị cái gì thế

aphone · 13/6/24

rongthhieng2007 đã nói:
bảo mật nó là 1 cái mảng riêng, đây chỉ nói về mã hoá vs hash, đọc nghe ngứa thật, tránh hacker thì rút mẹ dây điện như Quảng nổ là ok nhất ...
bàn về mã hoá vs hash mà cứ lỗi hacker vào, tụi mày bị cái gì thế

Này thím, đang nói về user view và tôi thắc mắc thật vì tôi ko chuyên ngành này, lội thớt trên 2 cái là thấy tôi nói trước !

Với cả nó cũng chẳng phải gì đặc biệt mà thể hiện ta đây ra vẻ với gì mà ngứa !

rongthhieng2007 · 13/6/24

aphone đã nói:
Này thím, đang nói về user view và tôi thắc mắc thật vì tôi ko chuyên ngành này, lội thớt trên 2 cái là thấy tôi nói trước !

Với cả nó cũng chẳng phải gì đặc biệt mà thể hiện ta đây ra vẻ với gì mà ngứa !

Ko chuyên ngành thì im, cứ bày đặt hacker này nọ, vào đọc xem kiến thức, gặp mấy thằng như mày chỉ biết hỏi vs hỏi mấy cái vớ vẩn, tụi m bị ngu à, hỏi mấy câu vớ vẩn loãng hết mẹ topic, hack hack cái lol, ngứa thật chứ

kangtk · 14/6/24

aphone đã nói:
Ọc, vậy nói tựu chung ra là nó 1 cái unique key, bằng cách nào đó cho ra 1 chuỗi giống nhau 2 kết quả khác nhau.
Chỉ phòng được vụ hacker trộm được DB và ko decode được.
Còn hacker nó mà đã leo quyền trộm được salt, DB thì coi như banh luôn ?

Salt sinh ra ngẫu nhiên khi hash bạn à.

aphone · 14/6/24

Cảm ơn bác giải ngố hộ

rongthhieng2007 đã nói:
Ko chuyên ngành thì im, cứ bày đặt hacker này nọ, vào đọc xem kiến thức, gặp mấy thằng như mày chỉ biết hỏi vs hỏi mấy cái vớ vẩn, tụi m bị ngu à, hỏi mấy câu vớ vẩn loãng hết mẹ topic, hack hack cái lol, ngứa thật chứ

Chào, bạn ngứa thì tự gãi, tôi cũng CNTT và lập trình, vào đây để trao thêm đổi kiến thức mảng chuyên ngành bảo mật, nói chuyện tục thì ignore hộ.

kangtk đã nói:
Salt sinh ra ngẫu nhiên khi hash bạn à.

Cảm ơn thím giải ngố giúp, thực sự thì khi làm với DB em cũng cứ gọi hàm MD5 thôi, chứ ko biết cụ thể nó gen sới MD5+ salt rồi lưu DB.
Lúc đầu em lại tưởng phải viết thêm 1 function mã hóa lại

thanhx0kjt · 16/6/24

LmaoSuVuong đã nói:
lội 2 page của thớt theo mình hiểu thì trong password đã hash có chứa salt ở trong đó, lấy salt ngược ra hash lại password là compare dc.
còn A1' với A2' của fen là 2 user có cùng password nhưng trong db hiển thị khác nhau do khác salt.

mình nghĩ đoạn đó bạn ý giải thích chưa rõ ràng
Dùng để verify password thì SALT lúc lưu hash vào DB và SALT lúc compare password phải giống nhau. Ý bác thớt nói có thể là mỗi user sẽ có 1 giá trị khác nhau (random), thường là userId chẳng hạn.
Đoạn bôi đen trong comment của bác cũng không đúng. Khi so sánh password thì hệ thống compute lại HASH từ password người dùng nhập vào, dùng đúng quy trình/function lúc lưu hash password rồi so sánh với giá trị trong DB. Không thể dịch ngược từ hash -> password.
Một số thuật toán hashing cao cấp hơn:

Lấy SALT
Tạo vòng lặp HASH n lần
....

Các tham số này tùy chọn độc lập trên hệ thống (hardcode hoặc trong file cấu hình), tách biệt khỏi phần DB. Do vậy quản trị DB có mò vào được user table cũng không thể dùng các thủ thuật vét cạn để dò password thật của người dùng. Điều này hạn chế việc internal attack.
Còn khi hacker đã hack được hệ thống thì họ có nhiều cách để phá chứ quan tâm gì password người dùng.

GodzillaTheMonster · 23/6/24

Hôm trước đọc thì thấy dự đoán tương lai máy tính lượng tử đủ khả năng giải được AES-256 trong thời gian <1 năm, và Intel đang có cuộc thi tìm thuật toán khó hơn để cho encryption chống lại máy tính lượng tử. Do cách tính của máy tính lượng tử, nếu dùng biến đổi Fourier lượng tử thì có thể giải mã được AES-256, vấn đề chỉ là thời gian.
Đọc mấy cái này cũng khá hay, không biết có thím nào chuyên ngành về kỹ thuật mã hoá không?

kiến thức Phân biệt Encrypt và Hashing

Senior Member

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Junior Member

Senior Member

Junior Member

Member

Junior Member

Member

Senior Member

Junior Member

Đã tốn tiền

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này