이것은 비밀번호 관리에 대한 다른 접근 방식인 탄생시킨 13년의 여정입니다. 여기에 Articles.length == 2의 기사[0]가 있습니다. Neulock을 1부 2011년의 일이었습니다. 여전히 영화 소재였습니다. 사람들은 개구리 페페와 시바견 대신 단색의 낙서 얼굴을 사용하여 소통했고, 대너리스 타르가르옌은 야만적인 칼 드로고가 사랑을 찾게 만든 어린 소녀였습니다. 컨테이젼(Contagion)은 Google Chrome이 처음으로 이러한 제안을 한 것은 바로 그때였습니다. Chrome이 이 사이트의 비밀번호를 저장하도록 하시겠습니까? 이 비밀번호를 저장하시겠습니까? 그게 브라우저가 지금 하는 일인가요? 와, 고마워요, 크롬, 정말 편리해요! 그러고 보니 대부분의 비밀번호는 웹브라우저에서 입력하는데, 이곳에 비밀번호를 저장해두면 참 좋을 것 같습니다. 게다가 일어날 수 있는 최악의 상황은 무엇입니까? Chrome은 내 컴퓨터에 설치된 프로그램입니다. 컴퓨터! 저는 노련한 Debian Linux 고급 사용자이고, 우주 어디에도 내 하드 드라이브보다 안전한 곳은 없습니다! 내 물론이죠, Chrome을 이용해 보세요. 이 비밀번호와 다음 비밀번호, 그리고 입력 필드에 입력하는 모든 비밀번호를 저장하세요. 기만 다른 컴퓨터를 구입할 때까지. 당시 내가 좋아했던 Linux 배포판이 무엇이든 사전 설치된 Windows를 버린 후, 다음으로 해야 할 일은 Chrome을 설치하는 것이었습니다. Firefox Quantum은 아직 6년이나 남았기 때문에 선택의 여지가 많지 않았습니다. Google 계정으로 로그인하시겠습니까? 물론이죠. 왜 안 되나요? 페이스북이든 뭐든 확인해 보자. 그리고… 야, 내 사용자 이름 크롬 기억나? 좋습니다. Facebook에 로그인하겠습니다. 잠깐, 왜 비밀번호 필드가 이미 별표로 채워져 있나요? 아니요, Chrome님, 이건 버그인 게 틀림없어요. 방금 이 컴퓨터를 구입했는데, 로컬 데이터베이스가 깨끗해요. 로그인 버튼을 클릭하면 실수를 깨닫게 될 것입니다. 그리고... 내가 들어가요? 바로 크롬 설정을 확인하러 갔습니다. 내가 본 것은 나의 공포를 더욱 증가시킬 뿐이었습니다. 내가 저장한 모든 웹사이트와 사용자 이름이 목록에 있었습니다. 일반 텍스트 비밀번호는 단 한 번의 클릭만으로 가능했습니다. 두 가지 기대가 깨졌습니다. 첫 번째이자 가장 중요한 것은 Chrome이 동의를 요청하지 않고 내 비밀번호를 Google 서버에 업로드할 것이라고는 전혀 예상하지 못했다는 것입니다. 그들은 나에게 비밀번호를 공유하지 말고 요청했습니다! 저장하라고 두 번째 기대는 나의 희망사항이었습니다. 부끄러워요. Google은 세계에서 가장 멋진 기술 회사 중 하나이며, Googleplex의 엔지니어들은 탁구 경기 사이에 불가능한 일을 해내는 천재라고 알려져 있습니다. 나는 Chrome이 내 비밀번호를 매우 안전한 방식으로 저장하고 적절한 시간에만 각 비밀번호를 검색하여 비밀번호가 속한 정확한 입력 필드에 닌자처럼 삽입한다고 생각했습니다. 나는 그것들을 모두 일반 텍스트로 볼 것이라고 기대하지 않았습니다. 그리고 충격을 받은 사람은 나뿐만이 아니었습니다. . 추가 논의에서 Chrome의 보안 책임자인 Justin Schuh는 다소 오만한 태도로 . Tim Berners-Lee 경은 Kember의 편을 들어 Chrome의 비밀번호 관리자를 " "이라고 불렀습니다. Elliott Kember는 Chrome의 비밀번호 보안이 "미친 수준"이라고 말했습니다 어깨를 으쓱했습니다 언니의 비밀번호를 알아내는 방법 이 경험 이후 나는 어떤 비밀번호 관리자도 신뢰하지 않게 되었습니다. 비록 그것이 어리석은 인간의 머릿속으로 이상한 비밀번호를 만들어내는 것보다 낫다는 것을 알면서도 말입니다. 하지만 브라질에서는 뱀에게 물린 개는 소시지조차 두려워한다고 합니다. 포르투갈어로는 더 이상 의미가 없습니다. 더 나은 비밀번호 관리자 나는 그 후 10년 동안 비밀번호가 불안정한 사막에서 방황했습니다. 나는 더 나은 비밀번호 관리자를 갈망했지만 그들 모두는 동일한 원칙을 따르는 것 같았습니다. 모든 비밀번호를 "볼트"에 묶고 마스터 키로 암호화한 다음 이 볼트를 클라우드 서버에 업로드하는 것입니다. 나는 이 모델을 결코 믿을 수 없었다. 엔드투엔드 암호화를 구현하고 있는 거죠? 악용 대기 중인 "키 복구" 백도어가 있습니까? 아니면 결국 Justin Schuh의 말이 옳았을 수도 있습니다. 귀하의 비밀번호는 비밀번호를 저장하는 모든 애플리케이션에서 "사소하게 복구"되며 비밀번호를 유출하기 어렵게 만들려는 시도는 "모두 연극일 뿐입니다." 이런 의미에서 비밀번호 관리자를 신뢰하는 것 이상으로 비밀번호를 보호하려는 것은 초보 바보의 심부름이었습니다. 2019년에 저는 브라질 외교부 IT부서에 입사했습니다. 그곳에서 저는 CTO이자 섀도잉했습니다. 나는 그에게서 많은 것을 배웠고 그가 떠난 후에 그 일을 이어받았습니다. 부처가 브라질 연방 정부의 모든 기밀 정보 중 약 80%를 생산하고 그 운영이 거주 가능한 모든 대륙의 240개 이상의 위치에 퍼져 있었기 때문에 사이버 보안은 항상 의제였습니다. 우리는 끊임없이 세계에서 가장 무서운 약어들의 표적이 되었기 때문에 항상 경계해야 했습니다. 수년 동안 다양한 사이버 보안 영역의 문제에 지속적으로 노출되면서 저는 더 나은 비밀번호 관리자를 위한 원칙을 정리하기 시작했습니다. 기술 전문가인 Fabio Cereda를 원칙 #0: 모든 암호화는 깨졌거나 결국 깨질 것입니다 제가 일하던 곳에 외교통신박물관이 있었습니다. 그것은 코드북, 주철 암호 기계, 여행 가방에 들고 다닐 수 있는 접시형 안테나, TELEX 어댑터, 그리고 의 표본 몇 개로 가득 차 있었습니다. 이는 본부와 브라질 대사관, 해외 공관 사이의 150년 동안의 비밀 통신을 보여주는 쇼케이스였습니다. 그들 모두는 비밀을 유지하기 위해 일종의 암호화폐에 의존했습니다. 이제 모든 암호화폐가 깨졌습니다. 악명 높은 Crypto AG C-52 기계 비밀번호 관리자에 대해 생각해 보면 모든 암호화폐가 결국 손상될 것이라는 사실은 두렵지 않습니다. 암호화 프로토콜을 깨는 데 평균 15년이 걸린다고 가정해 보겠습니다. 몇 년에 한 번씩 비밀번호를 변경하면 괜찮을 것입니다. 괜찮은 비밀번호 관리자는 때때로 암호화폐를 업그레이드해야 항상 앞서 나갈 수 있습니다. 무서운 부분은 프로토콜이 이미 위반되었는지 여부를 아는 것이 불가능하다는 것입니다. 또는 Crypto AG 시스템의 경우처럼 의도적으로 숨겨진 취약점을 가지고 설계된 경우 더욱 그렇습니다. 정보 기관과 사이버 범죄 조직은 가능한 한 오랫동안 제로데이를 감시합니다. 최신 기업 수준의 보안 시스템이 비밀 정보를 누출하는 것을 더 많이 볼수록, 때로는 치명적인 방식으로, 모든 클라우드 기반 암호 관리자가 사용하는 저장소 모델을 덜 신뢰하게 되었습니다. 아주 최근까지 이러한 우려는 단지 이론적인 것에 불과했습니다. 것처럼, 동료 해커누너 @hossam26644가 쓴 Google의 비밀번호 관리자, Microsoft, Apple, 1password, Bitwarden 등을 사용하는 데에는 아무런 문제가 없습니다. 사람들은 지금까지 아무런 문제 없이 오랫동안 사용해 왔습니다. 2022년 7월 25일에 그의 말이 옳았습니다. 하지만 그는 그들 중 누구도 믿지 않았고, 이번에도 그의 말이 옳았습니다. 1년 후, 사람들이 돈을 잃었다는 강력한 증거가 나타났습니다. 150명 이상이고 돈이 3,500만 달러가 넘습니다. 악명 높은 LastPass 유출로 인해 일부 고가의 금고가 손상되고 일반적인 오해는 암호화된 저장소를 크랙하려면 자체가 손상되어야 한다는 것입니다. LastPass는 암호화를 깨는 것이 얼마나 쉬운지 상기시켜 주었습니다. AES는 강력하지만 LastPass는 구현 결정을 제대로 내리지 못했습니다. 마스터 키 요구 사항이 너무 짧고 반복 횟수가 너무 적으며 일부 사용자에게는 무차별 대입으로 쉽게 크랙할 수 있는 저장소가 남아 있었습니다. AES 알고리즘 원칙 #1: 물류는 가장 취약한 보안 링크인 경우가 많습니다. 정부 암호 분석가들은 원칙 #0을 너무나 잘 알고 있었습니다. 그들은 내가 만난 사람들 중 가장 똑똑한 사람들 중 일부이며, 암호화만으로 보호되는 것에 돈을 투자하는 사람은 거의 없습니다. 그들 중 가장 조심스러운 사람들은 매우 안전한 통신을 위해 사용할 것을 주장했습니다. 실제로 그들은 일급 비밀 문서의 전송 및 보관에 대한 규정에 이 요구 사항을 적용했습니다. 일회용 패드(OTP)를 원칙적으로 OTP 암호는 해독될 수 없습니다. 이는 일반 텍스트(데이터)와 데이터(OTP 키)와 동일한 길이의 임의 값 버퍼의 간단한 XOR 연산입니다. 동일한 키에 대해 암호를 다시 XOR하면 일반 텍스트가 복구됩니다. 암호 분석의 관점에서 보면 해독할 수 없지만 OTP에는 몇 가지 불편한 점이 있습니다. 각 OTP 키는 재사용할 수 없습니다. OTP 키는 최소한 일반 텍스트 길이만큼 길어야 합니다. 키는 대칭적이며 송신측과 수신측 간에 미리 공유되어야 합니다. 전 세계 조직의 경우 모든 사무실에 OTP 키를 제공하는 것은 대규모의 지속적인 물류 작업입니다. 더 나쁜 것은 전체 보안 모델의 아킬레스건입니다! 왜냐하면 OTP의 놀라운 암호화폐 기능이 모두 유효하려면 운송 중과 정지 상태 모두에서 물류가 필요하기 때문입니다. 완벽한 Eve가 목적지로 이동하는 동안 OTP 키를 가로채야 할까요? 그 시점부터 모든 통신이 손상됩니다. Eve가 물리적으로 안전실을 해킹하고 OTP 키 미디어를 훔쳐야 할까요? 해당 시점부터 모든 통신이 손상될 수 있으며, 키의 사용된 부분이 미디어에서 제대로 삭제되지 않은 경우 이전 통신도 손상될 수 있습니다. 정보를 보낼 때 소비되는 1GB의 무작위 바이트 청크로 OTP 키를 구현하는 경우 및 역방향 보안성이 모두 부족합니다. 순방향 결국 완벽한 암호화는 책임을 사이버 보안 팀에서 물리적 보안 팀으로 옮기는 방법입니다. 그리고 유사한 문제가 오프라인 비밀번호 관리자에 영향을 미칩니다. 즉, 가용성과 기밀성을 절충하여 정리해야 할 물류상의 혼란을 초래합니다. 의 로컬 복사본을 실행하는 사람이라면 누구나 알고 있듯이 볼트를 백업해야 합니다. 컴퓨터 저장소가 죽을 경우를 대비해 이 백업은 외부에 백업하는 것이 좋습니다. 백업을 최신 상태로 유지해야 합니다. 그리고 아무도 그것에 접근할 수 없도록 하세요. 그리고 그것들을 모두 집에 두지 마십시오. 홍수와 화재의 희생양이 되지 않도록 하십시오. 그리고 Google 드라이브에 업로드하지 마세요. 그렇지 않으면 더 이상 오프라인 비밀번호 관리자를 사용하지 않습니다. 그리고… KeePass 원칙 #2: 사용자 장치가 손상되면 게임이 종료됩니다. 어느 날 상사가 나에게 전화를 했다. 그녀는 상위 계층의 10명과 PDF를 공유하고 싶었습니다. 이 정보는 3일 동안만 눈에 남아 있어야 합니다. 그녀는 유리한 출발을 위해 이 문서를 해당 팀과 공유할 인센티브가 있다는 것을 알고 있었습니다. 이런 종류의 정보는 직접 제시해야 하지만 코로나19로 인해 발생합니다. 그래서 그녀는 이 PDF를 복사하고 공유할 수 없도록 해달라고 요청했습니다. — 할 수 없습니다라고 대답했습니다. 내 상사는 대사였습니다. 이는 장군과 동등한 외교적 성격을 지닌다. 대사는 "아니오"라는 대답을 듣는 데 익숙하지 않습니다. 나는 컴퓨터 과학에서 누군가에게 리소스에 대한 읽기 권한을 부여하면 암묵적으로 복사 및 배포 권한을 부여하는 것이라고 인내심을 갖고 설명했습니다. 정보 접근 권한은 법적 권리를 따르지 않습니다. 파일을 공유하는 것이 다소 불편하더라도 휴대전화로 화면을 사진으로 찍어 WhatsApp으로 공유할 수 있었습니다. 화면에서 문서를 볼 수 있으면 카메라도 볼 수 있습니다. 저스틴 슈가 옳았습니다. 누군가가 귀하의 컴퓨터(또는 전화)에 대한 전체 액세스 권한을 얻으면 사용자인 귀하가 해당 장치를 통해 액세스할 수 있는 정보에 대한 전체 액세스 권한을 갖게 됩니다. 그의 말이 맞습니다. 하지만 그렇다고 해서 그가 Chrome에 그런 형편없는 비밀번호 관리자를 구현한 것에 대한 변명이 될 수는 없습니다. 비밀번호 관리자의 경우 이는 사용자 장치를 보호하는 것이 항상 중요하다는 것을 의미합니다. 서버가 유출되더라도 공격자는 여전히 금고를 크랙하는 과제를 통과해야 합니다. 그러나 해커가 비밀번호 관리자 클라이언트를 실행하는 컴퓨터에 대한 완전한 소유권을 얻은 경우 모든 비밀번호를 도용하는 것을 막을 수 있는 방법은 없습니다. 이런 일은 암호화폐 커뮤니티에서 자주 발생합니다. 사용자 Alice는 수십 개의 BTC를 보유하고 있어 백만장자가 되었습니다. 그녀는 신상 털기를 당했거나 애초에 자신의 신원을 결코 숨기지 않았습니다. 그녀는 데스크탑의 로컬 비밀번호 관리자에 시드 문구의 사본을 보관합니다. “이것은 클라우드 비밀번호 관리자가 아닙니다. 나는 누출로부터 안전합니다.”라고 그녀는 생각합니다. 해커는 그녀가 컴퓨터에 백도어를 설치하도록 만드는 방법을 찾습니다. 정말 훌륭하다면 사용자 개입 없이도 이를 수행할 수 있습니다. 다음날 아침, 그녀는 빈 지갑을 발견했습니다. 사용자 장치 손상에 대한 모든 불운과 암울함에도 희망은 있습니다. 즉, 사용자로서 우리 자신의 장치를 보호하는 것은 우리가 통제할 수 있는 일입니다. 서버 누출은 아닙니다. LastPass 서버 유출로 인해 수백만 달러를 잃은 150명 이상의 사람들은 유출이나 LastPass의 부적절한 암호화 표준 구현에 대해 책임을 지지 않습니다. 사용자 장치 손상이 비밀번호 관리자 보안 모델에 관계없이 치명적인 공격 벡터이고 사용자로서 어쨌든 장치를 보호해야 한다면 이것이 공격 벡터라면 좋지 않을까요? 서버 보안 및 AES 구현 세부 사항과 같이 사용자가 통제할 수 없는 사항에 대해 걱정할 필요가 없도록 어떤 비밀도 사용자 장치에 남지 않는 비밀번호 관리자를 구축할 수 있다면 어떨까요? 유일한 온라인 재료가 테이블 위에 있어요 동료 저자인 @hossam26644는 덧붙였습니다. "아마도 나는 보안에 광적인 사람일지도 모르지만, 나는 그들의 약속이나 평판에 상관없이 내 비밀번호를 특정 단체에 맡기고 싶지 않습니다." 그가 또 옳았어. 사이버 보안은 신뢰와 평판을 기반으로 하는 것이 아니라 입증되고 감사 가능해야 합니다. 자신의 기사에서 다음과 같이 위에서 설명한 세 가지 원칙은 개발의 지침이 되었습니다. 현재의 형태, 즉 암호화가 아닌 설계에 따라 제로 지식을 달성하는 감사 가능한 클라우드 기반 비밀번호 관리자에 도달하는 데 3년의 아이디어와 반복이 걸렸습니다. 비밀번호는 클라우드를 사용하여 사용자 장치 간에 동기화되지만, 어떤 비밀도 이러한 장치 밖으로 나가지 않습니다. 비밀은 클라우드에 도달하지 않기 때문에 클라우드 서버 손상으로 인해 비밀이 유출될 수 없습니다. Neulock Password Manager Neulock을 만드는 데 걸린 3년의 과정은 Part II에 기록될 것입니다.
