Đặt lại mật khẩu danh tính số
- Nếu bạn quên mật khẩu sau khi đã kích hoạt danh tính số, bạn có thể đặt lại mật khẩu thông qua trang này.
- Bạn phải nhập thông tin cá nhân vào biểu mẫu bên dưới và cần biết tên người dùng của mình.
- Tên người dùng có dạng tương tự địa chỉ email, ví dụ như jn1234@student.uni-lj.si.
- Nếu bạn quên cả tên người dùng lẫn mật khẩu, bạn cần liên hệ bộ phận hỗ trợ của trường đại học.
Nhập thông tin cá nhân
- Cần có thông tin cá nhân để tìm danh tính số trong cơ sở dữ liệu.
- Bắt buộc phải nhập tên, họ, ngày sinh, ID sinh viên và khoa trực thuộc.
- Phần chọn khoa có nhiều lựa chọn như Học viện Mỹ thuật và Thiết kế, Học viện Âm nhạc, Học viện Sân khấu, Phát thanh, Điện ảnh và Truyền hình.
Thiết lập tên người dùng và mật khẩu mới
- Tên người dùng có dạng giống địa chỉ email; ví dụ, tên người dùng của John Smith là js1234@student.uni-lj.si.
- Bạn nên chọn một mật khẩu mạnh và có thể nhớ được, đồng thời tránh các mật khẩu dễ đoán.
- Mật khẩu phải có ít nhất 10 ký tự, không chứa tên của bạn và đáp ứng 3 trong các tiêu chí sau: chữ hoa tiếng Anh, chữ thường tiếng Anh, chữ số, ký tự đặc biệt (-_.+@).
- Mật khẩu không được chứa các tổ hợp ký tự như script, select, insert, update, delete, drop, --, ', /*, */.
- Bạn phải nhập mật khẩu hai lần để tránh lỗi gõ nhầm.
Ý kiến của GN⁺
- Trang này giúp những người dùng đã quên mật khẩu danh tính số có thể dễ dàng đặt lại mật khẩu.
- Các quy tắc thiết lập mật khẩu mạnh đóng vai trò quan trọng trong việc bảo vệ thông tin số của người dùng.
- Quy trình liên hệ bộ phận hỗ trợ của trường đại học khi quên tên người dùng và mật khẩu cung cấp cho người dùng một kênh để nhận thêm trợ giúp.
1 bình luận
Ý kiến trên Hacker News
Câu chuyện của một nhà phát triển cho biết anh ấy đã thêm một chuỗi cụ thể theo yêu cầu của quản trị viên. Trang web đó không lưu mật khẩu mà cung cấp giao diện cho hệ thống quản lý tài khoản bên ngoài. Có tin đồn rằng trong các ứng dụng legacy có thể tồn tại kiểu xác thực kỳ lạ khiến không thể đăng nhập bằng mật khẩu chứa một số chuỗi nhất định, nhưng không biết ví dụ cụ thể nào.
Chuyện kể về thời nhỏ từng hack một nền tảng mạng xã hội lớn. Bằng cách lợi dụng cơ chế chỉ đơn giản xóa các từ bị cấm, người này đã chèn được thẻ HTML hợp lệ và kiểm soát những ai truy cập trang.
Có ý kiến cho rằng trong một số trường hợp, các yêu cầu như vậy là ý tưởng tốt. Nhiều người viết code và kiến trúc hệ thống tệ hại, trong khi lại thiếu người có đủ năng lực, quyền hạn trong tổ chức và thời gian để phát hiện vấn đề và buộc phải thay đổi. Ở Mỹ, doanh nghiệp có thể vẫn phải vận hành trên những website được lập trình rất kém. Trong trường hợp đó, có lẽ tốt hơn là giả định việc triển khai sẽ tệ như thường thấy và khuyến nghị các biện pháp giảm thiểu tương ứng.
Chỉ trích cách tiếp cận hạn chế vài từ khóa rồi hy vọng hacker sẽ không nghĩ ra cách khác, thay vì dùng stored procedure và kỹ thuật phù hợp để ngăn chặn hoàn toàn SQL injection. Đây đâu còn là năm 2005 nữa; việc không để đầu vào của người dùng trộn lẫn với SQL không còn là chuyện quá cao siêu. Còn việc lưu mật khẩu mà không mã hóa thì ngay cả năm 2005 cũng đã là điều ngu ngốc.
Có bình luận nói sẽ dùng
truncatethay thế.Ý kiến cho rằng chuyện này có vẻ bắt nguồn từ các hệ thống cũ. Một số trường đại học và ngân hàng dùng hệ thống mainframe cũ cho xác thực tập trung, và có nơi lưu mật khẩu dạng văn bản thuần, giới hạn 8 ký tự và chỉ cho chữ in hoa. Lý do chính không nâng cấp hệ thống là chi phí và độ phức tạp.
Trải nghiệm của một sinh viên cho thấy không phải mọi chuỗi bị cấm đều được kiểm tra.
Câu chuyện của một người nói rằng trong công việc họ đã phải đặt ra những yêu cầu như thế này. Dù phải escape mọi chuỗi đúng cách và dùng parameterized query để tránh tấn công SQL injection, nhưng để phòng thủ nhiều lớp, họ vẫn cho rằng nên từ chối ở mọi trường dữ liệu những đoạn trông giống SQL hoặc HTML.
Một bình luận đầy tự tin rằng mật khẩu của mình chắc chắn sẽ không bao giờ bị chặn.
Phỏng đoán lạc quan rằng các yêu cầu kiểu này có thể xuất phát từ một WAF (tường lửa ứng dụng web) hoạt động quá mức nhiệt tình.