it-swarm-vi.com

Tại sao không cho phép các ký tự đặc biệt trong mật khẩu?

Thủ phạm trong trường hợp này là một ngân hàng cụ thể (và đặc biệt lớn) không cho phép các ký tự đặc biệt (thuộc bất kỳ loại nào) trong mật khẩu của họ: Chỉ [a-Z 1-9]. Là bất kỳ lý do hợp lệ của họ để làm điều này? Có vẻ như hiệu quả đối với sức mạnh mật khẩu như thế này, đặc biệt là đối với một hệ thống bảo vệ thông tin có giá trị như vậy.

Điều duy nhất tôi có thể nghĩ ra là một nỗ lực yếu để ngăn chặn việc tiêm SQL, nhưng điều đó sẽ cho rằng mật khẩu không bị băm (điều mà tôi chắc chắn hy vọng là không đúng).

68
Gary

Một lời giải thích tôi chưa từng thấy ở đây là nhiều tổ chức tài chính được tích hợp chặt chẽ với các hệ thống cũ và bị ràng buộc với những hạn chế của các hệ thống đó.

Điều trớ trêu là tôi đã thấy các hệ thống được xây dựng để tương thích với các hệ thống cũ nhưng hiện tại các hệ thống cũ đã biến mất và chính sách vẫn phải tồn tại để tương thích với hệ thống mới hơn được xây dựng để tương thích với hệ thống cũ.

(bài học ở đây là nếu bạn phải tương thích với một hệ thống cũ, hãy cho phép loại bỏ những hạn chế đó trong tương lai).

65
Mark Burnett

Còn chi phí hỗ trợ thì sao? Hãy nói rằng chúng tôi cho phép bất cứ ai tạo mật khẩu bao gồm ký tự. Hurrah, chúng tôi có thể sử dụng các ký tự đặc biệt trong mật khẩu của chúng tôi. Nhưng chờ đã - làm thế nào trên trái đất chúng ta có thể nhập mật khẩu đó nếu chúng ta muốn truy cập vào ngân hàng của mình từ điện thoại di động? Dễ dàng nhập từ bàn phím của chúng tôi hơn từ điện thoại di động.

Còn ngày lễ thì sao? Chúng tôi đang ở Vương quốc Anh, nơi chỉ truy cập vào bàn phím Vương quốc Anh. Thay vì chúng ta có thể dễ dàng gõ £. Lời easily rất quan trọng ở đây. Đối với một số người dùng trung bình, việc gõ ký tự cho bàn phím "mới" có thể là một vấn đề. Làm thế nào anh ta sẽ cố gắng giải quyết nó? Anh ta có thể sẽ gọi cho bộ phận hỗ trợ ngân hàng để yêu cầu họ thay đổi mật khẩu hoặc hỏi why the € character dissapeared from his keyboard.

13
p____h

Điều này có thể được coi là một biện pháp chuyên sâu - nếu có lỗi tiêm hoặc dữ liệu khác, việc giới hạn bộ ký tự mật khẩu và độ dài có thể ngăn không cho khai thác. Nó cũng phần nào đơn giản hóa việc triển khai, vì nếu chúng chỉ xử lý 7-bit ASCII ký tự, xử lý chuỗi ký tự Unicode và đa chuỗi là không liên quan và việc triển khai đơn giản hơn là một quy tắc ít có khả năng chứa lỗi.

Tuy nhiên, việc đánh giá rủi ro giảm này chống lại rủi ro gia tăng do chất lượng mật khẩu thấp hơn là không đơn giản - tôi hy vọng rằng khi số lượng người dùng hệ thống tăng lên, số lượng mật khẩu có thể bị xâm phạm cũng tăng lên, đầu tư vào việc nâng như vậy hạn chế đáng giá hơn. Tất cả những gì đã nói, hầu hết mật khẩu của người dùng sẽ rất tệ ngay cả khi trường hoàn toàn không bị hạn chế.

12
D Coetzee

