Restic: 빈 비밀번호 허용

Restic은 빈 비밀번호를 허용해야 합니다.

사용 사례가 무엇인지 자세히 설명해 주시겠습니까? 왜 restic은 빈 암호를 허용해야 합니까?

디자인 결정입니다.

사실이다. 그러나 나는 당신이 달성하려는 것이 무엇인지 궁금합니다.

관련 문제는 아마도 #1018일 것입니다.

디렉토리에서 파일을 변경할 때 빠른 안전망으로 로컬 시스템의 일부 디렉토리를 임시로 백업하고 싶었습니다. 백업을 생성할 때마다 암호를 기억하거나 암호를 입력하는 번거로움을 겪고 싶지 않았습니다. 방금 a 를 암호로 사용했기 때문에 암호를 전혀 사용하지 않는 것과 비교하여 이 암호를 사용하면 실질적인 보안상의 이점이 없습니다. 따라서 불필요한 암호를 기억하거나 입력하는 데 드는 오버헤드가 낮으면 도구가 덜 완벽해집니다.

설명 감사합니다. 이 수표를 유지하고 싶으므로 지금은 이 문제를 닫습니다. 추가 의견을 자유롭게 추가하십시오. 감사 해요!

얼마 전에 우리가 이것에 대해 이야기했을 때 당신은 토론이 있을 것이라고 말했습니다...
이 검사가 유용하다고 생각하는 이유를 설명해 주시겠습니까? 나중에 암호를 추가할 수 있도록 리포지토리를 계속 암호화해야 합니다.

내 경험상 대부분의 사용자는 암호를 설정하기를 원할 것이기 때문에 이 검사가 유용하다고 생각합니다. 빈 암호를 수락하거나 빈 암호를 수락할 수 있는 코드 경로가 있는 경우 사용자가 실수로 적절한 암호화 없이 원격 위치에 백업을 저장할 수 있습니다. 이러한 상황이 발생할 수 있는 한 가지 상황은 RESTIC_PASSWORD 환경 변수를 내보내지 않거나 실수로 빈 문자열로 설정하는 경우입니다.

그래서 이 경우 비밀번호를 설정해야 하는 소소한 불편함을 없애는 것보다 실수로부터 사용자를 보호하는 것이 더 낫다는 생각이 듭니다. :)

이 비록 쉬운 해결 방법이 있습니다 사용 암호 관리자가 문자열을 사용하여 test , 수출 RESTIC_PASSWORD 에 파일 등을 통해 정적으로 /etc/profile.d , 디렉토리의 이름을 사용하면 '(또는 저장소)를 비밀번호로 저장 중입니다...

저장소에 액세스하려면 비밀번호를 알고 있어야 합니다.
비밀번호를 잊어버리면 데이터가 복구 불가능하게 손실됩니다.

내 데이터를 영원히 잃고 싶지 않다면 어떻게 이런 일이 일어나지 않도록 할 수 있습니까?

@LexSong 암호 관리자를 사용합니다.

2018년 7월 3일 화요일 09:56:56AM -0700에 Chenfeng Bao가 작성했습니다.

@LexSong 암호 관리자를 사용합니다.

비밀번호 관리자 데이터베이스를 백업하는 방법은 무엇입니까? 당신은 ~
데이터베이스와 함께 암호 관리자를 사용하는 것을 제안합니다.
비밀번호? 어떤 암호 관리자가
비밀번호는?

암호 관리는 이 스레드에서 너무 많은 세부 정보를 얻고 싶지 않은 거대한 주제입니다. 올바르게 수행되면 암호가 골칫거리가 되지 않아야 한다는 점을 지적하십시오. 온라인에는 수많은 리소스가 있습니다.

암호 관리자의 데이터베이스는 이미 적절하게 암호화되어 있어야 하므로 다른 암호화 계층 없이 원하는 위치에 둘 수 있습니다. 또한 많은 클라우드 기반 암호 관리자 서비스가 있으므로 백업에 대해 스스로 걱정할 필요가 없습니다.

restic의 지원에 관해서는 로컬에서 일반 텍스트 파일에 암호를 입력하고 --password-file 옵션을 사용할 수 있습니다. 그러면 암호를 수동으로 입력할 필요가 없습니다. 암호 자체도 기록을 위해 암호 관리자에 넣어야 합니다.

하루가 끝나면 모든 것을 진정으로 안전하게 유지하기 위해 외워야 하는 복잡한 암호/암호가 항상 하나 있습니다.

사실, 당신이 정말로 단순한 저장소의 암호를 원하지 않는다면, 한 글자의 더미 암호를 사용하지 않는 이유는 무엇입니까?

