Cuối cùng thì có lẽ cách thực tế là dùng mật khẩu được tạo ngẫu nhiên và quản lý bằng trình quản lý mật khẩu có hỗ trợ những phương thức như 2FA.
Tôi đang dùng vaultwarden trên máy chủ homelab.
Tôi khá hoài nghi về kiểu quyết định mật khẩu thông qua việc suy ra (derivation) như thế này. Bối cảnh quan trọng nhất của việc dùng trình quản lý mật khẩu có lẽ là dù bản thân có làm tốt đến đâu thì cũng không thể biết dịch vụ nào sẽ gặp sự cố rò rỉ, và nếu vậy thì khi sự cố rò rỉ xảy ra, cần phải có khả năng loại bỏ mật khẩu cũ và tạo lại một mật khẩu hoàn toàn mới. Có vẻ như với cách suy ra thì điều đó khá khó.
Tất nhiên có thể nhớ số lần đây là mật khẩu được suy ra và tạo ra lần thứ mấy, rồi đưa cả số lần đó vào quá trình suy ra, nhưng như vậy thì con người lại phải nhớ ở mỗi dịch vụ mình đã đổi mật khẩu bao nhiêu lần.
Vì vậy, tôi dùng một cách tạm thời là đưa giá trị năm hoặc tháng hiện tại vào quy tắc suy ra mật khẩu mà cá nhân tôi sử dụng.
Do hệ thống công việc có quy định phải đổi mật khẩu đăng nhập mỗi 1 tháng, nên nếu không dùng cách suy ra mật khẩu thì tôi chẳng thể nhớ nổi việc phải đổi mỗi lần. Cũng không thể quay lại dùng mật khẩu đã dùng trước đó, nên đằng nào cũng phải đổi hàng tháng, tôi bèn tạo đại một quy tắc suy ra có kèm thông tin năm-tháng để dùng.
Tôi cũng từng làm tương tự vì quy tắc cửa ra vào ở chỗ làm trước đây bắt buộc phải đổi mỗi tháng. Nhưng chỉ có 4 chữ số...
2 số cuối của năm và 2 số của tháng, lấy 2 số cuối của tích và 2 số cuối của tổng
vd) tháng 03 năm 2023: tích 69, tổng 26 -> 6926
Ban đầu trông có vẻ hay, nhưng tôi đã ngạc nhiên khi thấy nói rằng nếu muốn đổi mật khẩu thì phải đổi cả tên người dùng (thường có lẽ là ID…). Nghĩ lại theo cách hoạt động của nó thì đúng là điều hiển nhiên.
6 bình luận
Cũng có lesspass.com như một dạng nguyên bản.
Cuối cùng thì có lẽ cách thực tế là dùng mật khẩu được tạo ngẫu nhiên và quản lý bằng trình quản lý mật khẩu có hỗ trợ những phương thức như 2FA.
Tôi đang dùng vaultwarden trên máy chủ homelab.
Tôi khá hoài nghi về kiểu quyết định mật khẩu thông qua việc suy ra (derivation) như thế này. Bối cảnh quan trọng nhất của việc dùng trình quản lý mật khẩu có lẽ là dù bản thân có làm tốt đến đâu thì cũng không thể biết dịch vụ nào sẽ gặp sự cố rò rỉ, và nếu vậy thì khi sự cố rò rỉ xảy ra, cần phải có khả năng loại bỏ mật khẩu cũ và tạo lại một mật khẩu hoàn toàn mới. Có vẻ như với cách suy ra thì điều đó khá khó.
Tất nhiên có thể nhớ số lần đây là mật khẩu được suy ra và tạo ra lần thứ mấy, rồi đưa cả số lần đó vào quá trình suy ra, nhưng như vậy thì con người lại phải nhớ ở mỗi dịch vụ mình đã đổi mật khẩu bao nhiêu lần.
Vì vậy, tôi dùng một cách tạm thời là đưa giá trị năm hoặc tháng hiện tại vào quy tắc suy ra mật khẩu mà cá nhân tôi sử dụng.
Do hệ thống công việc có quy định phải đổi mật khẩu đăng nhập mỗi 1 tháng, nên nếu không dùng cách suy ra mật khẩu thì tôi chẳng thể nhớ nổi việc phải đổi mỗi lần. Cũng không thể quay lại dùng mật khẩu đã dùng trước đó, nên đằng nào cũng phải đổi hàng tháng, tôi bèn tạo đại một quy tắc suy ra có kèm thông tin năm-tháng để dùng.
Tôi cũng từng làm tương tự vì quy tắc cửa ra vào ở chỗ làm trước đây bắt buộc phải đổi mỗi tháng. Nhưng chỉ có 4 chữ số...
2 số cuối của năm và 2 số của tháng, lấy 2 số cuối của tích và 2 số cuối của tổng
vd) tháng 03 năm 2023: tích 69, tổng 26 -> 6926
Ban đầu trông có vẻ hay, nhưng tôi đã ngạc nhiên khi thấy nói rằng nếu muốn đổi mật khẩu thì phải đổi cả tên người dùng (thường có lẽ là ID…). Nghĩ lại theo cách hoạt động của nó thì đúng là điều hiển nhiên.