Có lý do nào khiến một số trang web không cho phép dấu chấm trong mật khẩu không?

Tôi đã tự hỏi tại sao một số trang web không cho phép bất kỳ điều gì khác ngoài chữ cái và số trong trường mật khẩu.Có lý do nào khiến một số trang web không cho phép dấu chấm trong mật khẩu không?

Có lý do bảo mật hay có lẽ đó chỉ là giới hạn của DB mà họ đang sử dụng? Cảm ơn bạn về thông tin.

Chỉnh sửa: Có vẻ như cơ sở dữ liệu của Oracle không thừa nhận chữ hoa và chữ thường? Điều này có đúng không? Tôi đã được thông báo rằng qua PM. Cảm ơn các bạn thông tin, đây thực sự là công cụ hữu ích.

Tôi tự hỏi tại sao câu hỏi này có 3 phiếu bầu để đóng cửa. Không đủ jQuery và vòng tròn tự do?

Nguồn

2010-10-18 Anonymous

+25

Tôi có xu hướng không tin tưởng các trang web có yêu cầu như vậy. "Làm thế nào để bạn lưu trữ mật khẩu của tôi rằng yêu cầu như vậy thậm chí sẽ quan trọng?" là một phản ứng thông thường. – David

@ David: Tôi đồng ý, trong các ứng dụng tôi đã thực hiện chưa bao giờ có vấn đề khi lưu trữ bất kỳ ký tự nào tôi muốn. Tôi tự hỏi nếu có một lý do mặc dù, tôi chỉ lập trình với C#, vì vậy tôi có thể không phải bây giờ về các hạn chế ngôn ngữ khác. –

... và tại sao bạn không thể viết mã để nó không quan trọng. Thật thú vị khi sử dụng dấu ngoặc nhọn ''<>'' trong mật khẩu. Và tôi có một số lượng mật khẩu đau khổ khiến những suy nghĩ theo dòng "Waddya có nghĩa là tôi không thể sử dụng dấu chấm câu trong mật khẩu của tôi cho trang web thảm hại của bạn?". –

Không có lý do gì cả, ngoại trừ mã hóa DB cẩu thả, nơi họ cho phép văn bản thuần trong DB hoặc sử dụng các hàm DB (không di động) để băm mật khẩu và sử dụng câu lệnh SQL trực tiếp. Điều này có vẻ giống như xác thực chuỗi đồng bằng. Ngoài ra, về mặt thực tế, vị trí đặc biệt trong bàn phím nước ngoài hoặc chật chội là khó khăn và có thể gây phiền toái cho người dùng đang di chuyển (hoặc trong trường hợp thay thế trường hợp hiện đại hơn như bàn phím ảo trên điện thoại thông minh). Một số trang web thậm chí có thể đẩy hệ thống hơn nữa bằng cách cung cấp bàn phím ảo trên màn hình của họ để đăng nhập (với nhiều sự xáo trộn khác nhau).

Không cho phép các ký tự đặc biệt giúp QA và giảm sự thất vọng của người dùng đa nền tảng.

Và cuối cùng, cho phép một bộ ký tự giới hạn (được coi là an toàn) (không chỉ là dấu chấm câu mà còn có nhiều ký tự ngôn ngữ cụ thể trong Unicode), nhà phát triển cũng có thể tránh sự nhầm lẫn giữa trình duyệt và ứng dụng máy chủ (mã hóa dữ liệu biểu mẫu) không rõ ràng trong tiêu chuẩn và có thể phức tạp trên một số trình duyệt).

Nguồn

2010-10-18 14:08:48 dvhh

Việc cho phép các ký tự đặc biệt không có nghĩa là Yêu cầu ký tự đặc biệt. Nếu người dùng biết rằng họ sẽ đăng nhập vào một hệ thống gây khó khăn cho việc nhập các ký tự này, giải pháp hợp lý là không sử dụng các ký tự đó. – Graham

Trong một worlrd lý tưởng người dùng sẽ biết tất nhiên, nhưng trong một số trường hợp rất chung chung (95% trường hợp), đó có thể là do trang web di động được thêm vào sau hoặc người dùng không biết về bố cục bàn phím nước ngoài trước khi họ đi du lịch ví dụ. – dvhh

Không cho phép một số ký tự nhất định vì * một số * người dùng * có thể * di chuyển đến các trang web * có thể * không làm cho việc nhập chúng trở nên dễ dàng - và những người dùng đó * có thể không biết cách làm việc đó - sẽ rất lạ. –

Không phải là để tránh tất cả có thể SQL injection?

