Tại sao các trang web nhất định ngăn không gian trong mật khẩu?

Có vẻ như ít phổ biến hơn với các trang web mới hơn, nhưng nhiều trang web tôi cần có tài khoản trên (như để thanh toán hóa đơn, v.v.) ngăn tôi tạo mật khẩu có khoảng trắng trong đó. Điều này chỉ làm cho mọi thứ trở nên khó nhớ hơn và tôi biết rằng không có hạn chế về cơ sở dữ liệu hoặc lập trình đối với các khoảng trắng trong mật khẩu, được mã hóa hoặc (trời cấm) nếu không. Tại sao, sau đó, phím cách thường bị phân biệt đối xử khi đăng ký một trang web?

Có một số lượng lớn sự ngu ngốc khi nói đến mật khẩu trong các trang web.

• Một số có lý do kỹ thuật hoàn toàn (hợp lệ hay không, đó là một câu hỏi khác, nhưng gần như tất cả chúng đều không):

Mật khẩu của bạn phải có bốn ký tự và chỉ có các chữ số.

(Bằng cách giới hạn mật khẩu ở phạm vi 0001 .. 9999, bạn chỉ cần lưu trữ chúng dưới dạng số, văn bản gốc, trong cơ sở dữ liệu)

• Khác được giải thích bởi một số suy nghĩ sai lầm rằng họ sẽ làm cho mật khẩu an toàn hơn :

Mật khẩu của bạn phải bắt đầu bằng chữ in hoa và kết thúc bằng một chữ số.

(Bằng cách này, nhà phát triển hoặc người quản lý đã cho rằng điều này thực sự sẽ buộc người dùng chọn mật khẩu an toàn, trong khi quy tắc là "Mật khẩu của bạn phải chứa tối thiểu 6 ký tự và chứa ít nhất một chữ in hoa, chữ thường và một chữ số "sẽ không thực hiện được điều đó)

• Cuối cùng, được giải thích bởi thực tế là mật khẩu được lưu trữ trên bản rõ và có một số sự mơ hồ về cách chúng được lưu trữ, xử lý hoặc truy xuất và không có thời gian để kiểm tra chúng.

Mật khẩu của bạn chứa một ký tự không hợp lệ é.

hoặc là,

Mật khẩu của bạn y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dchứa một số ký tự không hợp lệ. Chỉ sử dụng các ký tự từ bảng chữ cái Latinh và chữ số.

hoặc là,

Mật khẩu của bạn không thể chứa các ký tự khoảng trắng.

Trong cả ba trường hợp, nhà phát triển chỉ đảm bảo rằng mật khẩu như thế này sẽ được lưu trữ chính xác.

• Trong trường hợp đầu tiên, điều gì ésẽ xảy ra %C3%A9nếu được gửi thành khi gửi? Hoặc nếu cơ sở dữ liệu sẽ lưu trữ ékhông chính xác?

• Trong trường hợp thứ hai, điều gì sẽ xảy ra nếu PHP (tại sao PHP?) Không thể xử lý unicode và làm điều gì đó khủng khiếp khi nhận được mật khẩu như thế này? Nếu <nhân vật gây rắc rối thì sao? Điều gì xảy ra nếu &ký tự được hiểu là dấu phân cách trong một URL (giả sử rằng vì một số lý do, mật khẩu đang được gửi qua GET thay vì POST)? Điều gì xảy ra nếu 'được cơ sở dữ liệu diễn giải, bởi vì, hãy đoán xem, chúng ta không biết SQL Injection là gì và làm thế nào để tránh nó? Hoặc nếu 'được chuyển thành \'?

• Trong trường hợp thứ ba, điều gì sẽ xảy ra nếu PHP (một lần nữa?) Cắt khoảng trắng trong một số trường hợp và không phải trong các trường hợp khác? Điều gì sẽ xảy ra nếu các quản trị viên (người có quyền truy cập mật khẩu người dùng trong bản rõ) bị mất vì họ chỉ thấy một khoảng trắng, trong khi người dùng đã đặt ba khoảng trắng liên tiếp ?

Trong cả ba trường hợp, những sự mơ hồ đó đều được giải quyết dễ dàng thông qua thử nghiệm , đặc biệt là thử nghiệm đơn vị. Nhưng trong một số lượng lớn các dự án, không có thử nghiệm nào cả , và không có thời gian để thử nghiệm (nhưng vẫn còn nhiều thời gian để gỡ lỗi sau này).

Điều này có nghĩa là liệu nhà phát triển có cố gắng nghĩ về hậu quả có thể xảy ra khi cho phép dấu cách hoặc ký tự unicode hoặc bất kỳ ký tự nào bên ngoài ASCII 48..57 65..90 97..122 (chữ số, chữ thường, chữ in hoa) , cách dễ nhất, khi kiểm tra là không thể, là chỉ cấm chúng .

