Kiểm tra xác thực trên Web site

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

Kiểm tra xác thực trên Web site

[Question] Kiểm tra xác thực trên Web site	26/01/2007 02:11:03 (+0700) \| #1 \| 38134

kryptos
Member

Joined: 12/09/2006 10:42:48
Messages: 24
Offline

Kiểm tra xác thực trên Web Site - Phần 1
Một trường hợp cần được quan tâm là: Bạn xây dựng một trang Web cho phép nhiều dạng (hệ thống user được phân cấp) người dùng log-in. Bạn cho phép người dùng tạo username và password, khi họ đăng nhập vào trang web phải cung cấp đúng thông tin về Username và Password. Nhưng bạn có đảm bảo rằng việc xác thực đó của bạn luôn được bảo mật? Mọi thời gian tôi có thể đăng ký tại trang web này, tôi lấy làm ngạc nhiên - đôi khi các trường hợp bảo mật còn xảy ra đối với những trang web rất lớn trên thế giới. Web là đã trở thành một phần của cuộc sống, và nguy cơ bị ăn cắp các thông tin cá nhân ngày càng lớn.
Thiếu việc bảo mật các user là một vấn đề lớn của các nhà phát triển Web. Có thể nó là một sự thiếu sót, nhưng có thể sự thiếu sót ấy có thể được kiểm tra. Trong bài viết này tôi giới thiệu với các bạn một tiêu chuẩn để kiểm tra các quá trình bảo mật của bạn. Từ đó bạn có thể đưa ra những chính sách hợp lý cho trang web của bạn.
Hai vấn đề cần được quan tâm là:
- Username và Passwords
- Password Management
1. Các vấn đề liên quan tới Usernames and Passwords
Hệ thống có cần thiết cả Username và Password?
Đó là một cách thông minh để bảo mật, nhưng đôi khi tôi vào một số trang web chỉ cần một password mà không cần đến username. Vấn đề này xảy ra khi khi một username sử dụng một password nhưng một user khác cũng sử dụng username khác như password lại trùng. Bạn sẽ có một thông báo là tài khoản cần thiết phải nhập lại mật khẩu, bởi hệ thống vẫn tưởng user của bạn đã được log-in vào hệ thống rồi, khi đó bạn chỉ cần gõ mật khẩu và lúc đó hệ thống sẽ cho bạn đăng nhập. Do đó việc kết hợp cả username và mật khẩu là một ý tưởng rất thông minh.
Tại sao hệ thống lại cho phép, khuyến cáo, hoặc bắt buộc bạn phải sử dụng một password khó?
Nếu hệ thống bảo mật của bạn phụ thuộc vào passwords, khi đó bạn chỉ có thể tăng tính bảo mật nếu bạn có chính sách yêu cầu cần phải có mật khẩu khó. Có thể áp dụng chính sách như: tối thiểu chiều dài của password cho phép và không cho password tương tự như username. Bằng cách sử dụng ký tự là số hay các ký tự đặc biệt sẽ tạo ra một password khó, nhưng bạn có thể cũng khuyến cáo người dùng sử dụng một password dài. Bạn cũng có thể tạo ra những password bằng những câu thành ngữ dài và thêm các kí tự đặc biệt ở đầu và cuối. Hơn nữa hiện nay tất cả các chính sách mật khẩu đều cho phép bạn sử dụng tất cả các ký tự trên bàn phím, không giới hạn các ký tự cũng như các số được sử dụng. Nhưng bạn muốn hệ thống hoạt động nhanh hơn việc xác thực nhanh hơn khi có hàng nghìn người đăng nhập cùng một lúc bạn cần có chính sách hạn chế chiều dài của mật khẩu: tiêu chuẩn là 128 ký tự.
Như AOL - bao gồm AIM, và Netcape Network and Compuserve - cho phép bạn sử dụng mật khẩu ngắn nhất là 3 ký tự nhưng dài nhất là 16 ký tự.
Làm cách nào để hệ thống không cho việc sử dụng lại các mật khẩu đã được đổi?
Hotmail được ra đời vào 4 - 6 năm 1996 - đã hơn 10 năm. Bây giờ bạn thử hỏi, còn bao nhiêu người trong số hàng triệu người sử dụng Hotmail trong 10 năm qua vẫn luôn giữ một mật khẩu từ đó đến nay? Nếu bạn không muốn áp dụng việc tái sử dụng lại mật khẩu cũ cho người dùng, bạn phải có cơ chế lưu lại mật khẩu cũ của họ để từ đó áp dụng chính sách không cho người dùng sử dụng mật khẩu đã được thay đổi.
Việc sử dụng tài khoản dễ đoán, hay tài khoản mặc định.
Bạn có thể hạn chế tính năng này, việc dễ đoán biết, hay các sử dụng các username tuần tự (123456). Việc hạn chế này sẽ giới hạn các cuộc tấn công vào các tài khoản người dùng cụ thể, bạn không bao giờ gán một username và password mặc định cho hệ thống, hay việc áp dụng chính sách với password và username là không được tuần tự, hay quá dễ đoán biết, cũng là một tính năng tăng cường bảo mật.
Có thể lấy được usernames từ các ứng dụng?
Một vài ứng dụng cho phép bạn đoán, hay lấy được usernames từ các ứng dụng web của bạn. Nếu một kẻ tấn công có thể tổng hợp được danh sách của usernames, anh ta có thể sử dụng tấn công brute-force để tìm kiếm mật khẩu. Việc dễ dàng bị phát hiện ra usernames cũng là một vấn đề. Ví dụ, một forums tại trang web msn.com mà có thể sử dụng một phần mềm lấy được toàn bộ các username của nó. Có nghĩa khi đó người dùng sẽ phải gánh chịu những bức thư quảng cáo, các bức thư chứa virus...Với số user được quản lý lên tới hàng triệu, việc khai thác được số user này cũng là mục tiêu của các kẻ tấn công.
Một thông báo lỗi được hiện lên với quá nhiều thông tin về username hay password.
Khi tôi loging vào một trang web của ngân hàng, nhưng tôi lại gõ sai mật khẩu. Tôi nhận được một thông báo là, mật khẩu của tôi không đúng. Nhưng nó cũng thông báo rằng mật khẩu của tôi bao gồm 4 ký tự, và là các ký tự số, tôi không thể gõ các ký tự thường được. Trong khi các thông đó hiện ra với tôi như vậy, nó sẽ giúp tôi dễ dàng nhớ ra được mật khẩu của mình và thực hiện loging vào hệ thống. Nhưng điều đó cũng dễ dàng cho các kẻ tấn công khoanh vùng mật khẩu sử dụng, từ đó dùng các phần mềm tấn công thử liên tục các mật khẩu bao gồm 4 số (tổ hợp 4 của 10 ký tự) quá dễ dàng cho một kẻ tấn công có kinh nghiệm.
Làm cách nào để bạn phát hiện và chống việc tấn công brute-force và đoán tài khoản hay mật khẩu?
Để chống việc tấn công brute-force đoán biết mật khẩu, bạn phải có cơ chế phát hiện ra các cuộc tấn công đó. Để giảm thiểu vấn đề này bạn chỉ cho phép một user log-on sai mấy lần, nếu người dùng log-in sai hơn số cho phép tài khoản sẽ bị khoá trong bao lâu đó. Hoặc từ một địa chỉ IP bạn không thể đăng nhập quá nhiều username và password được.
Đôi khi mã nguồn của trang web lại có những thông tin về Username và Password?
Nếu có đoạn mã này, bạn cần phải xoá chúng khỏi mã nguồn của trang web, đây là một kiểu tấn công khá cơ bản.
Làm cách nào để hệ thống không cho sử dụng các tài khoản ám muội?
Tôi thấy một hệ thống có trang web cho thương mại cho phép người dùng truy cập vào các file nếu họ đã biết được đường dẫn URL của files đó. Để cho việc này không thể xảy ra bạn cần phải thêm những đoạn mã vào phía sau, để chỉ có những người đã log-in vào mới có quyền truy cập vào nội dung của file đó mà thôi.
Người dùng có thể thay đổi username?
Một vấn đề đặt ra là người dùng muốn thay đổi username cho một việc gì đó mà không cần phải tạo một tài khoản mới. Một vài hệ thống, tuy nhiên hầu hết đều không cho phép bạn thực hiện việc này bởi username là một dữ liệu chính được tạo ra. eBay cho phép người dùng thay đổi username tại đó bởi họ nghĩ như vậy sẽ có thể khó khăn hơn trong việc tấn công vào các tài khoản của họ. Một vấn đề khác bạn cũng cần phải thận trọng trong việc cho phép người dung thay đổi username. Bởi khi kẻ tấn công biết được username và password và thay đổi thì người dùng sẽ mãi mãi mất tài khoản.
Tại sao bạn lại cần địa e-mail cho usernames?
Microsoft Passport yêu cầu bạn thiết lập cho một username một địa chỉ e-mail. Usernames có địa chỉ e-mail nhưng nó lại cho phép các kẻ spammers khai thác địa chỉ email và tạo sự khó khăn trong việc hay đổi một username. Nó cũng thông báo cho người dùng khi có những yêu cầu từ địa chỉ e-mail, ví như người dùng quên mật khẩu và yêu cầu mật khẩu khi đó hệ thống sẽ gửi mật khẩu vào email của người dùng, đó cũng là một cách khai thác khi biết địa chỉ email của đối tượng, việc dữ mật khẩu, hay các chính sách bảo mật trên máy tính là một điều vô cùng quan trọng, bởi khi địa chỉ e-mail của bạn bị khai thác thì sẽ có rất nhiều thông tin khác trên mạng của bạn cũng dễ dàng bị khai thác.
Làm cách nào để người dùng nhận được một tài khoản online mà người dùng không sử dụng đến chúng?
Rất nhiều ngân hàng tự động cung cấp các tài khoản online cho những người đăng ký sử dụng dịch vụ của họ, kể cả trường hợp người dùng không bao giờ sử dụng đến các tài khoản online đó. Có người không bao giờ sử dụng Internet, và cũng không muốn học cách sử dụng nó, hay không tin tưởng vào sự bảo mật của ngân hàng. Và điều đó cũng có khả năng tạo ra những mối nguy hiểm, khi có những tài khoản được tạo ra, và có thể bị khai thác bởi các kẻ tấn công.