Nguồn

2010-10-18 14:00:05

@Goto, làm thế nào sẽ '.' có nguy cơ cho phép SQL injection? Các từ khóa '--','; ',' ''và SQL sẽ nguy hiểm hơn. – Brad

Tôi nghi ngờ nó '; DROP TABLE Người dùng; - – David

@Goto: Tại sao một'. ' cho phép SQL injection? –

Chúng não chết và sợ dấu chấm câu nói chung - và dấu chấm được tính là dấu chấm câu. Đó là một trường hợp 'thân thiện-lửa' hơn là dấu chấm nguy hiểm. Dash cũng khá vô hại.

Một trong những mối quan tâm là SQL Injection, tất nhiên. Khác là năng lực của lực lượng lập trình.

Nguồn

2010-10-18 14:00:44

Trong các công việc trước đây mà hệ thống của chúng tôi có các yêu cầu như thế này (ví dụ, tôi từng làm việc tại ngân hàng cho phép CHỈ chữ cái và số trong mật khẩu của người dùng), đó thường là vấn đề "đó là hệ thống/tiện ích của bên thứ 3/giải pháp chúng tôi đã mua yêu cầu. " Vì vậy, đôi khi vấn đề "năng lực" trở lại với bất cứ ai quyết định mua nó (thường không phải là lập trình viên) và bất cứ ai họ mua nó. – David

Chase là một trong những công ty đó. Nó bảo vệ tâm trí cách một trang web như Stack Overflow cho phép tôi định cấu hình mật khẩu an toàn hơn trang web * banking * của tôi. * sigh * –

Nếu dấu câu trong mật khẩu trở thành mối quan tâm của SQL injection, ** chúng đang làm sai.** –

-1