Theo tôi, đây là lý do duy nhất để cấm không gian. Yannis Rizos đã đưa ra một lý do khác liên quan đến UX. Mặc dù là một lý do chính đáng trong lý thuyết, nó hoàn toàn không hoạt động trong thực tế: các trang web được tạo bởi những người thực sự quan tâm đến UX không sửa các quy tắc mật khẩu ngu ngốc. Thay vào đó, các trang web nơi khoảng trắng thực sự bị cấm phần lớn được thực hiện bởi những người chưa bao giờ nghe về UX . Điều này đặc biệt đúng vì việc cấm bất kỳ ký tự nào thực sự gây khó chịu theo quan điểm của UX, vì mọi hạn chế liên quan đến mật khẩu, bao gồm cả những hạn chế hữu ích, là số lượng ký tự tối thiểu.

Câu trả lời là Lịch sử

Chúng tôi dường như quên rằng cơ sở của rất nhiều này xuất phát từ một thời gian khi lưu trữ là không có hiệu quả miễn phí (trên đĩa hoặc trong bộ nhớ) khi khả năng của chúng tôi để quản lý tất cả những điều này đã phần nào ít hơn bây giờ và không kém phần khả năng của hệ thống tự động để cố gắng để cùng crack cũng có phần ít hơn.

Có rất nhiều ý kiến ​​trái chiều về mật khẩu dựa trên những gì chúng ta biết bây giờ và những gì chúng ta có thể làm bây giờ nhưng thực tế đơn giản là chúng ta thường xử lý sự kết hợp giữa tư duy kế thừa và hệ thống di sản.

Có nên hạn chế trong các hệ thống mới bây giờ ? Tôi hy vọng không - ít lý do hơn bây giờ

IMHO, thật ngu ngốc khi bất kỳ trang web / ứng dụng nào sử dụng tính năng băm và / hoặc muối hiện đại để lưu trữ mật khẩu để không cho phép có khoảng trắng trong mật khẩu. Nhưng, một số hệ thống cũ (đọc về điều này ở đâu đó) vẫn chuyển xung quanh mật khẩu trong bản rõ - vì vậy không cho phép không gian ở đó có thể có ý nghĩa. Ngoài ra, một số ứng dụng có thể "tước" tất cả các chuỗi đầu vào mà chúng nhận được. Vì vậy, mật khẩu bắt đầu hoặc kết thúc bằng một khoảng trắng sẽ không tốt (tất nhiên, điều đó đã bị chiếm dụng, nhưng bạn có thể tưởng tượng điều gì không thể xảy ra với hầu hết mọi người đến với trang web của chính mình). Không có gì "xấu" trong việc cho phép các khoảng trắng trong mật khẩu - như bạn chỉ ra, các DB sẽ không cho phép băm hoặc các phiên bản văn bản gốc.

Trên thực tế, hầu hết bạn bè Windows của tôi không biết rằng họ có thể sử dụng khoảng trắng trong mật khẩu của họ - Vì vậy, có thể, theo câu trả lời của Tim Medora, chủ sở hữu trang web không muốn có cơ hội với lamahs (xin lỗi) hoặc có thể một số người trong số họ có quan niệm sai lầm và / hoặc không biết gì về những lợi thế mà không gian có thể cung cấp.

Nó được thực hiện vì cùng một lý do là nhiều trang web không cho phép dấu gạch ngang, dấu nháy đơn hoặc chữ cái không phải ASCII trong tên, mặc dù đây là những thực tiễn rất phổ biến ngay cả ở Hoa Kỳ và nó đòi hỏi nhiều công việc hơn để không cho phép các ký tự này hơn là chỉ cho phép họ

Nó cũng được thực hiện vì lý do tương tự nhiều bộ lọc từ của nhiều trang web sẽ không cho phép bạn sử dụng các từ như "cocky", "retardant" hoặc thậm chí "tích lũy" (mặc dù nhiều từ ngữ chủng tộc thông thường hoàn toàn ổn).

Đó là bởi vì rất nhiều nhà phát triển dường như hoàn toàn thiếu ý thức chung, hoặc ít nhất là có trí tưởng tượng rất hạn chế khi xem xét các đầu vào và kịch bản có thể có của người dùng. Một tỷ lệ nhỏ trong số họ có thể xử lý thông tin sai lệch (ngoại trừ các ký tự không phải là chữ và số bằng cách nào đó là một cách thực hành tiêu chuẩn hoặc thuật toán băm hoặc phương thức lưu trữ không thể xử lý khoảng trắng hoặc ký tự đặc biệt). Những người khác có thể chỉ đơn giản là lười biếng, họ lo lắng về các vấn đề bộ ký tự, vì vậy họ chỉ cần hạn chế đầu vào trong một không gian ký tự tối thiểu. Và sau đó có thể có những người đang thực hiện xác nhận / vệ sinh đầu vào quá nhiệt vì hoang tưởng do thiếu hiểu biết về các mối đe dọa thực sự.