Đây là hành trình 13 năm dẫn đến , một cách tiếp cận khác để quản lý mật khẩu. Đây là bài viết [0] của bài viết.length == 2. Neulock Phần I Nó quay trở lại năm 2011. vẫn là chất liệu điện ảnh; mọi người giao tiếp bằng cách sử dụng khuôn mặt vẽ nguệch ngoạc đơn sắc thay vì Pepe the Frog và Shiba Inu doges, và Daenerys Targaryen là cô bé đã khiến Khal Drogo man rợ tìm thấy tình yêu. Sự lây lan Đó là lần đầu tiên Google Chrome đưa ra lời đề nghị đó. Bạn có muốn Google Chrome lưu mật khẩu của bạn cho trang web này không? Lưu mật khẩu này? Đó có phải là điều mà các trình duyệt hiện đang làm không? Wow, cảm ơn Chrome, thật tiện lợi! Nghĩ mà xem, tôi gõ hầu hết mật khẩu trên trình duyệt web, vì vậy đây có vẻ là một nơi tuyệt vời để lưu chúng. Ngoài ra, điều tồi tệ nhất có thể xảy ra là gì? Chrome là một chương trình được cài đặt trên máy tính của tôi. Máy tính ! Tôi là một người dùng Debian Linux dày dạn kinh nghiệm và không nơi nào trên thế giới này an toàn hơn ổ cứng của tôi! của tôi Chắc chắn rồi, Chrome, hãy tiếp tục. Lưu mật khẩu này, mật khẩu tiếp theo và mọi mật khẩu tôi nhập vào trường nhập của bạn. Lừa dối Cho đến khi tôi mua một chiếc máy tính khác. Sau khi bỏ Windows được cài đặt sẵn để chuyển sang bất kỳ bản phân phối Linux nào mà tôi yêu thích vào thời điểm đó, điều tiếp theo cần làm là cài đặt Chrome. Firefox Quantum vẫn còn sáu năm nữa mới ra mắt nên không có nhiều sự lựa chọn. Đăng nhập bằng tài khoản Google của bạn? Chắc chắn rồi, tại sao không? Hãy kiểm tra Facebook hoặc bất cứ thứ gì và… này, bạn có nhớ tên người dùng của tôi không, Chrome? Được rồi, hãy đăng nhập vào Facebook. Đợi đã, tại sao trường mật khẩu lại được điền bằng dấu hoa thị? Không, Chrome thân mến, đây chắc chắn là lỗi, tôi mới mua máy tính này, cơ sở dữ liệu cục bộ của bạn vẫn nguyên vẹn. Bạn sẽ nhận ra sai lầm của mình khi tôi nhấp vào nút đăng nhập. Và… tôi tham gia? Tôi đã đi kiểm tra cài đặt Chrome ngay lập tức. Những gì tôi nhìn thấy chỉ làm tăng thêm nỗi kinh hoàng của tôi. Tất cả các trang web và tên người dùng tôi đã lưu đều ở đó, trong một danh sách. Mật khẩu văn bản gốc chỉ cách bạn một cú nhấp chuột. Hai kỳ vọng đã bị phá vỡ. Điều đầu tiên và quan trọng nhất là tôi chưa bao giờ mong đợi Chrome tải mật khẩu của tôi lên máy chủ của Google mà không xin phép. Họ yêu cầu tôi mật khẩu của mình, không chia sẻ chúng! lưu Kỳ vọng thứ hai là mơ tưởng của tôi. Thật xấu hổ cho tôi. Google là một trong những công ty công nghệ tuyệt vời nhất trên thế giới và các kỹ sư của họ được cho là những thiên tài làm được những điều không thể giữa các trận đấu bóng bàn tại Googleplex. Tôi nghĩ Chrome đang lưu trữ mật khẩu của tôi theo một cách siêu an toàn nào đó và chỉ truy xuất từng mật khẩu vào đúng thời điểm để đưa mật khẩu đó như một ninja vào trường nhập chính xác nơi mật khẩu đó thuộc về. Tôi không mong đợi được nhìn thấy tất cả chúng ở dạng bản rõ. Và tôi không phải là người duy nhất bị sốc. ”. Trong một cuộc thảo luận sâu hơn, Justin Schuh, giám đốc an ninh của Chrome, với thái độ khá kiêu ngạo. Ngài Tim Berners-Lee đứng về phía Kember, gọi trình quản lý mật khẩu của Chrome là “ ”. Elliott Kember gọi tính năng bảo mật mật khẩu của Chrome là “điên rồ chỉ nhún vai một cách để lấy mật khẩu của chị gái bạn Sau trải nghiệm này, tôi không bao giờ tin tưởng vào bất kỳ trình quản lý mật khẩu nào, mặc dù tôi biết điều đó tốt hơn là nhầm lẫn những mật khẩu kỳ lạ trong đầu con người ngu ngốc của mình. Nhưng, như chúng tôi hay nói ở Brazil, một con chó bị rắn cắn còn sợ cả xúc xích. Nó không có ý nghĩa hơn trong tiếng Bồ Đào Nha. Trình quản lý mật khẩu tốt hơn Tôi đã dành mười năm tiếp theo lang thang trong sa mạc của sự thiếu an toàn về mật khẩu. Tôi đã mong mỏi có một trình quản lý mật khẩu tốt hơn, nhưng tất cả chúng dường như đều tuân theo cùng một nguyên tắc: gói tất cả mật khẩu của bạn vào một “kho tiền”, mã hóa nó bằng khóa chính của bạn và tải kho tiền này lên máy chủ đám mây của họ. Tôi không bao giờ có thể tin tưởng vào mô hình này. Họ đang triển khai mã hóa đầu cuối phải không? Có cửa sau “khôi phục khóa” đang chờ khai thác không? Hoặc có thể Justin Schuh rốt cuộc đã đúng: mật khẩu của bạn được “khôi phục một cách tầm thường” từ bất kỳ ứng dụng nào lưu trữ chúng và những nỗ lực làm cho mật khẩu khó bị rò rỉ hơn “tất cả chỉ là rạp hát”. Theo nghĩa này, việc cố gắng bảo vệ mật khẩu của bạn hơn là tin tưởng vào trình quản lý mật khẩu là một việc làm ngu ngốc của người mới làm quen. Năm 2019, tôi làm việc tại Cục CNTT của Bộ Ngoại giao Brazil. Ở đó, tôi theo dõi CTO và . Tôi đã học được rất nhiều điều từ anh ấy và tiếp quản sau khi anh ấy rời đi. An ninh mạng luôn nằm trong chương trình nghị sự vì Bộ đó sản xuất khoảng 80% tất cả thông tin mật trong chính phủ Liên bang Brazil và hoạt động của nó trải rộng trên 240 địa điểm ở tất cả các lục địa có thể sinh sống được. Chúng tôi liên tục là mục tiêu của những từ viết tắt đáng sợ nhất thế giới, vì vậy chúng tôi cần phải luôn cảnh giác. Trong những năm đó, thông qua việc thường xuyên gặp phải các vấn đề trong các lĩnh vực an ninh mạng khác nhau, tôi bắt đầu tập hợp các nguyên tắc để có một trình quản lý mật khẩu tốt hơn. chuyên gia công nghệ Fabio Cereda Nguyên tắc số 0: tất cả mật mã đều bị phá vỡ hoặc cuối cùng sẽ bị phá vỡ Nơi tôi làm việc có một bảo tàng về truyền thông ngoại giao. Nó chứa đầy sách mã, máy mật mã bằng gang, ăng-ten đĩa di động, bộ chuyển đổi TELEX và một vài mẫu của . Đó là sự thể hiện một thế kỷ rưỡi liên lạc bí mật giữa trụ sở chính với các đại sứ quán và cơ quan ngoại giao Brazil ở nước ngoài. Tất cả họ đều dựa vào một số loại tiền điện tử để nắm giữ bí mật. Tất cả số tiền điện tử đó hiện đã bị hỏng. chiếc máy Crypto AG C-52 khét tiếng Nếu bạn nghĩ về một trình quản lý mật khẩu, thì việc tất cả tiền điện tử cuối cùng sẽ bị phá vỡ không có gì đáng sợ. Giả sử trung bình phải mất 15 năm để phá vỡ một giao thức mật mã. Chỉ cần thay đổi mật khẩu của bạn vài năm một lần và bạn sẽ ổn thôi. Một trình quản lý mật khẩu phù hợp thỉnh thoảng nên nâng cấp tiền điện tử của mình để bạn luôn dẫn đầu. Điều đáng sợ là không thể biết liệu một giao thức đã bị hỏng hay chưa. Hoặc tệ hơn, nếu nó được thiết kế với một lỗ hổng cố ý, ẩn giấu, như trường hợp của máy Crypto AG. Các cơ quan tình báo và các tổ chức tội phạm mạng sẽ giữ bí mật về các ngày số 0 của họ lâu nhất có thể. Càng thấy các hệ thống bảo mật cấp công ty, thế hệ cuối rò rỉ thông tin bí mật, đôi khi theo cách ngoạn mục đến mức thảm khốc, tôi càng ít tin tưởng vào mô hình vault được sử dụng bởi tất cả các trình quản lý mật khẩu dựa trên đám mây. Cho đến rất gần đây, những lo ngại này chỉ mang tính lý thuyết. Như , đồng nghiệp hackernooner @hossam26644 đã viết Không có gì sai khi sử dụng trình quản lý mật khẩu của Google, Microsoft, Apple, 1password, Bitwarden hoặc bất cứ thứ gì. Mọi người đã sử dụng chúng từ lâu và không có vấn đề gì cho đến nay. Anh ấy đã đúng vào ngày 25 tháng 7 năm 2022. Tuy nhiên, anh ấy không tin tưởng bất kỳ ai trong số họ và anh ấy lại đúng một lần nữa. Một năm sau, có bằng chứng thuyết phục cho thấy và mọi người mất tiền. Hơn 150 người, hơn 35 triệu USD tiền mặt. vụ rò rỉ LastPass khét tiếng đã khiến một số kho tiền có giá trị cao bị nứt Một quan niệm sai lầm phổ biến là để bẻ khóa một kho tiền được mã hóa, bản thân cần phải bị xâm phạm. LastPass đã nhắc nhở chúng ta việc phá mã hóa dễ dàng hơn nhiều như thế nào. AES rất mạnh mẽ, nhưng LastPass đã đưa ra những quyết định triển khai kém: yêu cầu khóa chính quá ngắn, quá ít lần lặp lại và một số người dùng bị bỏ lại với các kho tiền có thể dễ dàng bị bẻ khóa bằng vũ lực. thuật toán AES Nguyên tắc số 1: Hậu cần thường là mắt xích an ninh yếu nhất Các nhà giải mã của chính phủ biết rất rõ Nguyên tắc số 0. Họ là một trong những người thông minh nhất mà tôi từng gặp, và rất ít người trong số họ bỏ tiền vào thứ gì đó được bảo vệ bằng mật mã. Những người cảnh giác nhất trong số họ nhất quyết yêu cầu sử dụng để liên lạc cực kỳ an toàn. Trên thực tế, họ đã đưa yêu cầu này vào quy định về truyền và lưu trữ các tài liệu tuyệt mật. Bảng ghi nhớ một lần (OTP) Về nguyên tắc, mật mã OTP không thể bị phá vỡ. Đó là một phép toán XOR đơn giản của bản rõ (dữ liệu) và bộ đệm gồm các giá trị ngẫu nhiên có cùng độ dài với dữ liệu (khóa OTP). Bằng cách XOR mật mã dựa vào cùng một khóa một lần nữa, bản rõ sẽ được phục hồi. Mặc dù không thể phá vỡ được từ quan điểm phân tích mật mã, OTP có một số bất tiện: Mỗi khóa OTP không bao giờ có thể được sử dụng lại; Khóa OTP ít nhất phải dài bằng văn bản gốc; Khóa này có tính đối xứng và phải được chia sẻ trước giữa bên gửi và bên nhận. Đối với một tổ chức trên toàn thế giới, việc cung cấp khóa OTP cho mọi văn phòng là một hoạt động hậu cần quy mô lớn đang diễn ra. Tệ hơn nữa, đó là gót chân Achilles của toàn bộ mô hình bảo mật! Bởi vì, để tất cả tính chất tuyệt vời của tiền điện tử OTP trở thành hiện thực, bạn cần có dịch vụ hậu cần , cả trong quá trình vận chuyển và khi lưu trữ. hoàn hảo Eve có nên chặn khóa OTP của bạn khi đang trên đường đến đích không? Tất cả thông tin liên lạc của bạn kể từ thời điểm đó trở đi đều bị xâm phạm. Eve có nên đột nhập phòng an toàn của bạn và đánh cắp phương tiện khóa OTP của bạn không? Tất cả các liên lạc của bạn kể từ thời điểm đó trở đi đều bị xâm phạm và thậm chí có thể cả những liên lạc trước đó của bạn, nếu các phần đã sử dụng của khóa không được xóa khỏi phương tiện một cách thích hợp. Nếu bạn triển khai các khóa OTP dưới dạng các khối byte ngẫu nhiên có dung lượng 1 GB được sử dụng khi bạn gửi thông tin thì rõ ràng là nó thiếu cả tính bảo mật và lùi. tiến Cuối cùng, tiền điện tử hoàn hảo là một cách để chuyển trách nhiệm từ nhóm an ninh mạng sang nhóm bảo mật vật lý. Và một vấn đề tương tự ảnh hưởng đến các trình quản lý mật khẩu ngoại tuyến: chúng đánh đổi tính khả dụng để lấy tính bảo mật, khiến bạn gặp rắc rối về mặt hậu cần để giải quyết. Như bất kỳ ai đang chạy bản sao cục bộ của đều biết, bạn cần sao lưu kho lưu trữ của mình. Bản sao lưu này tốt hơn nên ở bên ngoài trong trường hợp bộ nhớ máy tính của bạn bị hỏng. Bạn cần luôn cập nhật bản sao lưu của mình. Và đảm bảo rằng không ai có quyền truy cập vào nó. Và đừng giữ tất cả chúng trong nhà kẻo chúng trở thành nạn nhân của lũ lụt và hỏa hoạn. Và đừng tải chúng lên Google Drive; nếu không, bạn sẽ không sử dụng trình quản lý mật khẩu ngoại tuyến nữa. Và… KeePass Nguyên tắc số 2: khi thiết bị của người dùng bị xâm phạm, trò chơi sẽ kết thúc Một ngày nọ, sếp gọi cho tôi. Cô ấy muốn chia sẻ một bản PDF với mười người ở cấp trên. Thông tin này chỉ nên lưu lại trong mắt họ trong ba ngày. Cô biết rằng họ có động cơ chia sẻ tài liệu này với các nhóm tương ứng của mình để có được khởi đầu thuận lợi. Loại thông tin này lẽ ra phải được trình bày trực tiếp, nhưng lại có tính chất Covid. Vì vậy, cô ấy yêu cầu tôi làm cho bản PDF này không thể sao chép và chia sẻ được. - Không thể được, tôi đáp. Sếp của tôi là một Đại sứ. Đây là cấp bậc ngoại giao tương đương với một vị tướng. Các đại sứ không quen nghe câu trả lời “không”. Tôi kiên nhẫn giải thích rằng, trong khoa học máy tính, khi bạn cấp cho ai đó quyền đọc một tài nguyên, bạn ngầm cho phép họ sao chép và phân phối. Quyền truy cập thông tin không tuân theo các quyền hợp pháp. Ngay cả khi chúng tôi bằng cách nào đó khiến việc chia sẻ tệp trở nên bất tiện, họ vẫn có thể chụp ảnh màn hình bằng điện thoại và chia sẻ chúng qua WhatsApp. Nếu họ có thể nhìn thấy tài liệu trên màn hình thì máy ảnh của họ cũng vậy. Justin Schuh đã đúng. Nếu ai đó có toàn quyền truy cập vào máy tính (hoặc điện thoại) của bạn, họ có toàn quyền truy cập vào thông tin mà bạn, người dùng, có thể truy cập thông qua thiết bị đó. Anh ấy đúng, nhưng điều đó không bào chữa cho việc anh ấy triển khai trình quản lý mật khẩu tệ hại như vậy trên Chrome. Đối với một trình quản lý mật khẩu, điều đó có nghĩa là việc bảo vệ thiết bị của người dùng luôn là điều quan trọng. Nếu máy chủ bị rò rỉ, những kẻ tấn công vẫn cần phải vượt qua thử thách bẻ khóa kho tiền. Nhưng nếu tin tặc giành được quyền sở hữu hoàn toàn đối với máy tính đang chạy ứng dụng khách quản lý mật khẩu thì không có gì có thể ngăn cản chúng đánh cắp tất cả mật khẩu. Điều này xảy ra khá thường xuyên trong cộng đồng tiền điện tử. Người dùng Alice có vài chục BTC, điều này khiến cô ấy trở thành triệu phú. Cô ấy đã bị lừa hoặc chưa bao giờ che giấu danh tính của mình ngay từ đầu. Cô ấy giữ một bản sao của cụm từ hạt giống của mình trong trình quản lý mật khẩu cục bộ trên máy tính để bàn của mình. “Đây không phải là trình quản lý mật khẩu đám mây; Tôi an toàn không bị rò rỉ,” cô nghĩ. Hacker tìm cách bắt cô cài đặt backdoor vào máy tính của mình. Nếu họ thực sự giỏi, họ có thể làm điều này mà không cần sự tương tác của người dùng. Sáng hôm sau, cô thức dậy với chiếc ví trống rỗng. Đối với tất cả những điều tồi tệ và u ám về sự xâm phạm thiết bị của người dùng, có một điều may mắn: việc bảo vệ thiết bị của chính chúng ta, với tư cách là người dùng, là điều nằm trong tầm kiểm soát của chúng ta. Một rò rỉ máy chủ thì không. Hơn 150 người đã mất hàng triệu đô la do vụ rò rỉ máy chủ LastPass không chịu trách nhiệm về vụ rò rỉ hoặc việc LastPass thực hiện các tiêu chuẩn mã hóa không đầy đủ. Nếu việc xâm phạm thiết bị của người dùng là một vectơ tấn công thảm khốc bất kể mô hình bảo mật của trình quản lý mật khẩu và nếu chúng ta, với tư cách là người dùng, vẫn phải bảo vệ thiết bị của mình thì sẽ tốt hơn nếu đây là vectơ tấn công ? Nếu chúng ta có thể xây dựng một trình quản lý mật khẩu nơi không có bí mật nào rời khỏi thiết bị người dùng để người dùng không cần phải lo lắng về những thứ ngoài tầm kiểm soát của họ, như bảo mật máy chủ và chi tiết triển khai AES? duy nhất trực tuyến Nguyên liệu ở trên bàn Đồng tác giả @hossam26644 tiếp tục : “có thể tôi là người yêu thích bảo mật, nhưng tôi không muốn tin tưởng giao mật khẩu của mình cho một thực thể, bất kể lời hứa và/danh tiếng của họ”. Anh ấy lại đúng nữa. An ninh mạng được cho là phải được chứng minh và kiểm tra, không dựa trên sự tin cậy và danh tiếng. trong bài viết của mình Ba nguyên tắc nêu trên đã hướng dẫn tôi phát triển . Tôi đã mất ba năm lên ý tưởng và lặp đi lặp lại để có được hình thức hiện tại: một trình quản lý mật khẩu dựa trên đám mây có thể kiểm tra được, đạt được kiến thức bằng không nhờ thiết kế chứ không phải thông qua mã hóa. Mật khẩu được đồng bộ hóa trên các thiết bị của người dùng bằng đám mây nhưng không có bí mật nào được lưu giữ trên các thiết bị này. Sự xâm phạm máy chủ đám mây không thể rò rỉ bất kỳ bí mật nào vì bí mật không bao giờ đến được đám mây. Trình quản lý mật khẩu Neulock Ba năm chế tạo Neulock sẽ được ghi lại trong Phần II.

This story contains new, firsthand information uncovered by the writer.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

This post provides insights into new product. 

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Making security fun one episode at a time

Trình quản lý mật khẩu Chrome đã phản bội lòng tin của tôi 13 năm trước Tôi không bao giờ quên.

dài quá đọc không nổi

Lucas Neves

STORY’S CREDIBILITY

Original Reporting

Vested Interest

Product Launch

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

Trình quản lý mật khẩu Chrome đã phản bội lòng tin của tôi 13 năm trước Tôi không bao giờ quên.

dài quá đọc không nổi

Lucas Neves

STORY’S CREDIBILITY

Original Reporting

Vested Interest

Product Launch

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

NHỮNG BÀI VIẾT LIÊN QUAN