2. Các vấn đề liên quan tới Password Management
Người dùng có thể dễ dàng thay đổi được passwords?
Nếu bạn không tạo ra khả năng dễ dàng cho họ thay đổi passwords, họ sẽ không thích làm việc này. Thay đổi passwords có thể là một tính năng của tất cả các hệ thống thực hiện chức năng xác thực người dùng. Một tab ứng dụng cho phép người dùng truy cập trực tiếp vào việc thay đổi mật khẩu của họ là cần thiết.
Người dùng có cần thiết phải xác thực lại trước khi thay đổi password?
Khi bạn cho phép người dùng thay đổi mật khẩu, sẽ có ba mục cần phải thực hiện đó là: Old password, new password và xác nhận lại new password. Điều này chống lại việc chiếm đoạt mật khẩu khi người dùng quên không log-out khỏi hệ thống khi đã thực hiện xong các tác vụ. Hoặc khi người dùng đã đóng trình duyệt web nhưng hệ thống vô tính lại lưu lại mật khẩu và tài khoản của họ, khi người dùng khác truy cập vào trang web đó thì mật khẩu và username đã được cung cấp khi đó nếu không cần xác thực lại mật khẩu cũ thì người kia hoàn toàn có thể chiếm đoạt được tài khoản của người dùng.
Sau khi người dùng thiết lập một password và bạn có thể tạo ra những phiên làm việc và thiết lập thời gian có hiệu lực cho password này, nếu password hết hiệu lực hệ thống sẽ gửi thư, gửi đường link vào email cho người dùng và yêu cầu họ phải đổi mật khẩu. Điều này giúp người dùng dễ dàng thay đổi mật khẩu hơn, và cũng đem lại cho người dùng chính sách bắt buộc phải thay đổi mật khẩu sau một khoảng thời gian nhất định
Cuối cùng, khi người dùng thay đổi mật khẩu, thường một email xác nhận mật khẩu đã được thay đổi sẽ gửi đến người dùng bao gồm địa chỉ IP khi thực hiện thay đổi.
Làm cách nào để hệ thống cho phép lấy lại password?
Một cách thay đổi khác là cho phép người dùng lấy lại mật khẩu, bạn có thể reset lại mật khẩu của họ. Cho phép người dùng lấy lại mật khẩu có nghĩa mật khẩu cũ đã được sử dụng phải được lưu vào cơ sở dữ liệu và được mã hoá.
Ví dụ: một hacker có thể chiếm quyền điều khiển toàn bộ một máy PC của nạn nhân. Hacker có thể nhìn thấy các tài khoản trong ngân hàng, và họ kick vào Forgot My Password và đợi sau một thời gian sẽ nhận được một e-mail. Nội dung của bức thư sẽ chứa mật khẩu, hay có thể cho phép người dùng reset lại mật khẩu, từ đó họ có thể truy cập vào tài khoản trong ngân hàng một cách đễ dàng, sau đó kẻ tấn công cẩn thận xoá sạch dấu vết truy cập trên hệ thống.
Một biện pháp tốt đó là khi nhận được một email thì nội dung của email đó sẽ không chứa thông tin về mật khẩu của người dùng đang sử dụng, mặt khác buộc phải thay đổi mật khẩu khi xác thực địa đường link đó, khi người dùng không thể đăng nhập vào tài khoản của mình họ sẽ phát hiện ra tài khoản của họ đã bị mất và từ đó có biện pháp tăng cường bảo mật hơn.
Làm thế nào để hệ thống cần phải kiểm tra trước khi cho phép người dùng reset lại password của họ?
Một biện pháp khác cần phải yêu cầu một vài thông tin trước khi gửi e-mail yêu cầu reset lại mật khẩu - ví như câu hỏi "bạn yêu quý ai nhất" khi có cung cấp đúng, và địa chỉ email đúng hệ thống sẽ gửi yêu cầu reset mật khẩu, điều đó mang lại tính bảo mật cao hơn.
Hệ thống sẽ gửi các thông tin nhạy cảm qua e-mail?
Một cách sử dụng với việc lấy lại mật khẩu là làm thế nào để bạn cung cấp mật khẩu cũ lại cho người dùng. Ví dụ, khi tôi nhìn thấy password là E*Trade's, tôi sẽ biết đó là mật khẩu đang được sử dụng. Nhưng một biện pháp là bạn sẽ cung cấp cho người dùng không bao giờ lấy lại mật khẩu bởi nó đã một lần bị thay đổi và không đảm bảo tính bảo mật, người dùng chỉ có thể thiết lập một mật khẩu mới mà thôi. Thông tin lấy lại mật khẩu sẽ ở trên một trang web được mã hoá SSL, khi truyền tải thông tin, bởi nó sẽ không cho người khác tóm gói tin mật khẩu mới được cung cấp, phân tích và giải mã gói tin đó.
Một dạng khác nữa là khi người dùng nhận được email bao gồm username và password họ sẽ dữ lại để cho việc nhỡ quên trong tương lai và có thể đem ra tái sử dụng. Điều đó không chỉ mang đến những nguy cơ tiềm tàng vì lưu thông tin ở dạng "clear text" là một điều vô cùng nguy hiểm.
Hệ thống sẽ cung cấp một mật khẩu tạm tời.
Nếu bạn cung cấp mật khẩu cũ cho người dùng đổi mật khẩu, điều đó sẽ không bảo mật và an toàn. Bạn cần tạo ra một mật khẩu tạm thời cung cấp cho người dùng để log-in vào hệ thống sau đó người dùng sẽ buộc phải thay đổi mật khẩu đó.
Hệ thống trợ giúp bạn nhớ mật khẩu.
Khi bạn chót quên mật khẩu, bạn cần phải nhớ câu hỏi bí mật mà hệ thống cung cấp khi bạn đăng ký tài khoản như "con vật bạn yêu quý nhất là? " chẳng hạn bạn buộc phải nhớ nó, hay khi bạn quên mật khẩu thì bạn định nghĩa một sự trợ giúp từ hệ thống như, tôi không nhớ đã chọn câu hỏi bí mật nào nhưng hệ thống có thể sẽ cung cấp câu hỏi bí mật cho bạn và bạn chỉ cần trả lời, hoặc sau khi trả lời đúng hệ thống sẽ hiện câu hỏi bí mật ra cho bạn...
Kết luận
Trong phần 2 của bài viết này tôi sẽ giới thiệu với các bạn một số vấn đề liên quan tới:
User Privacy
Session Authentication
User Security
Cookies
General Principles