Nói chung, thực tiễn không tốt là chỉ giới hạn mật khẩu cho các số và chữ cái. Tuy nhiên, nó giúp bảo vệ mã khỏi "tiêm mã", nơi một hacker truyền một số hướng dẫn như một phần của mật khẩu để truy cập vào hệ thống. Một mật khẩu như `Apple; 'Xóa * khỏi người dùng;"' có thể sẽ gây thiệt hại nếu nhà phát triển không quan tâm đến việc thoát khỏi đầu vào của người dùng.

Một vấn đề khác là việc sử dụng các ký tự đặc biệt có thể gây xung đột trong mã phía sau trang web. Hoặc các ký tự đặc biệt phụ thuộc vào tập hợp/mã hóa ký tự cụ thể được sử dụng trong cơ sở dữ liệu. Các chữ cái như ë, è, ï, î và ì là tất cả các ký tự đặc biệt có thể được sử dụng, nếu được cho phép. Nhưng đôi khi họ cũng bị dịch sai.

Một vấn đề khác là một số người có xu hướng dễ dàng quên mật khẩu của họ, điều này trở nên phức tạp hơn một chút nếu bạn được phép sử dụng các ký tự đặc biệt. Bằng cách hạn chế mật khẩu để kết hợp ít hơn, bạn cũng làm cho mật khẩu dễ nhớ hơn.
Thật không may, nó cũng khiến chúng dễ hack hơn ...

Và thường nó chỉ là một chính sách do quản lý của một số công ty không biết rõ hơn. Hạn chế có thể chỉ là quyết định quản lý, không có giải thích hợp lý nào về quản lý muốn mật khẩu được lưu trữ theo cách đó ...

Nguồn

2010-10-18 14:06:58

Vì vậy, ý chính của nó là, các trang web yêu cầu mật khẩu số thư bởi vì một số nhà phát triển có thể không có phòng thủ được thiết lập trong trường hợp tấn công SQL injection? –

Trên thực tế, nhiều hơn bởi vì họ chỉ sợ các cuộc tấn công tiêm, mặc dù bản thân mã có thể cung cấp sự bảo vệ đầy đủ chống lại những tấn công đó. Để làm cho nó tồi tệ hơn, nó không phải là mã SQL. Nó có thể là mã JavaScript với hy vọng nó được thực thi trên máy chủ. Hoặc mã PHP. Hoặc mã ASP. Hoặc mã ColdFusion. Phụ thuộc vào ngôn ngữ được sử dụng để tạo trang web và tính dễ bị tổn thương đối với các loại tấn công này. –

Mã JavaScript được thi hành trên máy chủ? – dreamlax

Tôi đã làm việc ở một nơi muốn có thể đọc mật khẩu qua điện thoại (đó là cách hỗ trợ được thực hiện). Hỗ trợ mọi người không biết tất cả các tên cho các biểu tượng (băm, bang, đường ống, dấu và/và dấu hoa thị/dấu sao) và các vấn đề khác (bạn có nghĩa là dấu ngoặc vuông nào, báo giá, v.v ...). Vì vậy, họ không cho phép bất kỳ dấu câu nào.

Không phải là một lý do chính đáng (hỗ trợ không nên biết mật khẩu của tôi), nhưng bạn đã không hỏi vì lý do duy nhất tốt :)

Nguồn

2010-10-18 14:31:17 user479383

Đây là lý do chính đáng và bàn phím hợp lệ để loại bỏ một số ký hiệu. Không ai hỗ trợ nên có mật khẩu của bạn, nhưng khi ai đó có thể truy cập chi tiết thanh toán của bạn (số CC, địa chỉ thanh toán), sửa đổi tài khoản của bạn hoặc có quyền truy cập vật lý vào máy của bạn (hoặc máy lưu trữ nội dung/dịch vụ của bạn), bạn ' đã tin tưởng chúng với nhiều hơn những gì mật khẩu tài khoản của bạn bảo vệ. Điều đó nói rằng, hầu hết các trang web không bao giờ cần phải làm điều này, bởi vì tương tác qua điện thoại hoặc trong người là một cực kỳ hiếm. –

(Tôi có nên đề cập đến bạn không bao giờ nên sử dụng cùng một mật khẩu ở nhiều nơi không?) –

@Roger Pate: Tôi sử dụng một hệ thống tốt nơi cơ thể trung tâm của mật khẩu giống nhau, nhưng chi tiêu khác nhau theo trang web. Hoạt động rất tốt và nghi ngờ bất cứ ai sẽ nhận thấy một mô hình ngay lập tức. –

Về chữ hoa/thấp: nếu bạn lưu trữ mật khẩu trong văn bản đơn giản, sau đó đó có thể là một vấn đề. Tôi không chắc chắn về Oracle, nhưng SqlServer coi 'Mật khẩu' và 'passWORD' là giống hệt nhau.

Nếu bạn lưu trữ mật khẩu dưới dạng băm, thì vỏ của tài liệu gốc không phải là vấn đề: mật khẩu sẽ phân biệt chữ hoa chữ thường.

Nguồn

2010-10-18 15:49:17

Cảm ơn bạn đã không biết điều đó. –

Có không lý do có thể. Họ chỉ là không đủ năng lực. Bất kỳ mối quan tâm về SQL injection hoặc bất cứ điều gì khác chỉ là sai. Điều đó chỉ cho bạn biết rằng họ đang lo lắng về việc tiêm bảo mật có thể bởi vì họ không băm hoặc mã hóa mật khẩu của bạn.

Nguồn

2010-10-18 16:16:02

Có những mối quan tâm khác ngoài kỹ thuật. Xem chú thích user479383 để biết ví dụ. Nói chung, bạn đang đưa ra một tuyên bố chung cần chứng minh, không chỉ là ví dụ cho các trường hợp mà người ta có thể nghĩ ra. – egaga

OWASP khá rõ ràng về chủ đề. Phần đầu tiên của mình hướng dẫn tại OWASP Passwood Storage Cheat Sheet là:

Đừng giới hạn các ký tự đặt và thiết lập độ dài tối đa dài cho credentials Một số tổ chức hạn chế 1) loại ký tự đặc biệt và 2) chiều dài của các thông tin được chấp nhận bởi hệ thống vì của họ không có khả năng ngăn chặn SQL Injection, Cross-site scripting, command-injection và các hình thức tấn công tiêm khác. Những hạn chế này, trong khi có ý định tốt, tạo điều kiện cho các cuộc tấn công đơn giản nhất định như sức mạnh vũ phu.

Không cho phép mật khẩu ngắn hoặc không có độ dài và không áp dụng bộ ký tự hoặc hạn chế mã hóa khi nhập hoặc lưu trữ bằng chứng xác thực. Tiếp tục áp dụng mã hóa, thoát, che mặt, bỏ sót hoàn toàn và các phương pháp hay nhất khác để loại bỏ nguy cơ tiêm.

Độ dài mật khẩu dài hợp lý là 160. Chính sách mật khẩu rất dài có thể dẫn đến DOS trong một số trường hợp nhất định 1.

Nguồn

2015-12-09 18:55:13 ssabey

Có lý do nào khiến một số trang web không cho phép dấu chấm trong mật khẩu không?

Trả lời

Các vấn đề liên quan