S/KEY, một trong những hệ thống dựa theo mô hình OPT, được viết bởi Bellcore (hiện tại viết bởi Telcordia) và được phát triển như một phần mềm mã nguồn mở. Bellcore gần đây đã bắt đầu phát triển phiên bản thương mại, nhưng phiên bản miễn phí vẫn được cung cấp. Khi S/KEY trở thành sản phẩm thương mại, phần mã nguồn mở của chương trình này vẫn được quan tâm và phát triển thành sản phẩm OPIE. Cả S/KEY và OPIE sử dụng một hệ thống challenge/response. Trong mỗi trường hợp, mật khẩu của người sử dụng được chứa, trong dạng mẫu được mã hoá, trên hệ thống máy chủ. Mỗi hệ thống sử dụng bộ mã tạo mật khẩu chung dựa theo thông tin người sử dụng cung cấp lúc ban đầu và liên kết với một số tuần tự. Mật khẩu đầu tiên của người sử dụng được tạo bằng cách đặt thông tin của người sử dụng đó qua một thuật toán bảng băm (như thuật toán MD4 cho S/KEY, MD5 cho OPIE) với số N mật khẩu được tạo. N là số lần trong dãy bảng băm để người sử dụng có thể truy cập. Mật khẩu kế tiếp được tạo bằng cách giảm N đi 1 và đặt thông tin đó trong bảng băm số N-1, và tiếp tục như vậy. Với mục đich chứng thực, khi một người sử dụng đăng nhập vào hệ thống, anh ta sẽ gửi tên truy nhập của anh ta tới máy chủ. Máy chủ sẽ trả lời theo phương thức challenge, bao gồm tạo số tuần tự của người sử dụng. Sau khi người sử dụng gõ mật khẩu và gửi tới máy chủ, nếu mật khẩu trùng với mã mà máy chủ đã tạo trước đó một khoảng thời gian, người sử dụng đó được chấp nhận truy cập hệ thống. (Chú ý rằng, mật khẩu này chỉ có giá trị trong một khoảng thời gian nhất định. Và trong khoảng thời gian này, người sử dụng sẽ không thể đang nhập lại nếu hệ thống không được thiết lập lại hay khởi tạo lại). S/KEY và OPIE đã thực sự được thiết kế để bảo vệ các kẻ tấn công như replay attack, vì thông tin mật khẩu chỉ có giá trị cho mỗi phiên làm việc, nó không thể bị lây bởi một công cụ mạo danh hay sử dụng lại tại thời điểm khác. Tuy nhiên, một thông tin mã hoá yếu cũng có thể làm hệ thống như S/KEY hay OPIE có thể có lỗ hổng như một mật khẩu yếu. Vì vậy, ban đầu, chúng ta cần quay lại nơi mà chúng ta xuất phát: đó chính là sử dụng các mật khẩu có độ dài đủ lớn. Phần kết An toàn của mật khẩu trên các hệ thống *.nix bao gồm 3 khía cạnh chính: Đầu tiên, bạn phải tạo các mật khẩu và các bảng băm với độ khó cho các kẻ tấn công khó có thể phá mã được. Bạn có thể thực hiện điều này sử dụng các file mật khẩu, như hạn chế quyền truy cập hơn là thay đổi file chuẩn /etc/passwd file. Thứ hai, bạn phải mã hoá mật khẩu khi truyền tin. Thay thế các giao thức sử dụng việc chứng thực dạng text với các dạng chứng thực được mã hoá. Thứ ba, đảm bảo rằng thuật toán mã hoá, bản thân nó là an toàn. Không có phương thức mã hoá nào là hoàn hảo; Để sử dụng thuật toán mã hoá mạnh nhưng nơi có thể (MD5 hay MD4 hay thủ tục mã hoá crypt). Thậm chí khi bạn sử dụng thuật toán mã hoá, các mật khẩu mạnh vẫn là phương thức tốt nhất bảo vệ việc phá mã hay đoán mật khẩu. Cuối cùng, việc kiểm tra các mật khẩu của bạn (ví dụ: với quyền truy cập) là một trong những cách tốt nhất để nâng cao độ an toàn cho hệ thống của bạn. Các công cụ như Crack rất hữu ích không chỉ cho những kẻ tấn công mà còn cho cả những người quản trị an toàn hệ thống. Công cụ kiểm tra Phiên bản hiện tại Có sẵn tại Môi trường chạy + Crack 5.0a Trung tâm nghiên cứu giáo dục thuộc trường đại học Purdue (CERIAS) *nix; Solaris, Linux, FreeBSD, NetBSD, OSF, and Ultrix. + anlpasswd 2.3 Có rất nhiều Website cung cấp, gồm cả server FTP của CERIAS *nix + npasswd Thuộc trường đại học Texas tại Austin và tại một số website khácBSDI FreeBSD, NetBSD, SunOS, UNIX, and Ultrix + passwd+ 5.0a Trường đại học Dartmouth và một số website khác. Địa chỉ download: ftp://ftp.dartmouth.edu/pub/security/ *nix + S/KEY 1.1 (phẩn mềm miễn phí) Bellcore FTP site FTP của site Bellcore, theo địa chỉ: ftp://thumper.bellcore.com/pub/nmh/ AIX, BSDI, DG-UX, Digital UNIX/Alpha, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OpenBSD, SCO, Solaris, SunOS, and Ultrix + OPIE 2.32 The InnerNet *nix ======= Copy from HcE Gr0up ==== &ksvthdang(HCE) Security permissions in .NET framework Hầu hết các nhà phát triển ứng dụng và phát triển thành phần phần mềm sẽ không cần thiết làm một công việc đặt biệt nào khi làm việc với hệ thống bảo mật của bộ khung .NET ( .NET Framework security system ) mà sẽ được lợi ích nhiều từ sự bảo vệ an toàn mà nó cung cấp. Một ngoại lệ đòi hỏi phải có chiều sâu về kiến thức và sự cân nhắc đặt biệt của hệ thống bảo mật từ những thư viện an toàn bảo mật. Những chương trình này miêu tả ranh giới giữa chương trình quản lý bảo mật ( secure managed ) và chương trình không bị giới hạn ( unrestricted ). Những thư viện tiêu biểu phải có độ tin cậy cao khi sử dụng và chiếm vị trí quan trọng trong việc quản lý chương trình nơi mà một lỗi trong lập trình có khả năng bộc lộ những lỗ hổng, chổ yếu bảo mật. Những chương trình bảo mật truy cập không thể loại trừ tất cả các khả năng gây ra lỗi của con người, nhưng nó sẽ so sánh các phiên bản chương trình ứng dụng với những thư viện an toàn ( secure libraries ). Security An toàn bảo mật trong bộ khung .NET sẽ bảo vệ chương trình và dữ liệu nếu nó được dùng với mục đích sai hoặc bị gây hại nguy hiểm bởi những đoạn chương trình khác bằng cách thi hành những giới hạn an toàn trên những chương trình được quản lý. Khi một ứng dụng của bộ khung .NET có yêu cầu về quyền ( permission ) thì chính sách bảo mật sẽ được thiết lập bới những sự cấp phép của người quản trị và sẽ cho phép hoặc không cho phép thi hành chương trình đó. Độ tin cậy sẽ dựa trên bằng chứng của chương trình như một chữ ký điện tử, một dấu hiện số, khi chương trình đã được chấp nhận thì hiệu lực quyền bảo mật sẽ điều khiển cho phép thi hành chương trình. Permission An toàn trong bộ khung .NET cho phép chương trình được sử dụng những tài nguyên bảo vệ nếu và chỉ nếu nó được cấp quyền để làm điều đó " permissions ". Bộ khung .NET sử dụng khái niệm "permission" để miêu tả quyền mà chương trình có khả năng truy cập tài nguyên bảo vệ. Khi chương trình có yêu cầu những permission mà nó cần thiết và những chính sách bảo mật của thư viện bảo mật thì bộ khung .NET sẽ xác định permission mà chương trình thật sự được cho phép. Bộ khung .NET cung cấp cho chương trình được phép truy cập các lớp permission, mỗi gói ( encapsulate ) sẽ có khả năng truy cập một vùng tài nguyên. Sử dụng những permission để ra dấu hiệu cho .NET Framework biết chương trình sẽ cần cấp những quyền gì hay chương trình được cho phép làm những công việc gì, và để thực hiện việc ra dấu hiệu thì những lời gọi của chương trình sẽ phải được ủy quyền để làm điều đó. Những cách giải quyết vấn đề cũng sử dụng những đối tượng để xác định những permision nào cần thiết cấp phép cho một chương trình Demanding Security Permissions in .NET Framework Có hai cách thức để thực hiện lời gọi yêu cầu quyền bảo mật an toàn trong .NET Framework Imperatively: Sử dụng những lời gọi từ những lớp permission có trong .NET Framework Declaratively: Sử dụng những thuộc tính an toàn của permission Sau đây sẽ dẫn ra hai ví dụ thực hiện lời gọi từ chối những chương trình không được quản lý bởi bộ khung .NET được viết bằng C#: Ví dụ 1: // Imperatively: Sử dụng những lời gọi từ những lớp permission có trong .NET Framework // ImperativeSecurity.cs using System; using System.Security; using System.Security.Permissions; using System.Runtime.InteropServices; class NativeMethods { /* Đây là một lời gọi đến unmanaged code. Thi hành phương thức này phụ thuộc vào UnmanagedCode security permission. Khi không có permission thì chương trình sẽ cố gắng gọi phương thức này và đưa ra một SecurityException:*/ [DllImport("msvcrt.dll")] public static extern int puts(string str); [DllImport("msvcrt.dll")] internal static extern int _flushall(); } class MainClass { private static void CallUnmanagedCodeWithoutPermission() { // Tạo một đối tượng permission an toàn để miêu tả UnmanagedCode permission: SecurityPermission perm = new SecurityPermission(SecurityPermissionFlag.Unmanage dCode); /* Từ chối UnmanagedCode từ những permission đang thiết lập. Bất kỳ một phương thức nào được gọi trên tiến trình này cho đến khi phương thức kết thúc thì sẽ bị từ chối truy cập đến unmanaged code. Dù cho phương thức CallUnmanagedCodeWithPermission được gọi từ một stack frame đã chuẩn bị gọi quyền ( Assert ) cho unmanaged code, và vẫn không thể gọi chương trình này ( code ). Bởi vì ở đây dùng Deny, permission bị ghi chồng.*/ perm.Deny(); try { Console.WriteLine("Attempting to call unmanaged code without permission."); NativeMethods.puts("Hello World!"); NativeMethods._flushall(); Console.WriteLine("Called unmanaged code without permission. Whoops!"); } catch (SecurityException) { Console.WriteLine("Caught Security Exception attempting to call unmanaged code."); } } private static void CallUnmanagedCodeWithPermission() { // Tạo một security permission object để miêu tả UnmanagedCode permission: SecurityPermission perm = new SecurityPermission(SecurityPermissionFlag.Unmanage dCode); /* Kiểm tra permission để truy cập unmanaged code. Nếu không có permission để truy cập unmanaged code, thì lời gọi này sẽ đưa ra một SecurityException. Dù là khi phương thức CallUnmanagedCodeWithPermission được gọi từ một stack frame đã chuẩn bị gọi quyền ( Assert ) cho unmanaged code, và vẫn không thể gọi chương trình này ( code ). Bởi vì ở đây dùng Deny, permission bị viết chồng.*/ perm.Assert(); try {