Các lập trình viên web nên biết gì về mật mã? [đóng cửa]

Các lập trình viên xây dựng trang web / ứng dụng web có nên hiểu mật mã không? Tôi không biết làm thế nào hầu hết các thuật toán crypographic hoạt động và tôi thực sự không hiểu sự khác biệt giữa md5 / des / aes / vv. Có ai trong số các bạn tìm thấy bất kỳ nhu cầu hiểu biết sâu sắc về mật mã không?

Tôi không cần nó, nhưng tôi tự hỏi liệu có lẽ tôi đang thiếu thứ gì đó. Tôi đã sử dụng hàm băm muối + md5 để mã hóa mật khẩu và tôi nói với máy chủ web sử dụng SSL. Ngoài ra, tôi không thể nói rằng tôi đã sử dụng nhiều thứ khác, tôi cũng không thể nói chắc chắn rằng các phương pháp này an toàn đến mức nào . Tôi chỉ sử dụng chúng vì những người khác cho rằng chúng an toàn.

Bạn đã bao giờ tìm thấy một nhu cầu sử dụng mật mã trong lập trình web ngoài hai ví dụ đơn giản này chưa?

Các lập trình viên web nên biết rằng họ không bao giờ nên cố gắng tự thực hiện mật mã.

Cụ thể, điều đó có nghĩa là không có chuyên gia phi bảo mật nào được chạm trực tiếp vào bất kỳ nguyên tắc mã hóa nào. Họ không nên suy nghĩ ở cấp độ AES, SHA-1, v.v. Thay vào đó, họ nên sử dụng các chức năng cấp cao để mã hóa và ký tin nhắn và để "băm" mật khẩu.

Tại sao? Bởi vì nếu không, mọi người sẽ lầm tưởng rằng:

• AES-256 là "mã hóa tuyệt vời", mặc dù thực tế là họ đang sử dụng nó trong chế độ ECB hoặc sử dụng các giá trị IV không ngẫu nhiên, v.v. (Trong một số chế độ, IV không ngẫu nhiên nhưng duy nhất là ổn. rất nhiều.)
• Họ có thể sử dụng cùng một khóa đối xứng để mã hóa nhiều tin nhắn (hoặc tệ hơn là lưu trữ khóa đối xứng trong mã để sử dụng trực tiếp).
  • Họ thậm chí có thể quyết định sử dụng cụm mật khẩu trực tiếp làm khóa mà không sử dụng bất kỳ chức năng phái sinh chính nào.
• Họ có thể sử dụng RSA để mã hóa dữ liệu trực tiếp.
• Họ có thể chỉ cần "muối và MD5" mật khẩu của mình để giữ an toàn. (Nếu bạn nghĩ bảng cầu vồng là liên kết yếu nhất, hãy nghĩ lại .)

Chỉ cần ở trên cùng một trang, không có mục nào ở trên là ổn cả . Nếu bạn không có được điều đó, thì bạn không nên chạm vào tiền điện tử bằng sào 10 feet! (AES-256 là mã hóa tuyệt vời, nhưng chỉ khi bạn sử dụng đúng cách. "Đây không phải là kích thước quan trọng, đó là những gì bạn làm với nó." :-))

Tôi đang nói về loại chức năng cấp cao nào? Cá nhân tôi khuyên bạn nên sử dụng thư viện OpenPGP (cho dữ liệu khi nghỉ ngơi) hoặc SSL (cho dữ liệu đang chuyển động). Các giao thức này cứng nhắc xác định việc sử dụng đúng các thuật toán băm không đối xứng, đối xứng và băm. Ví dụ: với OpenPGP:

• Nó không sử dụng RSA để mã hóa dữ liệu trực tiếp mà thay vào đó tạo ra khóa phiên ngẫu nhiên (đối xứng) cho mỗi tin nhắn (điều này rất quan trọng) và sử dụng RSA để mã hóa khóa phiên đó.
  • Thậm chí sau đó, nó sẽ đệm khóa phiên bằng cách sử dụng mã hóa PKCS # 1 v1.5 ( EME-PKCS1-v1_5). Đệm là cực kỳ quan trọng đối với RSA. ( Một số người cho rằng sử dụng phần đệm v1.5 là ổn. Những người khác nghĩ rằng OAEP tốt hơn. )
• Nó sử dụng chức năng phái sinh chính để chuyển đổi cụm mật khẩu thành khóa. (Theo cách nói của OpenPGP, nó được gọi là S2K, nhưng tôi nghĩ "hàm dẫn xuất chính" là thuật ngữ chuẩn hơn.)
• Nó xử lý chọn một chế độ tốt, vì vậy bạn sẽ không bao giờ kết thúc việc sử dụng ECB.
• Nó xử lý việc quản lý khóa cho bạn, vì vậy bạn không phải đưa ra quyết định đột xuất về việc khóa nào đáng tin cậy, v.v.

Tóm tắt: nếu bạn không phải là chuyên gia bảo mật và bạn đang suy nghĩ ở cấp độ AES hoặc SHA-1 hoặc (trời cấm) MD5, bạn đã làm sai . Sử dụng thư viện được viết bởi các chuyên gia bảo mật (như Bouncy Castle), thực hiện các giao thức được thiết kế bởi các chuyên gia bảo mật (như OpenPGP để mã hóa, hoặc bcrypt hoặc mã hóa để băm mật khẩu), thay vì tự cuộn.

Tôi không phải là một chuyên gia về tiền điện tử, nhưng tôi biết đủ để không cố gắng thiết kế các giao thức đặc biệt của riêng mình. Nói rõ hơn, toàn bộ bài đăng này là tài liệu Mật mã 101 . Vì vậy, nếu bài đăng này không có ý nghĩa 100% với bạn, thì bạn chắc chắn không nên đến bất cứ nơi nào gần mật mã.

Bạn không cần phải biết bất cứ điều gì ngoại trừ những điều cơ bản về mật mã (băm là gì, muối là gì, gần như khó để bẻ khóa mã hóa này hay v.v.), nhưng bạn phải biết một chút công bằng về bảo mật chung.

Các lĩnh vực bảo mật chính mà bạn chắc chắn phải biết là nhà phát triển web:

1. SQL tiêm. Đây có lẽ là lỗ hổng nguy hiểm nhất mà nhà phát triển web có thể đục lỗ trên hệ thống.
2. Kịch bản chéo trang và cookie.
3. Spamb và captcha.
4. SQL tiêm. Không thể nhấn mạnh đủ tầm quan trọng của việc này.

Tôi nhớ đã xem bài nói chuyện này có tên Những gì mọi kỹ sư cần biết về bảo mật và nơi để tìm hiểu nó , người nói là Neil Daswani và đó là một Google Tech Talk mà anh ấy đã đưa ra, có thể là một nơi tốt để bắt đầu!

Không chỉ áp dụng cho các lập trình viên Web, có lẽ câu hỏi nên được đặt lại tên "Các lập trình viên nên biết gì về bảo mật?" vì họ không cần biết nhiều hơn những điều cơ bản về Mật mã học (cũng thú vị như vậy)

Tiền điện tử có ích trong nhiều tình huống. Một ví dụ chúng tôi đã sử dụng là mã hóa cookie phiên được tạo và thiết lập bởi máy chủ Win / IIS sẽ được sử dụng trên máy chủ LAMP.