Tôi đoán là chính sách tồn tại cho tất cả các trường do người dùng nhập và chính sách nhập của người dùng giống nhau (không có ký tự đặc biệt) đã được áp dụng cho các trường bao gồm cả mật khẩu để đơn giản. Hoặc tại một số thời điểm, một số ngân hàng đã không băm mật khẩu và có một cuộc tấn công SQLi thông qua trường mật khẩu của họ và một chính sách đã được quyết định rằng mật khẩu không thể có các ký tự đặc biệt (và lý do cho chính sách bị lãng quên sau khi băm được đưa ra).

Chắc chắn có một lợi ích bảo mật là không cho phép các ký tự đặc biệt trong các trường nhập vào người dùng khác không được băm và có thể được sử dụng cho các cuộc tấn công khác nhau như SQLi hoặc XSS (trên quản trị viên ngân hàng đang xem tài khoản). Tuy nhiên, các mối đe dọa này thường được giải quyết bằng cách luôn sử dụng các tham số ràng buộc trong SQL và luôn vệ sinh đầu vào của người dùng trước khi hiển thị/lưu vào db.

Tôi đoán khác là họ muốn có các quy tắc tùy chỉnh có thể khác với các nơi khác, vì vậy bạn không thể dễ dàng sử dụng lại mật khẩu mạnh tiêu chuẩn của mình (có thể bị mất) và phải đưa ra một cái gì đó duy nhất cho trang web của họ.


EDIT: Về suy nghĩ xa hơn, tùy thuộc vào ngôn ngữ, tôi có thể nghĩ ra ít nhất ba ký tự đặc biệt ASCII nên bị cấm/tước bỏ khi cho phép chúng chỉ tạm thời định mệnh. Cụ thể: \0 (null - ascii 0), vì nó thường được sử dụng để chỉ kết thúc chuỗi trong các ngôn ngữ kiểu C (có thể người dùng thay đổi bộ nhớ sau khi kết thúc chuỗi). Ngoài ra vận chuyển trở lại và nguồn cấp dữ liệu \r (ascii 13) và \n (ascii 10), vì những điều này thường phụ thuộc vào hệ thống cho dù ngắt dòng là \r\n hoặc là \n và điều đó không thể tránh khỏi, tôi chỉ có thể đăng nhập từ windows chứ không phải máy mac/linux. Trên thực tế, có vẻ khá hợp lý khi chỉ cho phép có thể in ascii (32-126) và cấm không thể in ASCII 0-31 và 127.

Nhưng nếu bằng các ký tự đặc biệt, bạn có nghĩa là unicode không ASCII ký tự (như ,./<>?;':"[]{}\|[email protected]#$%^&*(-=_+ có vẻ hợp lý vì đơn giản thực hiện từ nhiều hệ điều hành/bàn phím/trình duyệt để không cho phép các ký tự đặc biệt. Hãy tưởng tượng mật khẩu của bạn có một chữ thường pi trong đó. Đó có phải là chữ Hy Lạp pi (π) là mật mã 0x3c0 hay chữ thường chữ viết hoa (ⲡ) là tên mã 0x2ca1 - chỉ có một loại sẽ hoạt động và loại vấn đề này có các ký tự tương tự với các mật mã khác nhau sẽ tồn tại trong unicode. Hàm băm của bạn hoạt động trên các bit sẽ không thể đánh đồng hai số π, vì vậy nếu bạn thử đăng nhập ở những nơi khác nhau, bạn có thể nhập các ký tự khác nhau.

Tương tự, mặc dù vấn đề này là một trong những lập trình viên phần lớn có thể kiểm soát và cố gắng thực hiện chính xác, cho phép các ký tự unicode tạo ra các vấn đề mã hóa. Đó là đối với các ký tự ascii cơ bản của bạn, mọi thứ được thể hiện bằng một số byte. Tuy nhiên, có một loạt các sơ đồ khác nhau về cách mã hóa unicode. Có phải là UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), mã hóa Latin-N và (đối với một số mã hóa) thứ tự byte (cuối hay nhỏ) ? Mã hóa unicode cho pi (0x3c0) sẽ được biểu diễn dưới dạng byte 2b 41 38 41 2d trong UTF-7, CF 80 trong UTF-8, FF FE c0 03 trong UTF-16 và FF FE 00 00 c0 03 00 00 trong UTF-32. Bạn sẽ không thể đại diện cho pi bằng tiếng Latin-1 (nó chỉ có thêm 95 ký tự có thể in được), nhưng nếu bạn có A1 trong mật khẩu của bạn và ở dạng mã hóa khác nhau, bạn có thể phải thể hiện nó từ bất kỳ ký tự nào sau đây ¡ĄĦЁ‘ก”Ḃ (mà trong một số tiếng Latin-N có thể thành A1).

