Tôi không chắc chắn cách thức hoạt động của công cụ băm mật khẩu (sẽ triển khai sau), nhưng cần tạo lược đồ cơ sở dữ liệu ngay bây giờ.Loại dữ liệu nào để sử dụng cho trường mật khẩu băm và độ dài nào?
Tôi đang nghĩ đến việc giới hạn mật khẩu là 4-20 ký tự, nhưng khi tôi hiểu sau khi mã hóa chuỗi băm sẽ có độ dài khác nhau.
Vì vậy, cách lưu trữ các mật khẩu này trong cơ sở dữ liệu?
Tùy thuộc vào thuật toán băm bạn sử dụng. Việc băm luôn tạo ra kết quả có cùng độ dài, bất kể đầu vào là bao nhiêu. Nó là điển hình để biểu diễn kết quả băm nhị phân trong văn bản, như một chuỗi các số thập lục phân. Hoặc bạn có thể sử dụng chức năng UNHEX() để giảm một nửa số chữ số hex.
NIST khuyến cáo sử dụng SHA-256 trở lên cho mật khẩu.Các thuật toán băm nhỏ hơn có sử dụng của chúng, nhưng chúng là known to be crackable.
Bạn nên salt mật khẩu của mình trước khi áp dụng hàm băm. Nạp mật khẩu không ảnh hưởng đến độ dài của kết quả băm.
Có thể thực hiện việc chào bán bằng cách đặt trước một giá trị duy nhất (ví dụ: tên người dùng) cho mọi mật khẩu. Đây là một bài viết giải thích tại sao nó là cần thiết: http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html. Tóm lại, nó giúp ngăn chặn các nỗ lực phá mật khẩu sử dụng phương pháp tấn công cầu vồng. – AbdullahC
@ Hippo: Vui lòng không sử dụng tên người dùng làm muối. Tạo ra một muối ngẫu nhiên cho mỗi người dùng. –
Muối được tạo ngẫu nhiên có được lưu trữ trong cùng một hàng của bảng không? – AbdullahC
Là chuỗi có độ dài cố định (VARCHAR (n) hoặc tuy nhiên MySQL gọi nó). Hàm băm luôn có độ dài cố định là 12 ký tự (tùy thuộc vào thuật toán băm bạn sử dụng). Vì vậy, một mật khẩu 20 char sẽ được giảm xuống một hash 12 char, và một mật khẩu 4 char cũng sẽ mang lại một hash 12 char.
'hoặc tuy nhiên MySQL gọi nó' - MYSQL gọi nó là CHAR. Loại này dành cho giá trị độ dài cố định. Vì vậy, tôi nghĩ CHAR là loại tốt hơn VARCHAR. –
Tôi luôn kiểm tra để tìm độ dài chuỗi MAX của chuỗi được mã hóa và đặt độ dài ký tự của loại VARCHAR. Tùy thuộc vào số lượng bản ghi bạn sẽ có, nó thực sự có thể giúp kích thước cơ sở dữ liệu.
Bạn có thể tìm thấy bài viết trên Wikipedia về salting worthwhile. Ý tưởng là thêm một bit dữ liệu để ngẫu nhiên hóa giá trị băm của bạn; điều này sẽ bảo vệ mật khẩu của bạn khỏi các cuộc tấn công từ điển nếu ai đó truy cập trái phép vào các băm mật khẩu.
Bạn thực sự có thể sử dụng CHAR (chiều dài băm) để xác định kiểu dữ liệu của bạn cho MySQL vì mỗi thuật toán băm sẽ luôn đánh giá cùng một số ký tự. Ví dụ, SHA1 luôn trả về một số thập lục phân 40 ký tự.
Nó thực sự phụ thuộc vào thuật toán băm bạn đang sử dụng. Độ dài của mật khẩu ít có liên quan đến độ dài của băm, nếu tôi nhớ chính xác. Tra cứu các thông số kỹ thuật trên thuật toán băm bạn đang sử dụng, chạy một vài thử nghiệm và cắt ngắn ngay trên đó.
Dấu gạch ngang là một chuỗi các bit (128 bit, 160 bit, 256 bit, v.v., tùy thuộc vào thuật toán). Cột của bạn phải được nhập nhị phân, không phải văn bản/ký tự, nếu MySQL cho phép (kiểu dữ liệu SQL Server là binary(n) hoặc varbinary(n)). Bạn cũng nên muối các băm. Các muối có thể là văn bản hoặc nhị phân, và bạn sẽ cần một cột tương ứng.
Công lý là hoàn toàn chính xác ở đây - MySQL sẽ lưu trữ chúng dưới dạng giá trị số và sẽ tìm kiếm trên cột này nhiều hơn hiệu quả hơn so với thực hiện một chuỗi trận đấu, tuy nhiên muối không nên được lưu trữ trong cơ sở dữ liệu bên cạnh các dữ liệu muối - loại bỏ sự an toàn mà muối cung cấp. –
Các muối là * không * bí mật. Bí mật * only * là mật khẩu. Chỉ cần đảm bảo rằng mọi mật khẩu mới đều nhận được một loại muối mới. Mỗi khi người dùng thay đổi mật khẩu của mình, hệ thống sẽ tạo ra một muối mới cho mật khẩu đó. Các muối nên dài và ngẫu nhiên, chẳng hạn như 16 byte được tạo ra từ một PRNG an toàn mã hóa. – yfeldblum
@TonyMaro Không chắc liệu chuỗi mật khẩu có khớp với cấp độ SQL hay không là một chiến lược tốt. Nói cách khác, bạn không nên tìm kiếm cơ sở dữ liệu của mình để tìm mật khẩu, thay vào đó hãy truy xuất người dùng dựa trên tên người dùng của mình và so sánh mật khẩu trong mã, thay vì SQL. – bart
cho md5 vARCHAR (32) là thích hợp. Đối với những người sử dụng AES tốt hơn để sử dụng varbinary.
Bạn nên sử dụng TEXT (lưu trữ số ký tự không giới hạn) để đảm bảo tính tương thích về sau. Các thuật toán băm (cần phải) trở nên mạnh hơn theo thời gian và do đó trường cơ sở dữ liệu này sẽ cần hỗ trợ nhiều ký tự hơn theo thời gian. Ngoài ra tùy thuộc vào chiến lược di chuyển của bạn, bạn có thể cần lưu trữ băm mới và cũ trong cùng một trường, do đó, việc sửa chiều dài thành một loại băm không được khuyến nghị.
Cũng xem Openwall [khuôn khổ băm mật khẩu PHP] (http://www.openwall.com/phpass/) (PHPass). Nó di động và cứng rắn chống lại một số cuộc tấn công phổ biến trên mật khẩu người dùng. Anh chàng đã viết khung công tác (SolarDesigner) là anh chàng đã viết [John The Ripper] (http://www.openwall.com/john/) và làm thẩm phán trong [Cuộc thi Hashing mật khẩu] (http://password-hashing.net/). Vì vậy, anh ta biết một hoặc hai điều về các cuộc tấn công vào mật khẩu. – jww
Vui lòng không đặt giới hạn trên cho mật khẩu của bạn. Bạn đang băm chúng, không có lí do lưu trữ nào cho giới hạn trên. Nếu bạn đang lo lắng về các cuộc tấn công DoS bằng cách sử dụng mật khẩu băm, 1000 hoặc 1024 là một giới hạn trên hợp lý. – Iiridayn
tại sao giới hạn độ dài mật khẩu? Ít nhất cho phép người dùng tạo mật khẩu 100 ký tự :) – Andrew