Mật khẩu VPN đã lưu: ai có thể giải mã và khi nào

Một ứng dụng VPN hiển thị mật khẩu đã mã hóa trong XML của nó gần như chưa nói với bạn điều gì. Bản mã chỉ trả lời rằng giá trị không được lưu dưới dạng văn bản thuần trong biểu diễn đó. Ai có thể giải mã, bằng khóa nào và trong ngữ cảnh người dùng nào là những câu hỏi quyết định việc lưu trữ có ích hay không. Hãy trả lời chúng trước khi gọi tệp là an toàn hay không an toàn.

Xác định đối tượng nào được lưu

Bắt đầu từ mô hình lưu trữ đã được tài liệu hóa của sản phẩm. Ứng dụng khách có thể lưu mật khẩu có thể khôi phục, token hoặc tham chiếu đến kho thông tin xác thực, và mỗi loại có mức phơi nhiễm khác nhau. Tên phần tử XML không phải là thiết kế, và một chuỗi trông giống base64 cũng không phải bằng chứng của mã hóa.

Hỏi nhà cung cấp hoặc quản trị viên thành phần nào đọc giá trị khi kết nối.

Sau đó xác định API bảo vệ nếu có tài liệu. Trên Windows, CryptProtectData bảo vệ dữ liệu bằng khóa dẫn xuất từ thông tin đăng nhập của người dùng đang mã hóa, và tùy chọn ở cấp máy thay đổi ai có thể giải mã. Đó là ví dụ cụ thể về lý do phạm vi quan trọng. Đây không phải bằng chứng rằng bất kỳ ứng dụng VPN cụ thể nào dùng API đó.

Tách bản sao bị đánh cắp khỏi việc dùng khi chạy

Ứng dụng khách kết nối lại mà không hỏi bạn cần một cách được hỗ trợ để khôi phục thông tin xác thực. Bảo vệ bản sao lưu không loại bỏ khả năng đó. Bất kỳ chương trình nào chạy trong đúng ngữ cảnh người dùng đều có thể dùng cùng đường dẫn, vì thế bản thân điểm cuối nằm trong ranh giới tin cậy. Quyền tệp và đặc quyền tiến trình thu hẹp ranh giới đó; chúng không loại bỏ nó.

Chính sự khác biệt này là điều một tuyên bố về tệp ngoại tuyến thường hiểu sai. Mã hóa khi lưu trữ có thể chặn người sao chép một tệp mà không có tài khoản. Nó không chặn mã chạy dưới danh nghĩa tài khoản đó.

Cả hai phát biểu có thể cùng đúng, và phát biểu thứ hai mới là điều quan trọng khi ứng phó sự cố.

Đọc các kiểm soát truy cập thực sự áp dụng

Kiểm tra ACL của tệp và thư mục phía trên, không chỉ chế độ tệp. Trên Windows, so sánh quyền hiệu lực của hồ sơ người dùng với quyền của dịch vụ hoặc tác vụ theo lịch của ứng dụng khách. Một bí mật được bảo vệ cho một người dùng không tự động được bảo vệ khỏi quản trị viên, và cũng không tự động lộ ra cho quản trị viên.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Ghi lại danh tính nào chạy ứng dụng khách, vì danh tính đó là chủ thể của việc giải mã.

Với một đội thiết bị được quản lý, kiểm soát phù hợp có thể là quản lý thiết bị thay vì tệp. Hỏi xem thông tin xác thực có được ký gửi không, có thể thu hồi từ xa không và quy trình ra sao khi mất thiết bị.

Lập kế hoạch cho phơi nhiễm thay vì thử nghiệm giải mã

Đừng chạy một công cụ trích xuất lạ trên tệp để chứng minh một quan điểm. Nó có thể hiệu quả, có thể làm hỏng hồ sơ, và dù thế nào cũng thay đổi bằng chứng. Hãy dùng thiết kế đã được tài liệu hóa và một đánh giá được ủy quyền nếu thực sự cần xác minh.

Nếu đã xác định phơi nhiễm, hãy xoay thông tin xác thực tại chủ sở hữu danh tính.

Xóa mục đã lưu không phải là thu hồi. Nó có thể ngăn ứng dụng đó cung cấp lại giá trị, và không làm gì với bản sao đã bị lấy hoặc phiên đã được cấp quyền. Hãy thay thông tin xác thực, kết thúc các phiên mà chủ sở hữu có thể kết thúc, và ghi lại điều gì đã được xoay và khi nào.

Các câu hỏi cho một lần đánh giá nhà cung cấp

Hỏi bí mật nào được lưu, thành phần nào dùng nó, khóa người dùng hay khóa máy nào bảo vệ nó, những kiểm soát truy cập nào áp dụng cho việc dùng thông thường và bản sao lưu, và chính sách lưu cùng việc vô hiệu hóa từ xa được xử lý ra sao. Năm câu trả lời đó mô tả thiết kế; XML thì không.

Giữ các câu trả lời cùng hồ sơ triển khai để người đánh giá tiếp theo không lặp lại bài tập này.

Thông tin xác thực đã lưu là một sự đánh đổi giữa tiện lợi và phơi nhiễm. Hãy thực hiện sự đánh đổi đó một cách có chủ đích và ghi lại ai đã chấp nhận nó.