암호로 '''를 사용하는 것이 실제로 내 해결 방법이었지만 몇 년 후에 이 저장소를 다시 볼 때 이 저장소를 삭제하는 것을 잊었을 경우를 대비하여 이것을 사용한 기억이 있는지 확신할 수 없기 때문에 적절하지 않다고 느낍니다. 더 이상 필요하지 않습니다. 따라서 나는 그것을 알아내기 위해 일종의 무차별 대입을 구현해야 할 수도 있습니다. 이것은 모두 피할 수 있는 작업입니다.

과거에는 나중에 쉽게 삭제할 수 있도록 비밀번호로 외부 HD를 임시로 보호했을 때 이 상태로 남겨진 상황에서 이미 간단한 임시 비밀번호를 사용했습니다. 그러나 나는 그것을 삭제하지 않았으므로 다음에 사용할 때 드라이브에 중요한 것이 없는지 확인하고 싶었습니다. 불행히도 내 비밀번호 관리자의 비밀번호는 거기에서 비밀번호를 업데이트/제거하는 것을 잊어버렸기 때문에 더 이상 작동하지 않았습니다. 그러므로 미래의 나의 모습을 생각할 때 내가 복호화할 수 없는 은밀한 저장소를 만들지 않음으로써 그에게 더 쉽게 다가갈 수 있도록 하는 것이 좋은 생각인 것 같다.

다른 생각이 있습니다. 리포지토리에 액세스할 암호가 없을 때 "restic"을 기본 암호로 사용하려고 시도하고 작동하지 않으면 오류 메시지로 폴백하는 것은 어떻습니까? 그런 다음 사용자는 이 암호를 사용하여 암호화가 필요하지 않으며 나머지는 추가 마법 없이 열 수 있음을 나타낼 수 있습니다.

사용자 실수로부터 보호하기 위해 확인을 유지하기 위해 이전 의견에 동의합니다.

Restic은 이미 언급된 이유로 빈 비밀번호를 지원해야 합니다. 나
특히 내 로컬 백업을 암호화하고 싶지 않기 때문에
액세스할 수 없습니다. 비밀번호를 잊어버릴 위험을 감수하고 싶지 않습니다.
데이터를 복원할 수 없습니다. 사용자가 일반적으로
매우 드물게 복원하고 자주 수행하지 않는 무인 백업을 실행합니다.
비밀번호를 입력해야 하므로 잊어버리기 쉽습니다.

파일이나 스크립트에 암호를 저장하는 것은 오류가 발생하기 쉬운 해결 방법입니다.
존재해서는 안되는 문제.

실수로 업로드하지 않도록 주의해야 한다는 데 동의합니다.
원격 저장소에 암호화되지 않은 데이터.

간단한 해결책은 명령줄 옵션이 있는 것 같습니다.
--allow-empty-password . 사용자는 스크립트에서 해당 스위치를 설정할 수 있으며
기본값은 암호를 요구하도록 유지될 수 있습니다.

이것은 사용자가 일반적으로 매우 드물게 복원하고 암호를 입력할 필요가 없는 무인 백업을 실행하여 암호를 잊어버릴 가능성이 더 높기 때문에 실제 위험입니다.

이러한 백업 암호는 기억하기 위한 것이 아닙니다. 기억해야 할 복잡한 암호화 암호는 자주 사용하게 될 암호 관리자용 암호뿐입니다. 그리고 당신은 _정말로_ 암호 관리자를 사용해야 합니다.

파일이나 스크립트에 암호를 저장하면 존재하지 않아야 하는 문제에 대한 오류가 발생하기 쉬운 해결 방법입니다.

죄송합니다. 오류가 발생하기 쉬운 해결 방법인지 모르겠습니다. 그것은 나에게 암호화를 자동화하는 완전히 유효한 방법인 것 같습니다. 이 문제는 다시 암호 관리자를 사용하여 해결됩니다.

간단한 솔루션은 --allow-empty-password 명령줄 옵션을 사용하는 것 같습니다. 사용자는 스크립트에서 해당 스위치를 설정할 수 있으며 기본값은 암호를 요구하도록 유지될 수 있습니다.

이것은 사용자 오류를 피하기 위한 합리적인 방법처럼 보입니다. 그러나 공격 표면 증가에 대한 우려가 여전히 존재하며 세심한 주의가 필요합니다.

이러한 백업 암호는 기억하기 위한 것이 아닙니다. 기억해야 할 복잡한 암호화 암호는 자주 사용하게 될 암호 관리자용 암호뿐입니다. 그리고 정말로 암호 관리자를 사용해야 합니다.

암호 관리자는 이 문제에 대한 유효한 솔루션이 절대 아닙니다 . 백업의 요점은 암호 관리자의 데이터베이스를 포함하는 파일을 백업하는 것입니다! 그러면 암호가 암호화된 백업 세트에 저장 되어 있을 때 백업 세트에 대한 암호를 어떻게 복구합니까?

백업 시스템을 설계할 때 백업 외에 사용할 수 있는 것이 없을 때 복원을 포함하는 최악의 시나리오에 대한 계획을 세워야 합니다. 당신이 하는 일은 Restic 백업 과 별도로 비밀번호 관리자 데이터베이스를 백업하는 것입니다. 당신 에게는 괜찮지만 다른 사용자에게 그 시스템을 강요하는 것은 당신이 할 일이 아닙니다. 그리고 Restic을 사용하기 위해 암호 관리자가 필요하다고 말하는 것은 터무니없는 일입니다. 특히 Restic과 통합되도록 설계되지 않은 경우에는 더욱 그렇습니다. 그렇다면 그 취지에 대한 문서를 보여주세요.

Restic은 많은 소프트웨어와 마찬가지로 사용자가 자신의 요구 사항을 충족할 수 있도록 하기 위한 것입니다. 귀하의 요구사항에는 귀하의 Restic 백업 복원 시나리오에 불과한 베어메탈이 포함되어 있지 않습니다. 다른 사용자의 필요가 있습니다. 다른 사람들의 필요를 그들에게 지시하지 마십시오.

이것은 사용자 오류를 피하기 위한 합리적인 방법처럼 보입니다. 그러나 공격 표면 증가에 대한 우려가 여전히 존재하며 세심한 주의가 필요합니다.

제안된 --allow-empty-password 옵션으로 인해 공격 표면이 증가하는 것과 관련하여 구체적으로 어떤 문제가 있다고 보십니까?

이것은 사용자 오류를 피하기 위한 합리적인 방법처럼 보입니다. 그러나 공격 표면 증가에 대한 우려가 여전히 존재하며 세심한 주의가 필요합니다.

내 다른 아이디어는 restic이 restic 와 같이 암호가 지정되지 않은 경우 저장소에 액세스하기 위해 기본 암호를 사용하는 것이었습니다. 그러면 새 리포지토리를 생성하기 위한 UI가 변경되지 않고 사용자가 기본 비밀번호를 사용하는 경우에만 리포지토리에 자동으로 액세스할 수 있으며 사용자는 비밀번호를 기억할 필요가 없습니다.

죄송합니다. 오류가 발생하기 쉬운 해결 방법인지 모르겠습니다. 그것은 나에게 암호화를 자동화하는 완전히 유효한 방법인 것 같습니다. 이 문제는 다시 암호 관리자를 사용하여 해결됩니다.

암호 관리자와 통합되지 않는 한 암호 관리자 외부에 암호 복사본이 있기 때문에 암호 관리자의 값이 잘못되었거나 오래되었거나 실수로 삭제될 위험이 여전히 있습니다.

나는 또한 빈 암호를 허용하는 옵션을 보고 싶습니다( --allow-empty-password 플래그를 사용하거나 NRPE의 --dont-blame-nrpe 플래그와 같이 위험을 강조하기 위해 더 장황하고 고유한 것을 사용).

내 사용 사례:

• 비즈니스: 우리는 특별한 지식(예: 리포지토리 암호) 없이 비상/재해에서 복구할 수 있는 "누구나"가 필요한 신뢰할 수 있는 환경에 포함된 리포지토리를 보유하고 있습니다.
• 홈: 가족 사진과 같은 것들을 임시로 백업하고 싶습니다. 이것들은 특별히 기밀이 아니며, 내가 갑작스럽게 사망한 경우, 우리 가족은 최소한의 저항으로 이 개인적으로 중요한 데이터에 액세스할 수 있어야 합니다. 날짜 또는 다른 것과 혼합_).

데이터 무결성과 암호화를 보장하기 위해 암호가 필요하다는 것을 이해합니다. keys 디렉토리에 있는 파일이 JSON 객체인 것으로 보입니다. 아마도 의사 무작위 키가 생성되어(키가 없는 것이 아니라) 거기에 저장될 수 있습니까? 성능상의 이유로 암호화 오버헤드를 피하려는 사용자에게는 도움이 되지 않습니다.

@fd0 제안된 --allow-empty-password 명령줄 옵션에 대해 어떻게 생각하십니까? 기본적으로 암호가 필요하지만 필요할 때 사용자가 암호를 무시할 수 있습니다.

그리고 이 문제를 다시 여는 것을 고려하십시오. 많은 사용자의 요구 사항에는 암호를 잊거나 잘못 배치하여 액세스 권한을 잃을 위험 없이 기밀이 아닌 파일을 백업하는 것이 포함됩니다.

여기 완전히 새로운 사용자가 있습니다. 아직 첫 번째 저장소를 만들지 않았지만 다른 도구에 대한 수년간의 경험이 있습니다. 제가 가장 좋아하는 것은 오래된 "덤프"입니다. 이것은 당연한 일 입니다. 물론 빈 암호는 허용되어야 합니다. 부주의한 오류의 위험을 최소화하기 위해 반드시 플래그를 추가하지만, 다른 요구 사항을 명확하게 표시한 경험 있는(잠재적인) 사용자에게 사용 사례를 지시하지 마십시오.
내가 하려는 것은 안전을 위해 로컬 백업을 만드는 것뿐입니다. 보안은 문제가 되지 않으며 백업이 필요한 것보다 암호를 잊어버릴 가능성이 훨씬 더 큽니다. 그리고 나는 암호 관리자를 싫어합니다 ...

암호 요구 사항이 있으면 백업을 자동화하기 어렵고 환경이나 스크립트 파일에 암호를 제공해야 하는 것은 처음부터 전체 보안을 무용지물로 만듭니다.

env 또는 스크립트 파일에 암호를 제공해야 하는 것은 처음부터 전체 보안을 무용지물로 만듭니다.

반드시 사실은 아닙니다. 좋은 방법이 있습니다.

반드시 사실은 아닙니다. 좋은 방법이 있습니다.

여기에서 이 주장을 다시 언급하지 마십시오. 많은 사용자가 암호화되지 않은 백업이나 빈 암호 백업을 만들어야 합니다. 당신이 그들 중 하나가 아니라면, 당신에게 좋습니다.

@mholt , 추천 사항이 있습니까? 최대한의 보안을 유지하면서 간섭 없이 서버를 백업할 수 있어 기쁩니다.

많은 사용자가 암호화되지 않은 백업이나 빈 암호 백업을 만들어야 합니다.

이것은 일반적으로 XY 문제 입니다.

@mholt , 추천 사항이 있습니까? 최대한의 보안을 유지하면서 간섭 없이 서버를 백업할 수 있어 기쁩니다.

특정 상황, 위협 모델, 환경, 허용 가능한 위험, 기술 및 사용성 목표에 따라 크게 달라집니다. 그래서 아니오, 누구를 위한 포괄적인 권장 사항이 없습니다.

이것은 일반적으로 XY 문제입니다.

그래서 아니오, 누구를 위한 포괄적인 권장 사항이 없습니다.

그런 겸손한 태도는 도움이 되지 않습니다. 더 나쁜 것은 우리의 필요 사항이 잘못되었다고 말한 후 조언을 제공하기를 거부한다는 것입니다. 이것은 Apple, Inc.가 아닌 FOSS 프로젝트입니다.

예를 들어, 이미 암호화되지 않은 데이터의 로컬 백업을 암호화할 필요도 없고 암호화하고 싶지도 않습니다. 기본 디스크에 오류가 발생하여 백업을 복구해야 하는 경우 암호가 백업 스크립트 및 구성 파일과 함께 백업 리포지토리 내에 저장됩니다. 제 주요 관심사는 다른 사람들이 이 중요하지 않은 데이터에 액세스하지 못하도록 하는 것입니다. 저의 주요 관심사는 쉬운 복구와 데이터가 잠기지 않는 것입니다.

이것은 많은 사용자에게 일반적인 경우이며 사용자의 요구 사항을 결정하는 것은 귀하가 아닙니다.

소프트웨어는 사용자에게 서비스를 제공하기 위해 존재하는 것이지 사용자가 요구를 수락하도록 강요하는 것이 아닙니다.

사용 사례를 설명해주셔서 감사합니다. 다시 한 번 걱정해 주세요. 기록을 위해, 특히 "비밀번호 분실"이 유효하다고 생각합니다. 나는 또한에 대한 특별한 플래그 생각 restic init 같은 --allow-empty-password (내가 코너 케이스에 대한 몇 가지 고려 사항이 있지만, 나는 그들이 해결 될 수 있다고 확신 해요) 작동합니다. 따라서 이 문제를 다시 열겠습니다.

빈 비밀번호를 허용하면 "비밀번호 분실"에 대한 안전 문제가 해결되지만 여전히 평소와 같이 모든 데이터가 암호화됩니다.

다른 메모에서, 나는 이 스레드의 톤을 전혀 좋아하지 않습니다. 당신은 restic을 사용하지 않아도 무방합니다. 완벽합니다. 우리 대부분은 여가 시간에 쉼 없이 일하고 있습니다. 이 스레드의 일부 댓글은 "이 기능을 구현해야 합니다. 필요한 사용자가 있습니다!"라는 제목과 같이 매우 적절합니다. 그렇지 않습니다. 우리는 그것을 고려하고 실행할 수 있지만 아무것도 하지 않기로 결정할 수도 있습니다.

그러니 여러분, 여러분이 동의하지 않더라도 이 토론을 생산적으로 유지합시다. :)

@fd0 불명확한 점 양해 부탁드립니다. 나는 당신이나 Restic 개발자에게 어떤 것도 요구하거나 기대하지 않습니다. 그것은 당신의 프로젝트이자 당신의 시간이며, 당신이 원하는 것은 무엇이든 할 수 있습니다.

제가 묻고 싶은 것은 이 기능과 사용 사례를 고려하는 것입니다. 직접 구현하는 데 관심이 없다면 괜찮습니다. 다른 사람들이 논의할 수 있도록 문제를 공개하고 구현하는 PR을 고려하시기 바랍니다.

내가 반대하는 것은 이 기능을 원하는 사용자가 자신의 요구 사항을 이해하지 못한다는 의견(귀하가 아닌)입니다. 그것은 무례하고 도움이 되지 않는 소음입니다.

저를 위해, 저는 bup 특수 리모컨과 함께 git-annex를 사용하고 있습니다. Annex는 이미 파일 암호화를 지원합니다(bup의 중복 제거 기능을 사용하기 위해 해제했습니다). 그런 다음 원격 서버에 bup repo(단지 멋진 git repo)를 백업합니다. 그런 다음 bup repo는 캐시일 뿐이므로 삭제하고 필요에 따라 restic을 통해 복원을 수행할 수 있습니다.

그래서 기본적으로 저는 Unix Way(tm)에서 여러 개의 일회용 도구를 함께 꿰매고 있습니다. Restic(저는 현재 이중화에서 전환 중입니다.)은 슬라이딩 윈도우 블록 중복 제거를 원격 클라우드로 수행하고 그게 제가 필요한 전부 입니다. 암호화 및 로컬 블록 중복 제거는 다른 계층에서 발생합니다. 따라서 암호를 지정하거나 암호화(실제로 CPU 사용을 절약함)를 원하지 않습니다.

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

아직 암호화 중이지만 암호가 비어 있기 때문에 이것은 내가 원하는 것의 절반에 불과합니다. 가능하다면 CPU 사용량을 복구하고 싶습니다.

빈 비밀번호를 허용하면 "비밀번호 분실"에 대한 안전 문제가 해결되지만 여전히 평소와 같이 모든 데이터가 암호화됩니다.

흠, 여전히 빈 암호로 암호화하는 동기는 무엇입니까?

내 말은, 저전력 하드웨어에서 restic을 실행할 때 암호화가 눈에 띄는 런타임 오버헤드를 추가합니다.

편집 : 좋아, https://github.com/restic/restic/issues/1018#issuecomment -307549863 - 특히 두 번째 요점이 내 질문에 대답합니다.

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

이 제안의 주요 문제는 다음과 같습니다. 작동하지 않습니다. 그러면 restic이 대화식으로 암호를 묻습니다.

~# restic -r '/tmp/restic/' -p '/dev/null' init
enter password for new repository:

문제를 다시 열어주신 @fd0님 , 감사합니다. 내 의도는 그들이 재미가없는 아무것도 자신의 시간을 보내고있는 자유 시간 개발자를 밀어하지 않는 것입니다, @alphapapa에 동의합니다.

우리는 다른 사람이 우리 자신의 필요를 이해하지 못한다는 말을 듣는 것을 좋아하지 않습니다.

내가 보기에 백업 도구의 가장 중요한 기능은 어떤 경우에도 복원을 수행할 수 있는 기능입니다. 보안이 매우 중요하지만 데이터 보안(복원 기능) 또는 데이터 보안(무단 액세스로부터 보호)이 더 높은 우선 순위를 갖는지 여부는 특정 상황에 따라 다릅니다.

물론 보안보다 보안이 더 중요한 상황에서만 도구 개발을 자유롭게 결정할 수 있습니다.

@mholt는 "XY-문제"를 언급 한 바와 같이 : 요청은 공개 가능한 일반 restic 문서 넘어 저장소 자체에 물론 액세스에 대한 지식없이 재해 복구를 할 수있을 것입니다.
"아무런 지식도 없이"는 암호 관리자의 필요 또는 사용을 제외합니다.

이 문제를 발견한 이유는 다음과 같습니다. _개인적으로 PC를 사용하는 일부 사람들을 돕고 있습니다. 그들의 비밀번호 처리는 엉망입니다. USB 드라이브에 백업을 설정하는 동안 올바른 비밀번호 처리를 가르치려고 하면 백업이 전혀 생성되지 않거나 필요할 때 사용할 수 있는 비밀번호가 생성되지 않을 뿐입니다. 그들은 복원이 필요할 때 다른 사람의 도움을 받을 수 있으므로 상황을 완화하기 위해 내가 생각해낸 모든 것이 무효일 수 있습니다._

지금은 나머지 백업 리포지토리와 동일한 USB 드라이브에 텍스트 파일로 비밀번호를 저장하고 있습니다. 이는 비밀번호를 사용하는 보안을 완전히 망칩니다.
추가 보안 계층을 제공하지 않는 암호를 사용하면 보안에 대한 잘못된 상상을 하게 되므로 이 솔루션이 마음에 들지 않습니다.

물론 여기에서는 개인 로컬 백업에 대해서만 이야기하고 있습니다. 서버의 경우 강력한 암호를 별도의 오프라인 저장소에 복사하는 것이 좋습니다.

여기에 또 다른 문제가 있다고 생각합니다. 일부 프레임워크/API는 빈 비밀번호를 허용하고 일부는 허용하지 않는 경우. 그리고 다른 API가 빈 비밀번호로 암호화한 입력을 해독해야 합니다. 이것은 현재 https://github.com/RNCryptor/JNCryptor의 문제입니다.

그러니 여러분, 여러분이 동의하지 않더라도 이 토론을 생산적으로 유지합시다. :)

이 스레드를 읽은 후 결과가 긍정적이었기 때문에 대화가 생산적이라는 것을 알게 되었습니다.

나는 이것이 Github임을 모든 사람에게 상기시키고 싶습니다. 무언가에 대해 강하게 느끼고 프로젝트 관리자가 수용하지 않는다면 자유롭게 포크를 만드십시오. 말 그대로 몇 초가 걸립니다. 스스로 변화를 만드는 기술이 부족하다면 다른 사람들에게 도움을 요청하십시오. 유지 관리자는 스스로 구현하려는 동기가 부여되지 않은 것을 구현하는 패치를 받아들이는 데 더 개방적일 수 있음을 알게 될 것입니다.

개인적으로 이 경우 보안이 "해야"하는 모든 사람에게 선입견을 강요하는 것은 실수라고 생각합니다. 데이터 보안의 첫 번째 규칙은 데이터를 가질 자격이 있는 사람이 데이터에 액세스할 수 있어야 한다는 것입니다. 규칙 #1을 손상시키는 모든 규칙은 신중하게 고려해야 합니다.

보안은 FUD와 공포 중심 정책으로 가득 찬 주제로, 우리 중 실제로 잘못될 수 있는 모든 것에 대해 생각하는 것을 좋아하는 사람이 거의 없기 때문에 순진하고 성급하며 종종 위선적인 구현으로 이어집니다. 우리가 일이 잘못되게 내버려 두는 것처럼 보일 때 다른 사람들의 비판에 직면하고 싶어하는 사람은 훨씬 적습니다.

우리가 매일 보는 몇 가지 일반적인 실수:

1) 유휴 상태에서 암호화된 미디어에 기록된 데이터는 신뢰할 수 있는 환경에서도 자체적으로 암호화되어야 한다고 주장합니다. 도청에 대한 두려움의 끝은 어디입니까? 사용자가 잠재적으로 유능할 수 있고 중복 계층을 추가하면 데이터 손실 위험이 증가할 수 있다는 신뢰를 어디서부터 시작해야 할까요?

2) 특정 형식의 암호, 즉 하나 이상의 대문자, 하나의 숫자, 하나의 영숫자가 아닌 문자가 포함된 8자 - 이것은 20년 동안 일반적인 관행이었으며 고통이 이득을 초과하기 때문에 이제 폭로되었습니다. 대신 우리는 xkcdpassword 와 같은 기억 에

3) 마스터 비밀번호를 사용하는 경우 - 세션에 캐시하지 못하여 사용자가 하루 종일 여러 번 비밀번호를 입력해야 하므로 비밀번호를 입력하는 행위 자체가 눈에 띄는 공격 벡터가 됩니다.

4) 마스터 암호 사용 - 정책 확인에 실패하고 마스터 암호를 맹목적으로 쿼리하여 사용자가 실제로 필요하지 않은 경우 제시하는 데 익숙해지도록 하여 사용자가 마스터 암호를 제공해야 하는지 여부에 대한 비판적 분석을 중지하게 됩니다. 이 인스턴스.

5) 사용자가 거부감을 느끼고 옵트인을 피하거나 해결 방법을 찾도록 최소 권한 정책을 시행하여 보다 관대한 계획이 있는 경우보다 훨씬 더 오랫동안 문을 열어 둡니다.

6) N+1 중복 없이 최소 권한 정책 시행, 일명 '비즈니스 연속성/"핵심 인력 정책" 고려 부족. 즉, 둘 다 동의할 때만 액세스할 수 있도록 2개의 개인 키 뒤에 공유 리소스를 잠그는 대신(정족수 2), 3개의 개인 키 중 2개 뒤에 잠그십시오. 아무도 영원히 살지 않습니다.

프로그래머로서 우리는 단일 키 암호화 체계를 구현할 때마다 접근성의 중요성을 고려해야 하며 단일 키 암호화 체계에 대한 키 손실의 결과를 고통스럽게 알고 있는 사람들의 우려를 들어야 합니다.

또한 오용에 대한 두려움 때문에 사용자로부터 물건을 빼앗는 것은 거의 모든 결정이 두려움에서 비롯되는 것과 마찬가지로 근본적으로 잘못된 것임을 친절하게 기억하도록 합시다. 누군가가 잘못된 일을 할 수 있다는 이유로 모든 사람을 처벌하는 것은 사회 전체를 축소시킵니다.

이 순간에 그 개념에 동의하지 않는다고 생각되면 심호흡을 하고 10까지 세고 다음을 고려하십시오. 누군가가 깡통이 든 쓰레기 봉투에 머리를 넣어 자살했을 때 우리 사회는 어떻게해야합니까? 휘핑 크림을 뿌리고 아산화질소 캔 전체를 흡입하시겠습니까? 스프레이 휘핑 크림을 모든 사람에게서 멀리해야합니까? 비닐 봉투? 호흡? 이 모든 것이 사용자 사망을 초래하는 방식으로 오용될 수 있습니다.

어린아이가 성냥을 가지고 노는 것처럼 물건을 가져가려는 무모한 충동 대신에 사람들에게 이러한 물건을 올바르게 사용하도록 교육하는 쪽에서 실수를 저질러야 합니다. 또는 RTFM을 사용하는 사람들만 찾을 수 있도록 진입 장벽을 높입니다.

결국 여기까지가 그렇게 되었고, 그 결과를 받아들이겠다는 결정은 이미 모든 문제와 의견이 표명될 때까지 오지 않았습니다. 비생산적인 토론이 어떻게 들리는지에 대한 예를 보려면 공영 TV 방송국에서 의회 토론회 세션을 시청하는 것이 좋습니다. lol. 여기의 참가자들은 그에 비해 서로를 매우 존중했습니다.

암호화 및 암호 보호가 기본적으로는 아니지만 명시적인 옵션으로만 사용 가능했던 이전의 좋은 아카이브 유틸리티를 기억하십시오. 보안은 이 유틸리티 범위를 벗어나는 많은 외부 솔루션을 가질 수 있고 이러한 관리는 사용자에게 달려 있기 때문에 이것이 올바른 논리입니다. 사용자가 선택한 보안 도구를 제공하기만 하면 됩니다. 그러나 저자는 오용을 방지하기 위해 사용자가 요구하지 않는 것을 처리하는 것을 선호합니다.

그리고 다시 톤에 대해. 이것은 오픈 소스 세계에서 일반적입니다. 그리고 그것은 어떤 심리적 메커니즘에 의해 뒷받침되었습니다. 저자가 동의하지 않는 비판은 여가 시간을 보내기 위한 주장으로 간주됩니다. 그리고 매번 우리가 상기해야 할 사항: 우리는 여기에서 당신의 여가 시간에 대해 논의하지 않고 대신 당신의 천재적인 창조물, 그 기능 및 배후의 논리를 탐구합니다. 우리는 당신이 우리의 요구를 충족할 의무가 없으며 아무 것도 하지 않을 완전한 권리가 있음을 결코 잊지 않습니다. 하지만 당신이 하는 일이 마음에 든다면, 그것은 (어쩌면) 다른 사람들이 그것을 좋아하기 때문일 수도 있습니다. 따라서 최소한 다수의 요구를 충족하는 데 관심이 있다는 희망이 있을 수 있습니다.

추신: 이 모든 것은 단지 추상적인 말일 뿐이며 실제 행동을 의미하지는 않습니다.

저장소에 암호를 허용하지 않는 것에 대한 논의에서 한 가지 이해하지 못한 것이 있습니다(이전에 @fd0이 작성한 컨텍스트에서 데이터가 여전히 암호화된다고 가정). 암호를 "원하지 않는" 사람들이 "1234"와 같은 더미 암호를 사용하지 않는 이유는 무엇입니까? 비밀번호가 필요하지 않은 경우 더미 비밀번호를 사용할 수 있는데 비밀번호를 제거하는 restic에 코드를 작성하는 의미가 무엇입니까? restic을 실행할 때 명령줄에 입력하는 것이 번거롭다고 생각되면 하나의 환경 변수 또는 암호 파일에 있습니다.

@rawtaz 이것은 이 스레드의 이전 댓글에서 답변되었습니다.

restic init -r foo --no-password 가 아마도 restic init -r foo --allow-empty-password 보다 더 나은 플래그 이름이라고 말하겠습니다. 단순히 전자가 요점에 더 가깝고 후자가 너무 장황하기 때문입니다.

이 주제에 대한 나머지 코드 기반을 늘리는 대신 더미 암호를 사용하는 것이 완벽하게 실행 가능한 방법이 아닌 이유에 대해 좋은 논거를 찾지 못했습니다. 비밀번호 "a"를 잊어버릴 수 있다고 말하는 사람을 본 적이 있습니다. 그것이 사실일 수도 있지만 간단한 더미 암호를 만들어 기억하거나 최소한 필요할 때 새로 알아내는 것이 가능합니다. 그러나 무엇이든 플래그도 잘 작동합니다. 이것이 얼마나 큰 문제인지에 놀랐습니다.:D

여기 예가 있습니다. 1년 전에 임시 백업을 했습니다. 스크립팅
더미 암호, 파일에서 읽습니다. 비밀번호를 기록하지 않았습니다
다른 곳. 그 기계를 사용하지 않은 지 1년이 지난 후 나는 완전히
프로세스와 비밀번호를 잊어버렸고
결국 찾기 전에 암호를 추측(역설계)
스크립트. 전적으로 내 잘못이지만 여전히 -- 보안은 필요하지 않습니다.
그리고 더미 암호를 기억하도록 강요받고 싶지 않습니다. 그리고 만약 내가
원본 파일에 액세스할 수 없었다면 잠겨 있었을 것입니다.

TD

너무 복잡하게 해서 그런거 아닙니까? 가장 일반적인 암호 중 하나는 1234입니다. 그것을 사용하면 어딘가에서 찾으려고 시도할 필요가 없습니다(더 복잡한 암호를 사용했다고 생각하지 않는다고 가정). 왜냐하면 더미 암호를 입력해야 할 때 알고 있기 때문입니다. 1234. 하지만 무슨 말인지 알겠습니다.

나는 또한 빈 암호를 허용하는 옵션을 보고 싶습니다( --allow-empty-password 플래그를 사용하거나 NRPE의 --dont-blame-nrpe 플래그와 같이 위험을 강조하기 위해 더 장황하고 고유한 것을 사용).

내 사용 사례:

* **Business:** we have a repository contained in a trusted environment that we need "anyone" to be able restore from in an emergency/disaster without having to have special knowledge (ie, a repository password).

* **Home:** I would like to create a restic backup of things like family photos. These are not particularly confidential, and in the case of my untimely demise, my family need to be able to access this personally important data with minimum resistance (_for example, without having to find a passphrase in a safe, that's possibly out-of-date or mixed up with another_).

데이터 무결성과 암호화를 보장하기 위해 암호가 필요하다는 것을 이해합니다. keys 디렉토리에 있는 파일이 JSON 객체인 것으로 보입니다. 아마도 의사 무작위 키가 생성되어(키가 없는 것이 아니라) 거기에 저장될 수 있습니까? 성능상의 이유로 암호화 오버헤드를 피하려는 사용자에게는 도움이 되지 않습니다.

• 비즈니스: 우리는 특별한 지식(예: 리포지토리 암호) 없이 비상/재해에서 복구할 수 있는 "누구나"가 필요한 신뢰할 수 있는 환경에 포함된 리포지토리를 보유하고 있습니다.

그러나 그 "누구나"는 이미 특별한 지식/지시가 필요합니다. 그들은 사용할 리포지토리 및 기타 항목을 포함하여 데이터를 복원하기 위해 restic을 실행하는 방법을 알아야 하며, 그런 다음 해당 지침에 더미 암호를 포함하는 것이 매우 쉬울 것입니다. 또는 복원을 수행하는 스크립트 또는 유사한 자동화를 사용합니다(이 경우 여전히 해당 도구를 사용할 위치에 대한 지침을 알고/얻어야 함). 이 경우 더미 암호는 스크립트에서 처리됩니다. . 이것을 어떻게 보더라도 더미 비밀번호는 문제가 되지 않습니다. 그리고 진지하게, 모든 사람들이 갑자기 그것을 잊어버린다면 사람들은 단순히 1234를 추측하거나 무차별 대입할 수 있을 것입니다. 문제가 되지 않습니다 :P

• 홈: 가족 사진과 같은 것들을 임시로 백업하고 싶습니다. 이것들은 특별히 기밀이 아니며, 내가 갑작스럽게 사망한 경우, 우리 가족은 최소한의 저항으로 이 개인적으로 중요한 데이터에 액세스할 수 있어야 합니다. 날짜 또는 다른 것과 혼합_).

무엇을 기다립니다? 도대체 왜 암호가 없기를 원하고 그것이 불가능할 때(최소한 현재로서는) 아주 간단한 더미 암호(예: 1234)를 사용한 다음 그 슈퍼 간단한 더미 암호를 금고에 넣어두 겠습니까? 그것은 완전히 무의미합니다. 다른 곳에 두십시오. 그리고 그만한 가치가 있기 때문에 귀하의 사망 시 가족이 알아야 할 다른 정보가 이미 많이 있을 수 있으므로 더미 비밀번호도 함께 넣어 두십시오.

마지막으로, 더미 암호는 너무 간단하고 명확해야 오래되지 않으며 둘 이상의 더미 암호가 필요하지 않습니다. 따라서 구식이거나 다른 것과 혼합되어서는 안됩니다.

예, 그러한 제안은 이미 이루어졌으므로 이제 서클에 들어가고 있습니다. 개인적으로 말해서, 그것들은 내 환경과 사용 사례에 대해 편안함을 느끼는 적합한 솔루션이 아닙니다.

이 기능이 필요하지 않습니다. 괜찮습니다. 그렇다고 해서 다른 모든 사람의 사용 사례가 유효하지 않은 것은 아닙니다. Amazon S3 백엔드를 사용할 필요가 없지만 필요하지 않다고 선언하지 않고 그냥 사용하지 않습니다. 이 기능이 구현되면 사용하지 않는 데 비용이 들지 않습니다.

예, 그러한 제안은 이미 이루어졌으므로 이제 서클에 들어가고 있습니다.

네, 그리고 솔직히 더미 비밀번호가 왜 그렇게 다루기 힘든지에 대한 실제 설명을 아직 보지 못했습니다. 저는 대부분이 비밀번호의 과도한 복잡성을 본 것 같습니다.

개인적으로 말해서, 그것들은 내 환경과 사용 사례에 대해 편안함을 느끼는 적합한 솔루션이 아닙니다.

이것은 내가 완전히 존경하는 것입니다. 모든 사람의 사용 사례는 개별적이며 귀하의 워크플로가 있습니다. :)

어느 시점에서 우리는 --no-password 또는 이와 유사한 것을 얻을 것이라고 생각합니다. 바라건대 이 사용 사례도 해결될 것입니다. 입력해 주셔서 감사합니다!

로타즈가 썼다

restic init -r foo --no-password 가 아마도 restic init -r foo --allow-empty-password 보다 더 나은 플래그 이름이라고 말하겠습니다. 단순히 전자가 요점에 더 가깝고 후자가 너무 장황하기 때문입니다.

이 주제에 대한 나머지 코드 기반을 늘리는 대신 더미 암호를 사용하는 것이 완벽하게 실행 가능한 방법이 아닌 이유에 대해 좋은 논거를 찾지 못했습니다. 비밀번호 "a"를 잊어버릴 수 있다고 말하는 사람을 본 적이 있습니다. 그것이 사실일 수도 있지만 간단한 더미 암호를 만들어 기억하거나 최소한 필요할 때 새로 알아내는 것이 가능합니다. 그러나 무엇이든 플래그도 잘 작동합니다. 이것이 얼마나 큰 문제인지에 놀랐습니다.:D

나는 더미 암호 사용/처리에 대해 걱정하지 않습니다. 대신 CPU 사용이 저사양 하드웨어에서 실행될 때 필수 암호화로 인해 백업 프로세스 속도를 늦추는 것이 걱정됩니다.

#1018(암호화되지 않은 백업)을 해결하면 이 문제도 해결됩니다(예: --unencrypted 스위치 대신 --no-password 스위치 사용).

나는 실제로 CPU에 AES-NI(또는 유사한 확장)가 없고 백업이 CPU 바운드였던 저가형 하드웨어에서 restic을 사용했습니다. 다른 경우에는 CPU가 조금 더 강력했지만 사용 가능한 유일한 외장 하드 드라이브는 이미 LUKS로 암호화되어 있어 두 개의 암호화 프로세스를 병렬로 처리할 만큼 강력하지 않았기 때문에 CPU에 종속되었습니다.

참조: https://github.com/restic/restic/issues/1018#issuecomment -307549863

restic 사용법을 잊어버린 경우 문서를 읽을 수 있습니다. 저장소 위치를 잊은 경우 찾을 수 있습니다. 또는 고아 저장소를 우연히 만나 내부에 백업이 무엇인지 궁금해 할 수 있습니다. 하지만 비밀번호를 잊어버리면 데이터를 영원히 잃게 됩니다. 그리고 실생활에서 가장 단순한 더미 암호는 잊어버릴 수 있습니다. 자주 사용하지 않는 모든 것을 잊을 수 있습니다.

루트 암호를 분실한 경우 init=/bin/bash 옵션으로 부팅하고 전체 액세스 권한을 얻을 수 있습니다. 이 구멍은 닫힐 수 있지만 대부분의 시스템에는 여전히 존재합니다. 왜요? 사용할 수 없음으로 인한 손실이 이러한 경우 불안정으로 인한 손실보다 더 많기 때문입니다. 따라서 보안과 가용성 사이의 균형입니다. 요구 사항이 더 높은 시스템의 경우 보안과 가용성을 모두 제공하는 중복 키와 같은 특수 솔루션이 있습니다.

resitc는 보안 도구가 아닙니다. 백업 도구입니다. 따라서 백업 기능 자체를 먼저 제공하고 보안을 제공해야 합니다. 따라서 암호 보호 및 암호화는 옵션으로만 제공될 수 있으며 기본적으로 제공되어서는 안 됩니다.

BTW: 기본값은 소프트웨어 품질의 표시입니다.

@vstavrinov 보안 도구가 아니라고 말하기 전에 restic에 대한 소개를 읽으십시오. 주요 기능 중 하나는 백업을 안전하게 만드는 백업 도구입니다. 따라서 보안에 대해 염려하지 않는다고 말하면 꽤 멀리 떨어져 있습니다.

하지만 비밀번호를 잊어버리면 데이터를 영원히 잃게 됩니다.

예, 그렇기 때문에 (이 경우 간단한 옵션이 있음) 더미 암호를 사용하여 잊어버린 경우에도 항상 암호를 인식할 수 있습니다.

그리고 실생활에서 가장 단순한 더미 암호는 잊어버릴 수 있습니다.

그렇게 하면 너무 복잡한 더미 암호를 선택한 것이며 더 이상 단순한 더미 암호가 아닙니다.

이 모든 토론은 솔직히 말해서 우스꽝스러울 정도로 어리석어지고 있습니다. 사람들이 1234와 같은 가장 일반적이고 명백한 암호 중 하나가 잊어버려서 금방 알아낼 수 없다고 말하는 것을 믿을 수 없습니다. 비밀번호). 나는 당신이 그 상황에 있을 때 1234를 "추측"할 수 없도록 정말 열심히 노력해야 한다고 말하고 싶습니다. 그리고 그 경우에도 당신은 그것을 추측하지 못할 가능성이 가장 높습니다.

하지만 비밀번호를 잊어버리면 데이터를 영원히 잃게 됩니다.

Wikipedia가 도움이 될 수 있습니다 . https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List 에서 가장 일반적인 비밀번호를 시도해 보세요

이러한 상황이 발생할 수 있는 한 가지 상황은 환경 변수 RESTIC_PASSWORD를 내보내지 않거나 실수로 빈 문자열로 설정되는 경우입니다.

코드에서 암호가 명시적으로 빈 문자열로 설정되었는지 또는 설정되지 않았는지 확인할 수 있습니다(명령줄 옵션이 지정되지 않음, 환경 변수가 설정되지 않음 -> 빈 문자열과 다름).

어떤 암호를 선택하고 싶은지는 사용자가 선택해야 한다고 생각합니다.

#1018(암호화되지 않은 백업)을 해결하면 이 문제도 해결됩니다(예: --no-password 스위치 대신 --unencrypted 스위치 사용).

형식, MITM을 사용하여 암호화되지 않은 채널을 통한 전송 등과 독립적으로 호스팅 제공업체에서 이진 검색으로부터 보호하려면 암호화가 여전히 필수입니다. 이렇게 하면 빈 암호가 표적 공격(0)만큼 많은 보호 기능을 제공하지만 표적이 아닌 공격에 대한 부수적 피해를 피할 수 있습니다.

@rawtaz

주요 기능 중 하나는 백업을 안전하게 만드는 백업 도구입니다. 따라서 보안에 대해 염려하지 않는다고 말하면 꽤 멀리 떨어져 있습니다.

별로 멀리. 내가 "보안에 대해 걱정하지 않는다"라고 말한 부분을 알려주세요. 나는하지 않습니다. 당신은 같은 말을 합니다: "그것은 백업 도구입니다". 백업은 보안이 아니잖아요? 따라서 restic은 보안 도구가 아닙니다. 그리고 "... 주요 기능 중 하나 ...". 당신이 다시 옳습니다. 그것은 기능입니다. 즉, 보안은 기능이고 백업은 기능(대상) 지정입니다.

@rawtaz

이 모든 토론은 솔직히 말해서 우스꽝스러울 정도로 어리석어지고 있습니다. 나는 사람들이 1234와 같은 암호를 말하는 것을 믿을 수 없습니다 ...

나는 아무것도 할 수 없지만 이 경우에도 당신이 옳습니다. 어리석은 것은 더미 암호에 대한 토론입니다. 그러나 더 중요한 것은 암호 보호와 암호화가 선택 사항이어야 한다는 것을 이해하는 것입니다. 뿐만 아니라 사용자에게 불필요한 추가 기능을 부과하지 않아 사용 여부를 선택할 수 있습니다. 그리고 이것은 소프트웨어 품질의 표시이기도 합니다.

그러나 더 중요한 것은 암호 보호와 암호화가 선택 사항이어야 한다는 것을 이해하는 것입니다.

왜요? 백업 도구에 기본 암호화가 없어야 하는 이유는 무엇입니까? 단지 "백업" 도구이기 때문에? 라고 하시는데 그럴만한 이유가 없습니다.

모든 사람을 만족시킬 수 있는 디자인 결정은 없습니다. Restic은 보안을 크게 강조하기 위해 _선택_했으며, 저와 같은 사용자는 강력한 암호화가 기본임을 _사랑_합니다.

• 보안에 관심이 없다면 기본 보안 시스템을 오용 _할 수 없습니다_. 최악의 경우 몇 가지 오류가 표시되고 조정된 명령으로 다시 시도합니다.
• 보안에 관심이 있다면 기본적으로 안전하지 않은 시스템을 오용하여 치명적인 결과를 초래하는 방법이 많이 있습니다. 하나의 누락된 플래그와 민감한 데이터가 유출되어 _돌이킬 수 없을 수도 있습니다.

암호를 생략할 수 있는 플래그를 요청하는 것은 한 가지이지만 기본적으로 암호화가 없다고 주장하는 것은 restic의 암호화에 의존하는 모든 기존 사용자에게 위험한 "나쁜 사람"입니다. 치명적인 사용자 오류의 가능성은 엄청납니다.

@cfbao

그러나 더 중요한 것은 암호 보호와 암호화가 선택 사항이어야 한다는 것을 이해하는 것입니다.

왜요? 백업 도구에 기본 암호화가 없어야 하는 이유는 무엇입니까? 단지 "백업" 도구이기 때문에? 라고 하시는데 그럴만한 이유가 없습니다.

"선택 사항"은 "기본값"과 다릅니다. 기본값은 논쟁의 여지가 있습니다. 그러나 선택권을 갖는 것이 더 중요합니다. 우리는 선택의 여지가 없지만 기본값과 관련이 없습니다. 그게 요점입니다. 먼저 옵션을 제공한 다음 기본값에 대해 논의하는 것이 좋습니다.

이 경우(문제) 매우 간단합니다. --no-password 또는 restic init 유사한 플래그가 있을 수 있습니다(기본값은 여전히 ​​restic이 초기화 시 암호를 요청하는 것입니다). 그러나 이것은 단지 @fd0 의 마지막 응답에 대한 나의 견해. 그리고 이 시점에서 ETA가 없으므로 그것에 대해 물어볼 필요가 없습니다. :)

한편, 더미 비밀번호를 사용하십시오. :) 적절한 구현에는 이전에 리포지토리를 초기화하는 데 사용된 비밀번호/키를 제거/설정 해제하는 기능이 포함되므로 전체 리포지토리를 다시 만들 필요가 없습니다.

그러나 암호화는 또 다른 문제이며 다른 문제에서 추적됩니다.

나는 비밀번호 없음 옵션에 대해 그다지 신경 쓰지 않지만 기본 암호화 없음을 주장하고 있었습니다.

따라서 암호 보호 및 암호화는 옵션으로만 제공될 수 있으며 기본적으로 제공되어서는 안 됩니다.

BTW: 기본값은 소프트웨어 품질의 표시입니다.

내가 위험하다고 생각하는 것.

나는 일반적으로 @rawtaz 의 요점에 동의하지만 토론이 엄격하게 암호 없음 옵션(기본값 변경 안 함)에 관한 것이라면 나는 그것에 대해 너무 많은 지분을 갖고 있지 않습니다.

@cfbao

나는 비밀번호 없음 옵션에 대해 그다지 신경 쓰지 않지만 기본 암호화 없음을 주장하고 있었습니다.

따라서 암호 보호 및 암호화는 옵션으로만 제공될 수 있으며 기본적으로 제공되어서는 안 됩니다.

이 인용에서도 "옵션"이 첫 번째이고 "기본값"이 다음임을 알 수 있습니다. 그리고 그것이 다시 요점입니다.

이 경우(문제) 매우 간단합니다. --no-password 또는 restic init 유사한 플래그가 있을 수 있습니다(기본값은 여전히 ​​restic이 초기화 시 암호를 요청하는 것입니다). 그러나 이것은 단지 @fd0 의 마지막 응답에 대한 나의 견해. 그리고 이 시점에서 ETA가 없으므로 그것에 대해 물어볼 필요가 없습니다. :)

한편, 더미 비밀번호를 사용하십시오. :) 적절한 구현에는 이전에 리포지토리를 초기화하는 데 사용된 비밀번호/키를 제거/설정 해제하는 기능이 포함되므로 전체 리포지토리를 다시 만들 필요가 없습니다.

아마도 더 간단한 솔루션은 사용자가 암호를 지정하지 않은 경우 기존 저장소를 열려고 시도할 더미 암호를 지원하는 restic에 대한 것입니다.

더미 암호 처리와 관련하여: 모든 사람에게 적용되는 명확한 최고의 더미 암호는 없습니다. 1234는 위로 이동하여 입력하는 데 네 손가락이 필요하기 때문에 성가신 더미 암호입니다. 예를 들어 "asdf"는 입력하는 것이 훨씬 빠릅니다. 또한 일부 서비스는 비밀번호 선택을 제한하므로 숫자 또는 4자리만 가능하지 않을 수 있습니다. 따라서 restic 내부의 솔루션이 가장 사용자 친화적입니다. 그러면 사용자는 더미 암호를 한 번만 입력하면 됩니다.

보안 설계 관점에서 모든 종류의 더미 암호를 제공하는 것은 나쁜 생각입니다.

IFF 누군가가 정말로 암호화를 우회하고 싶거나 필요하지 않은 경우 일관된 암호를 제공하기만 하면 됩니다. 당신은 그것을 입력할 필요가 없습니다, 당신은 거기에 있는 당신의 마음의 내용에 간결하고 하드 코드를 래핑하는 스크립트를 작성할 수 있습니다. 정말, 저장소 주소나 다른 구성 옵션을 제공하는 것보다 더 많은 작업이 필요합니까?

가짜 또는 더미 하드코딩된 암호 세트를 제한적으로 시도하는 것은 단지 문제를 요구하는 것입니다. 만약 어떤 불쌍한 영혼이 당신이 제안한 "마법" 암호 중 하나를 선택하게 된다면 어떻게 될까요? 우리는 그들에게 우리의 특별한 가짜 암호화 암호를 선택하지 말라고 경고합니까? "아니요 Ted, 저장소 비밀번호로 SPACECHICKEN을 선택할 수 없습니다. _특별한_입니다." ;)

나는 사용자가 ("--no-repository-password")로 스스로를 쏠 수 있는 옵션을 제공하는 것은 괜찮지만, 감소된 보안을 원합니다.

보안 설계 관점에서 모든 종류의 더미 암호를 제공하는 것은 나쁜 생각입니다.

비밀번호를 허용하지 않는 것보다 더 나쁜 이유는 무엇입니까?

IFF 누군가가 정말로 암호화를 우회하고 싶거나 필요하지 않은 경우 일관된 암호를 제공하기만 하면 됩니다. 당신은 그것을 입력할 필요가 없습니다, 당신은 거기에 있는 당신의 마음의 내용에 간결하고 하드 코드를 래핑하는 스크립트를 작성할 수 있습니다. 정말, 저장소 주소나 다른 구성 옵션을 제공하는 것보다 더 많은 작업이 필요합니까?

예, 더 많은 작업입니다. Restic은 백업 솔루션이 될 것이며 그 출력은 리포지토리입니다. 따라서 이상적으로는 리포지토리에 백업을 복원하기 위한 모든 것이 포함됩니다. 그러나 더미 암호를 하드코딩하는 래퍼 스크립트를 사용할 때 이 스크립트는 다른 것으로 백업해야 함을 의미합니다. 그렇지 않으면 저장소가 쓸모가 없습니다.

가짜 또는 더미 하드코딩된 암호 세트를 제한적으로 시도하는 것은 단지 문제를 요구하는 것입니다. 만약 어떤 불쌍한 영혼이 당신이 제안한 "마법" 암호 중 하나를 선택하게 된다면 어떻게 될까요? 우리는 그들에게 우리의 특별한 가짜 암호화 암호를 선택하지 말라고 경고합니까? "아니요 Ted, 저장소 비밀번호로 SPACECHICKEN을 선택할 수 없습니다. _특별한_입니다." ;)

문제가 정확히 무엇입니까? Ted는 여전히 이 비밀번호를 선택할 수 있습니다. 지정하지 않으면 restic이 편리하게 사용할 수 있음을 의미합니다. Restic은 여전히 ​​특별한 비밀번호가 아닌 것처럼 리포지토리를 암호화/복호화합니다.

나는 사용자가 ("--no-repository-password")로 스스로를 쏠 수 있는 옵션을 제공하는 것은 괜찮지만, 감소된 보안을 원합니다.

이것을 "발에 총을 쏘다"라고 부르는 것은 불필요하게 판단적이며 보안이 저하된다는 의미도 아닙니다. 랜섬웨어에 대한 가용성 및 복원력은 보안 개념의 일부여야 합니다. 암호화 암호에 대한 액세스 권한이 없기 때문에 백업을 복원할 수 있는 기능이 없으면 보안이 약화됩니다. 추가 전용 스토리지 시스템에 백업을 안전하게 저장해도 보안 수준이 떨어지지 않습니다.

Why is it worse than allowing no password?

하드코딩되고, 숨겨져 있고, 리포지토리 암호에 대해 비밀리에 시도된 사람을 설득하는 것은 나쁜 생각이 될 것이라고 확신할 수 없습니다. 그들이 그렇다고 생각한다면 당신을 설득할 보안에 초점을 맞춘 주장은 없을 것입니다.

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

나는 재미있는 예를 선택했는데 아마도 없었을 것입니다. 암호 해독에 실패할 경우 비밀리에 자동으로 시도하려는 더미 암호가 "12345"라고 가정해 보겠습니다. 순진한 사용자는 그것을 비밀번호로 선택할 수 있습니다. 이제 그들은 암호화되었다고 믿는(그리고 일종의) 저장소를 가지고 있지만 _모든 사람_ restic은 해독할 수 있습니다. 이 인수는 하드코딩된 세트에서 선택한 암호 세트에 적용됩니다. 이것은 근본적으로 잘못된 보안 설계입니다.

당신이 제안하는 것에 대한 용어가 있습니다. 암호화 백도어라고 합니다. 문서에 백도어를 숨기는 것은 모든 독자가 restic을 사용하기 전에 설명서를 완전히 읽을 것이라고 가정합니다. 더 많은 사람들이 문서를 읽게 하여 그들이 이상하게 원하는 경우 보안을 줄이는 방법을 결정하도록 하는 것이 더 많은 사람들의 요구에 부응하지 않을까요?

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

유휴 암호화가 견고한 보안 정책이라고 생각하지 않고 다른 것을 선택한다면 확실히 소수에 속합니다. 이러한 종류의 안전하지 않은 기본값은 아무에게도 도움이 되지 않으며 모든 지점에서 권장하지 않아야 합니다. 이 경우 조언을 얻기 위해 모든 보안 참조를 살펴보기만 하면 됩니다. 내 요점은 논쟁의 여지가 없습니다. 업계 표준 관행을 주장하는 것입니다.

추가 전용 저장 미디어의 예에서도 미사용 암호화의 이점을 크게 누릴 수 있습니다. 최신 NIST, ISO 27002, NERC, IEC 62443 또는 여기에서 모범 사례에 대한 지침을 위해 실제로 세계적으로 승인된 표준 세트를 읽는 것이 좋습니다. 우리는 새로운 영역에 있지 않습니다.

또한 이 스레드에서 키 관리와 암호화라는 두 가지 문제를 효과적으로 통합하고 있음을 지적해야 합니다.

아마도 여기서 혼란이 발생합니다.

이 문제는 다음과 같은 문서로 해결할 수 있습니다.

암호로 저장소를 보호하지 않으려면 password 문자열을 사용하십시오.

그런 식으로 키를 관리할 필요 없이 restic으로 백업/복원을 달성하는 잘 알려진 방법이 있습니다.

Why is it worse than allowing no password?

하드코딩되고, 숨겨져 있고, 리포지토리 암호에 대해 비밀리에 시도된 사람을 설득하는 것은 나쁜 생각이 될 것이라고 확신할 수 없습니다. 그들이 그렇다고 생각한다면 당신을 설득할 보안에 초점을 맞춘 주장은 없을 것입니다.

나는 당신이 거기에서 "not"을 놓치고 있다고 생각합니다 ...

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

나는 재미있는 예를 선택했는데 아마도 없었을 것입니다. 암호 해독에 실패할 경우 비밀리에 자동으로 시도하려는 더미 암호가 "12345"라고 가정해 보겠습니다. 순진한 사용자는 그것을 비밀번호로 선택할 수 있습니다. 이제 그들은 암호화되었다고 믿는(그리고 일종의) 저장소를 가지고 있지만 _모든 사람_ restic은 해독할 수 있습니다. 이 인수는 하드코딩된 세트에서 선택한 암호 세트에 적용됩니다. 이것은 근본적으로 잘못된 보안 설계입니다.

나는 암호 해독에 실패했을 때 시도하지 않았지만 암호 해독을 위해 암호가 지정되지 않았을 때 시도했습니다. 누군가가 안전하지 않은 암호를 선택하면 직접적으로 시도하거나 무차별 암호 대입을 통해 시도하는 것과 상관없이 안전하지 않습니다. "12345"도 요즘은 안전하지 않은 비밀번호이고, restic의 기본 비밀번호가 되더라도 변경되지 않습니다.

당신이 제안하는 것에 대한 용어가 있습니다. 암호화 백도어라고 합니다. 문서에 백도어를 숨기는 것은 모든 독자가 restic을 사용하기 전에 설명서를 완전히 읽을 것이라고 가정합니다. 더 많은 사람들이 문서를 읽게 하여 그들이 이상하게 원하는 경우 보안을 줄이는 방법을 결정하도록 하는 것이 더 많은 사람들의 요구에 부응하지 않을까요?

암호화 백도어는 restic이 데이터를 암호화할 때 사용자가 제공한 암호에 추가로 기본 암호를 사용하는 경우입니다. 내 제안은 암호 해독 시 하나의 암호를 시도하는 것입니다. 사용자는 여전히 이 잘못된 암호를 적극적으로 선택합니다.

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

유휴 암호화가 견고한 보안 정책이라고 생각하지 않고 다른 것을 선택한다면 확실히 소수에 속합니다. 이러한 종류의 안전하지 않은 기본값은 아무에게도 도움이 되지 않으며 모든 지점에서 권장하지 않아야 합니다. 이 경우 조언을 얻기 위해 모든 보안 참조를 살펴보기만 하면 됩니다. 내 요점은 논쟁의 여지가 없습니다. 업계 표준 관행을 주장하는 것입니다.

당신이 생각하는 안전하지 않은 기본값은 무엇입니까?

추가 전용 저장 미디어의 예에서도 미사용 암호화의 이점을 크게 누릴 수 있습니다. 최신 NIST, ISO 27002, NERC, IEC 62443 또는 여기에서 모범 사례에 대한 지침을 위해 실제로 세계적으로 승인된 표준 세트를 읽는 것이 좋습니다. 우리는 새로운 영역에 있지 않습니다.

미사용 암호화는 restic에서 수행해야 함을 의미하지 않습니다. 추가 전용 저장소는 필요한 경우 다른 방법으로 여전히 암호화할 수 있습니다. 그럼에도 불구하고 비밀번호만을 위한 것이라 하더라도 일부 암호화되지 않은 스토리지가 있을 것입니다. 그렇지 않으면 백업 개념은 항상 암호를 기억하는 사람에 의존합니다.

이 스레드에서 구독 취소...

그냥 이것 좀두고 보자, 일부 사람들이 원하는 것은 분명 --no-password 에 옵션 init , 그리고이 문제에 대해 모든 것을입니다. 암호화 여부는 별개의 문제입니다.

여기에 간단한 설명:
저는 암호화에 관심이 없는 사용자입니다. 내 데이터에 민감한 것은 없습니다. 내가 아닌 20~40년 동안 사용할 수 있는 사람들을 걱정합니다. rclone을 사용하는 것은 또 다른 열악한 대안입니다.

Restic은 암호화를 의무화하고 암호가 이를 고려해야 한다는 것을 의미한다는 점을 제외하고는 이를 위한 좋은 도구처럼 보입니다. 백업 저장소에 README가 있을 수 있습니다. 더 많은 작업이 필요하고 모든 솔루션(내 쪽에서)은 어쨌든 모든 암호화를 무효화합니다.

표시

귀하의 기여에 감사드립니다. 충분한 정보를 수집한 것 같습니다.