Có, trang web có thể có bộ ký tự được xác định, nhưng người dùng có thể ghi đè bộ ký tự trên một trang trong trình duyệt của họ hoặc đã sao chép và dán dữ liệu từ nơi khác trong một mã hóa khác. Vào cuối ngày, có thể đơn giản hơn là chỉ cấm những nhân vật đó.

9
dr jimbob

Là một khái quát, đây là những lý do phổ biến nhất mà các tổ chức tài chính hạn chế độ dài và độ phức tạp của bộ ký tự.

(1) Các dịch vụ web là các hệ thống đầu cuối cho các ứng dụng máy tính lớn kế thừa, thường có giới hạn tám ký tự chỉ được tạo thành từ các chữ số và chữ số nhỏ. Không có "ký tự đặc biệt." Điều kỳ lạ là đây là giới hạn phổ biến nhất. +1 cho Mark Burnett ở trên.

(2) Họ không băm mật khẩu, vì vậy họ không thể lưu trữ một chuỗi số có độ dài cố định (nghĩa là đầu ra băm - 32 byte SHA256 (mật khẩu)). Vì vậy, họ phải lo lắng về việc giới hạn kích thước của đầu vào.

(3) Vectơ đe dọa tiêm SQL chỉ là vấn đề về mật khẩu nếu mật khẩu được lưu dưới dạng văn bản rõ ràng. Nhiều tổ chức và những người khác đang lãng phí thời gian lo lắng về việc thoát các ký tự của mật khẩu, khi vấn đề được giải quyết ngay lập tức bằng cách lưu trữ mật khẩu băm (lý tưởng đã muối kéo dài bằng cách sử dụng cái gì đó như PBKDF2).

Khác với việc ưu tiên mật khẩu hỗ trợ khách hàng đơn giản đặt lại bảo mật QUÁ, không có lý do nào có thể chấp nhận được mà tôi biết về việc truyền mật khẩu người dùng bằng văn bản rõ ràng khỏi thiết bị của người dùng. Bạn không muốn chịu trách nhiệm, vì vậy đừng bao giờ chấp nhận chúng. Đó là những gì băm tiền điện tử dành cho.

Dưới đây là một bài đăng blog tuyệt vời tóm tắt một số thực tiễn tốt nhất và bao gồm các mẫu mã. http://crackstation.net/hashing-security.htmlm

4
OnTheShelf

Tôi thực sự đã hỏi một webshop lớn rằng (bol.com, không chắc họ có quốc tế không).

Lời khuyên của họ là sử dụng một mật khẩu mạnh, thay đổi nó thường xuyên, sử dụng các chữ cái và số, nó sẽ dài và có thể một số thứ khác tôi đã quên. Dù sao, lời khuyên thông thường mà không ai làm theo. Nhưng họ dường như quan tâm đến chính sách mật khẩu.

Tuy nhiên, họ không cho phép hầu hết các ký tự đặc biệt và độ dài mật khẩu tối đa là 12 ký tự. Khi hỏi, họ nói với tôi rằng nếu không có quá nhiều người sẽ liên hệ với bộ phận hỗ trợ.

Khi tôi gửi thư lại cho họ để hỏi "Quên mật khẩu của bạn là gì?" Tính năng này là dành cho, tôi không nhận được trả lời ...

Vì vậy, đối với các ngân hàng, nơi đặt lại mật khẩu đơn giản bằng e-mail, tôi đoán chi phí hỗ trợ thực sự là lý do (như được đề xuất bởi những người khác ở đây). Đối với bất kỳ trang web nào khác như bol.com này, tôi rất không tin liệu họ có băm mật khẩu của mình hay không. Bạn nên sử dụng một mật khẩu độc đáo hơn ở đó, nếu cơ sở dữ liệu bị rò rỉ mật khẩu của bạn sẽ được biết đến.