Theo SecurityFocus - của Mark Burnett (05-05-2003)
Người viết: Hoàng Tuấn Đat - Vnexperts

[Question] Re: Kiểm tra xác thực trên Web site	30/01/2007 04:17:02 (+0700) \| #2 \| 38958

kryptos
Member

Joined: 12/09/2006 10:42:48
Messages: 24
Offline

Việc không đáp ứng được yêu cầu bảo mật cho người dùng cũng là một vấn đề đối với các nhà phát triển Web. Hy vọng trong tương lai sẽ có những tiêu chuẩn để đánh giá, và có thể tiến hành những bước kiểm tra bảo mật cho những sản phẩm Web. Trong bài viết này tôi giới thiệu chuẩn hoá trong việc kiểm tra giám sát tình trạng bảo mật của bạn, bao gồm các vấn đề như:
User Privacy
Session Authentication
User Security
Cuối cùng là Cookies
User Privacy
Làm thế nào để hệ thống tin tưởng vào quá trình truyền các gói tin quan trọng.
Khi có một người dùng log-in vào hệ thống, thiết lập các thông tin về họ, các câu hỏi bí mật, và luôn luôn sử dụng cơ chế bảo mật để truyền dữ liệu qua SSL. Tuy nhiên phải đảm bảo rằng toàn bộ các trang SSL đều không thể lấy lại được thông tin bởi một cách giải mã nào đó.
Rất nhiều trang web như Hotmail và Yahoo! Cung cấp trang web bảo mật dành cho việc log-in của người dùng, như nó không phải là một lựa chọn mặc định; người dùng phải truy cập vào một đường link khác để thực hiện việc bảo mật log-in.
Mật khẩu của bạn có được mã hoá với một thuật toán hash nào đó không?
Bạn cần phải biết rằng không bao giờ lưu mật khẩu của người dùng là các văn bản không được mã hoá. Để đảm bảo tối thiểu rủi ro có khả năng xảy ra bạn phải mã hoá các dữ liệu chứa mật khẩu của người dùng. Một cách tốt nhất là bạn không nên chỉ dùng mỗi tính năng mã hoá dữ liệu, mà trước khi mã hoá dữ liệu bạn nên thực hiện việc làm đảo lộn các ký tự băng một thuật toán hash nào đó. Sau khi sử dụng thuật toán dữ liệu sẽ hiển thị không phải là những mật khẩu cũ nữa, sau đó bạn thực hiện việc mã hoá sẽ bảo mật hơn rất nhiều.
Trong hầu hết các trường hợp, một Web site sẽ không cần phải biết một mật khẩu của người dùng; mà họ chỉ cần biết được một điều là - người dùng biết mật khẩu đó. Còn dữ liệu của mật khẩu đó sẽ được Hashing rồi lưu lại dạng mã hoá.
Session Authentication
Một người có thể vượt qua bước xác thực khi truy cập trực tiếp vào một module không?
Để hạn chế backdoors, bạn phải chắc chắn một điều rằng tất cả mọi tài nguyên của bạn cần phải được cung cấp với đối tượng khi đã được xác thực. Đảm bảo không một đường dẫn đến một tài nguyên nào mà người dùng có thể lấy tài nguyên đó trực tiếp mà không cần phải xác thực.
Does the system allow authentication to the Web server's operating system or network?
Rất nhiều hệ thống xác thực sử dụng trực tiếp các tài khoản trong hệ điều hành. Trong khi điều đó mang lại cho bạn sự thuận lợi và tính dễ dàng cho việc triển khai, nhưng bạn phải thực sự quan tâm đến quá trình làm việc với nó, ví dụ một kẻ tấn công có thể sử dụng hệ thống xác thực của bạn để đoán mật khẩu của user: administrator hay các tài khoản có đặc quyền khác. Họ sẽ có khả năng khai thác được các thông tin quan trọng trong hệ thống tài khoản của bạn.
Nếu bạn làm việc đó sử dụng hệ thống tài khoản trong hệ điều hành, bạn hãy hạn chế một số đặc quyền, và có kế hoạch tạo ra các user, groups một cách cụ thể, hay sử dụng các domains khác nhau.
Làm cách nào để một người dùng log-out hoàn toàn ra khỏi phiên làm việc.
Luôn luôn cung cấp một đường link cho việc ngắt một phiên làm việc, đảm bảo rằng phiên làm việc của người dùng được ngắt hoàn toàn, bằng một cú kick chuột vào đường dẫn log-out.
Làm cách nào để tránh việc quên không log-out của người dùng?
Tôi nhìn vào một hệ thống có thể xoá những phiên đang làm việc với những user đã đuợc xác thực. Nhưng bạn cũng có khả năng để xoá phiên làm việc đó. Trong một tình huống tốt hơn, bạn thêm giá trị thời gian vào một phiên làm việc, thiết lập một khoảng thời gian sau khi người dùng không làm gì đó với các ứng dụng hệ thống sẽ tự động log-out tài khoản của người dùng. Việc này nhằm đảm bảo khi người dùng để quên, không log-out khỏi hệ thống, tránh trường hợp bị kẻ xấu lợi dụng.
Tránh trường hợp cùng 1 user có nhiều phiên làm việc.
Bình thường một chương trình sẽ yêu cầu user log-in lại khi mở một cửa sổ mới. Việc thiết lập một tín hiệu là tài khoản người dùng đó đã được xác thực, khi đó bạn mở một cửa sổ khác hệ thống sẽ thực hiện việc tự động đăng nhập. Bạn muốn thực hiện việc chuyển từ user này sang user khác bằng cách mở nhiều cửa sổ hay sử dụng cookies.
Bạn cần phải thiết lập hệ thống cho phép nhiều user log-in từ một máy tính bằng cách bật nhiều cửa sổ, và hạn chế việc chuyển quá trình log-in từ cửa sổ này sang cửa sổ khác mà user vẫn được log-in.
User Security
Có thể sử dụng một ứng thứ ba cho việc xác thực người dùng?
Ví dụ như các trang web lớn như eBay, Hotmail, và PayPal có một vấn đề lớn với người dùng là bị mất quyền truy cập tới trang web. Bởi các thông tin của họ đã bị đánh cắp, là một lỗi lớn trong các trình duỵêt, và cách cấu hình ẩu trên các máy client đã vô tình khiến các thông tin nhạy cảm của người dùng bị thất lạc ra ngoài.
Trên trình duyệt sẽ không xuất hiện ra những đường link chính xác đã được truy cập, bởi điều đó rất dễ dàng cho kẻ tấn công lợi dụng, từ đó lấy cắp mất tài khoản của người dùng.
Bạn đã đào tạo cho người dùng biết cách tự bảo vệ các thông tin của họ?
Mọi trang Web đều nên có một trang dành riêng cho việc chỉ dẫn người dùng tự bảo vệ các thông tin cá nhân và hiểu được các chính sách bảo mật. Ví dụ, trang hướng dẫn về bảo mật sẽ nói với người dùng là trang web chính thức sẽ không bao giờ hỏi người dùng email và mật khẩu của họ, bất kỳ câu hỏi nào được đưa ra đó là những hình thức lừa đảo. Và từ đó có tạo ra khả năng người dùng sẽ ít bị lừa đảo hơn.
Cho phép người dùng xem quá trình log-in, log-out theo thời gian
Một cách rất tốt là cho phép người dùng nhìn lại log quá trình log-in, log-out tài khoản của họ. Với tính năng này người dùng sẽ biết được có người sử dụng tài khoản của mình hay không bằng cách so sánh thời gian log-in thực tế với quá trình log của hệ thống
Người dùng có thể dễ dàng phản ánh lại tình hình bảo mật?
Người dùng thường chú ý tới các sự việc sảy ra với tài khoản của họ, nhưng họ lại không hiểu cái gì về nó. Tất cả các trang web đều không chú trọng đến việc ghi lại các phản ánh của người dùng về các vấn đề bảo mật. Việc phát triển Web cho phép phản ánh lại các sự kiện xảy ra đối với tài khoản người dùng là cần thiết.
Người dùng có thể có những lựa chọn bảo mật?
Nếu bạn không thể cân bằng giữa việc bảo mật cho các tài khoản và sự thân thiện cho người dùng, vậy sao bạn không dành việc lựa chọn đó cho người dùng. Ví dụ, người dùng có thể tự thiết lập “session timeouts, IP Restriction, failed logins allowance. Yahoo là có một tuỳ chọn cho người dùng sự lựa chọn “session timeouts”, với những tuỳ chọn sẽ mang đến khả năng bảo mật tốt hơn với người dùng hiểu biết, và những người mới bắt đầu thì tính dễ sử dụng cần phải đặt lên hàng đầu.
Người dùng có thể lấy lại hay xoá bỏ accounts?
Nếu bạn cho phép người dùng tạo ra accounts, bạn cũng phải cho phép họ dễ dàng xoá bỏ accounts đó.
Cookies
Will a hijacked cookie allow a user logon?
Ghi lại toàn bộ cookie trên một hệ thống của một user có thể được thực hiện, nhưng điều đó cũng mang đến nhiều nguy cơ bảo mật. Nếu một kẻ tấn công có khả năng truy cập trái phép vào hệ thống và đánh cắp các thông tin trong cookie, tài khoản của người dùng đó có nguy cơ bị mất là rất cao. Một dạng khác, bạn có thể quan tâm là cần phải xác thực các thông tin, hay xác thực địa chỉ IP thì mới có khả năng truy cập vào các thông tin trên.
Sử dụng cookie để cho việc tự động đăng nhập vào hệ thống tiềm tàng rất nhiều vấn đề về bảo mật.
Rất nhiều thông tin nhạy cảm được lưu lại trong cookies?
Việc sử dụng cho người dùng log-in vào một hệ thống nào đó không phải là nguy cơ bảo mật duy nhất của cookies. Rất nhiều trang chứa các thông tin của người dùng trong cookies. Một điều lưu ý là đừng bao giờ lưu các thông tin thật của mình trong cookies.
Are cookies marked as secure?
Vấn đề bảo mật cookies được miêu tả trong RFC 2109, chống lại quá trình truyền tải thông tin tới một trang web không hỗ trợ SSL. Nhưng rất nhiều trang web đã thực hiện quá trình bảo mật này.
General Principles

Với nội dung của bài viết bao gồm hai phần bạn đã từng bước hiểu được các nguy cơ tiềm ẩn trong việc xác thực trên các trang Web và đối với các nhà phát triển Web việc có một khung sườn cho vấn đề bảo mật là cần thiết. Nếu bạn là người quản trị web site hãy có những chính sách bảo mật cụ thể, và yêu cầu người phát triển web có đáp ứng được toàn bộ các yêu cầu trên hay không.

Hoàng Tuấn Đạt Theo SecurityFocus.

Go to:

Users currently in here
1 Anonymous