Nếu bạn thực hiện mã hóa (trái ngược với băm md5 / sha1), một số thuật ngữ cơ bản rất quan trọng - chẳng hạn như sự khác biệt giữa mã hóa đối xứng và bất đối xứng. Cùng với việc hiểu sự khác biệt giữa hai loại này, bạn nên phát triển sự hiểu biết về những gì bạn là nhà phát triển web cần làm để lưu trữ và bảo mật các khóa giải mã đúng cách. Ví dụ: nếu phát triển một ứng dụng sẽ được triển khai trên một máy chủ mà bạn không có toàn quyền kiểm soát, như máy chủ chung, so với việc triển khai trên máy chủ nơi tất cả quản trị viên đều biết và tin cậy.

Theo tôi, bạn nên biết mọi thứ về mật mã mà ai đó tấn công mã của bạn sẽ biết. Bạn nên hiểu băm, muối, tính không ngẫu nhiên của các thuật toán mã hóa chính (RSA, 3DES, AES, v.v.), SHA-1 / MD-5 / et al. Bạn không cần phải ghi nhớ chúng, nhưng ít nhất bạn nên biết rằng tính hiệu quả của thuật toán băm và cách làm cho nó mạnh hơn. Bạn nên biết những va chạm và dương tính giả là gì. Bạn không nên đọc các thuật toán mã hóa, nhưng bạn nên làm quen với các điểm chuẩn của chúng, những thuật toán nào lý tưởng cho các kịch bản. Bạn sẽ có thể mô tả và giải thích mã hóa đối xứng và bất đối xứng và khi nào nên sử dụng từng loại. Bạn nên biết PKI là gì và nó được sử dụng như thế nào. Bạn nên biết cơ quan cấp chứng chỉ là gì và cách thức nó tương tác với máy chủ của bạn.

Biết được mọi thứ bên trong và mọi thứ không quan trọng bằng việc biết nền tảng của nó. Điểm chuẩn của những thứ nhất định là gì (nhanh, mạnh, yếu, v.v.).

Những khuyến nghị này là dành cho thông tin cấp cao hoặc kiến ​​trúc sư. Nếu bạn chỉ là một con khỉ web chèo một mái chèo, bạn không cần phải biết bất kỳ điều gì trong số này. Kiến trúc sư của bạn nên biết những thứ này. Nếu bạn phụ trách trang web, thiết kế nó, triển khai nó, v.v ... thì bạn nên làm quen với tất cả các khái niệm này và có thể trò chuyện một cách thông minh về chúng. Bạn không cần phải dạy nó, chỉ cần chấp nhận và phổ biến thông tin về nó.

Bạn nên sử dụng bcrypt (Blowfish) để lưu trữ mật khẩu thay vì MD5; đó là một thuật toán chậm hơn nhiều , điều đó có nghĩa là hacker khó đoán và kiểm tra hơn rất nhiều. Ngoài ra, bcrypt lấy yếu tố công việc làm tham số, nghĩa là nó có thể chậm hơn khi các máy tính mới hơn được giới thiệu, do đó, nó có tích hợp chứng minh trong tương lai.

Xem cách lưu trữ mật khẩu an toàn để biết thêm thông tin.

Là một câu trả lời khá chung cho các loại câu hỏi này, tôi luôn nghĩ rằng bạn nên cố gắng có một sự hiểu biết cơ bản về bất cứ điều gì có liên quan từ xa đến những gì bạn làm. Tất nhiên bạn cần có kiến ​​thức chi tiết cụ thể về những gì bạn đang thực sự làm việc. Rất khó để dự đoán một khu vực nhất định sẽ phát triển như thế nào, điều gì sẽ là "thời trang" hoặc những gì bạn sẽ cần trong tương lai, do đó, có một khu vực rộng lớn mà bạn ít nhất "nghe nói" sẽ giữ nhiều cánh cửa mở ra.

Theo như kinh nghiệm cá nhân của tôi về lập trình web, tôi đã tìm thấy những khái niệm cơ bản về mật mã học không đối xứng và những thứ hữu ích để hiểu những gì đang diễn ra dưới mui xe. Tôi có thể sống sót mà không có nó nhưng tôi phải nói rằng tôi thích mật mã và toán học vậy tại sao không.