2
Luc

Giới hạn ký tự được đặt thành chữ số sẽ giới hạn khả năng của tập lệnh hoặc khai thác vượt qua giai đoạn xác thực đầu vào.

Người dùng luôn có thể cải thiện bảo mật của họ bằng cách sử dụng mật khẩu dài hơn, nhưng ứng dụng cần phải có một danh sách trắng cụ thể để giúp ngăn chặn các cuộc tấn công.

1
Rory Alsop

Tôi có thể cố gắng đưa ra quan điểm của mình về vấn đề ở trên với tư cách là người thiết kế giao diện UI chứ không phải lập trình viên: điểm quan trọng ở đây là yêu cầu đăng nhập một phần là vấn đề thiết kế giao diện UI chứ không phải vấn đề chỉ lập trình.

Có một cuốn sách tuyệt vời "Apress - Thiết kế giao diện người dùng cho lập trình viên" cho thấy một vấn đề tương tự liên quan đến kích thước cửa sổ mà tôi sẽ đăng dưới đây:

Đây là một mẫu suy nghĩ lập trình phổ biến: chỉ có ba số: 0, 1 và n. Nếu n được phép, tất cả n đều có khả năng như nhau. Kiểu suy nghĩ này xuất phát từ quy ước mã hóa cũ (có thể là thông minh) rằng bạn không nên có bất kỳ hằng số nào trong mã của mình ngoại trừ 0 và 1.

Bây giờ suy nghĩ ở trên là chính xác trong một vấn đề chỉ lập trình, nhưng vì nó liên quan đến giao diện người dùng và đặc biệt là các cửa sổ nên không

Nhưng nó không đúng. Hóa ra, nó không có khả năng như nhau. Có nhiều lý do chính đáng tại sao bạn có thể muốn có một cửa sổ chính xác ở phía trên màn hình (nó tối đa hóa bất động sản màn hình), nhưng thực sự không có lý do nào để chừa hai pixel giữa đỉnh màn hình và đỉnh cửa sổ . Vì vậy, trong thực tế, 0 nhiều khả năng hơn 2.

Bây giờ đến vấn đề của chúng tôi, về mặt lý thuyết, tất cả các nhân vật đều có khả năng như nhau và được phép như nhau theo quan điểm lập trình và chính thức, tuy nhiên ở đây chúng tôi cũng đang ở trong một ví dụ về vấn đề giao diện UI và chúng tôi phải nhận thức được nó và đưa ra trọng số chính xác cho nó .

Vì vậy, tôi sẽ diễn giải một câu trả lời từ chủ đề trên mà theo tôi là đúng:

Hãy nói rằng chúng tôi cho phép bất cứ ai tạo mật khẩu có chứa € char. Hurrah, chúng tôi có thể sử dụng các ký tự đặc biệt trong mật khẩu của chúng tôi. Nhưng chờ đã - làm thế nào chúng ta có thể nhập mật khẩu đó nếu chúng ta muốn truy cập vào ngân hàng của mình từ điện thoại di động? Việc nhập € từ bàn phím của chúng tôi dễ dàng hơn so với từ điện thoại di động.

Đó là điểm chính từ quan điểm khả dụng và chúng ta không nên đổ lỗi cho người dùng nếu anh ta nhận ra vài năm sau đó với điện thoại thông minh khi nhiều năm trước khi chúng không tồn tại, anh ta đã sử dụng một ký tự mà anh ta nên tránh.

Đó là nghĩa vụ của chúng tôi khi nghĩ về loại vấn đề này và để người dùng tránh nó!

0
dendini

Một bữa tiệc muộn - tôi mới đọc rằng lý do cho điều này là vì nhiều ngân hàng, giá trị của việc tăng cường bảo mật cho phép các nhân vật đó vượt xa chi phí thực hiện và chi phí hỗ trợ giao dịch với khách hàng không thể nhớ mật khẩu của họ .

Tôi không nói rằng đó là một lý do tốt, nhưng đó là cách tôi diễn giải những gì tôi đọc.

http://www.theglobeandmail.com/tĩ/digital-cARM/why-canadas-banks-have-weaker-passwords-than-Twitter-or-google/article18325257/

0
Steve Campbell